必须预留冗余，因为每个活跃连接仅占1个文件描述符是理论值，实际还需承载日志、缓存、SSL会话、upstream连接、TIME_WAIT socket及系统其他服务开销；推荐最小安全值为worker_processes×worker_connections×1.5，且需配套调大worker_rlimit_nofile与用户ulimit限制。
要让 Nginx 在高并发下稳定运行，fs.file-max 不能只满足理论连接数，必须预留足够冗余——它不是“够用就行”的参数，而是系统级资源安全线。
为什么必须预留冗余？
一个活跃连接会占用至少 1 个文件描述符，但实际开销远不止于此：
- 每个 worker 进程除连接外，还需打开日志文件、临时缓存文件、SSL 会话缓存、upstream 连接等
- 大量短连接会快速堆积 TIME_WAIT 状态 socket（每个占 1 句柄），且持续约 60 秒
- 系统本身（syslog、cron、监控 agent 等）也会消耗句柄，不可忽略
- 突发流量或连接抖动会导致瞬时句柄峰值远超平均值
怎么算出合理冗余值？
推荐按这个公式估算最小安全值：
fs.file-max ≥ worker_processes × worker_connections × 1.5
例如：8 个 worker，每个设为 131072，则基础需求是 1,048,576；乘以 1.5 后建议 ≥ 1,572,864。更保守场景（如小文件服务、长连接+短连接混合）可上浮至 ×1.8～2.0。
若已知 ulimit -n 对应用户限制（比如 nginx 用户被设为 1048576），则 fs.file-max 至少应为该值的 1.2 倍以上，避免内核层先于用户层触顶。
设置与验证要点
- 临时生效：用
sysctl -w fs.file-max=2097152快速验证，适合压测前调试 - 永久生效：写入
/etc/sysctl.conf后执行sysctl -p，确保重启不丢失 - 检查是否真正加载：运行
cat /proc/sys/fs/file-max，确认输出值与设定一致 - 别忘了配套调大 nginx 自身限制：在 nginx.conf 的 main 块中加
worker_rlimit_nofile 1048576;，否则 worker 进程仍受默认 ulimit 限制
常见误判与避坑
- 只改了
worker_connections却没调fs.file-max→ 内核拒绝分配新句柄，Nginx 报 “cannot open more files” - 设了很高的
fs.file-max，但没同步调整 nginx 用户的ulimit -n（通过/etc/security/limits.conf）→ worker 进程启动时仍被卡在低值 - 误以为
fs.file-max是 per-process 限制 → 它是全系统总和，所有进程共享，需统筹评估其他服务用量 - 压测中观察
/proc/sys/net/ipv4/tcp_tw_count和/proc/sys/fs/file-nr，若后者第二列（已分配）持续逼近第一列（最大值），说明冗余不足
