关键在于确认fs.file-max是否成为实际瓶颈：它不直接作用于Nginx进程，但会卡住整个链路的上限；若其值小于用户硬限制或进程实际值，则系统级已成瓶颈，所有调优均被静默截断。
排查文件描述符调优中忽视系统全局限制的盲点，关键在于确认 fs.file-max 是否成为实际瓶颈——它不直接作用于 Nginx 进程，但会卡住整个链路的上限，且常被误认为“只要 ulimit 和 nginx.conf 配好了就没事”。
先看真实限制值是否被系统全局压制
执行以下命令，比对三组数值：
-
系统全局限制：
cat /proc/sys/fs/file-max（例如输出 262144） -
Nginx 用户硬限制：
su - nginx -c 'ulimit -Hn'（例如输出 65535） -
Nginx 进程实际生效值：
cat /proc/$(cat /var/run/nginx.pid)/limits | grep "Max open files"（例如显示 1024 65535）
如果第一项（fs.file-max）小于第二或第三项中的任意一个，说明系统级已成瓶颈。比如 fs.file-max=65535，但你给 nginx 用户设了 hard nofile=100000，那这个 100000 就根本不会被内核批准——进程启动时会被静默截断为 65535，甚至更低。
检查 systemd 服务配置是否绕过了 fs.file-max 的约束
systemd 的 LimitNOFILE 不是独立生效的，它仍受 fs.file-max 管辖。即使你在 systemctl edit nginx 中写了：
[Service] LimitNOFILE=100000
若 fs.file-max 只有 65535，Nginx 启动后查 /proc/<pid>/limits</pid> 仍只会看到 65535 65535，而非预期的 100000。
验证方法：重启 Nginx 后，用 systemctl show nginx | grep LimitNOFILE 查看 systemd 解析后的值，再与 /proc/<pid>/limits</pid> 对比。不一致即说明被系统全局值压制。
确认 nginx.conf 中的 worker_rlimit_nofile 没有“超支”
worker_rlimit_nofile 是进程级申请值，但它必须 ≤ 当前进程能获得的最高 nofile 上限——这个上限由 fs.file-max、用户 limits、systemd 三者共同决定，取其中最小者。
- 若
worker_rlimit_nofile 100000，但系统fs.file-max=65535，Nginx 启动时不会报错，但日志里会出现警告：worker_rlimit_nofile 100000 is greater than the system limit of 65535 - 此时该指令实际失效，worker 进程仍按 65535 运行，
worker_connections若设为 65535，则理论并发已达顶峰；若设为更高（如 100000），新连接将直接被拒绝，报Too many open files
临时验证与永久修复路径
临时提高系统全局限制（仅当前生效）：
sysctl -w fs.file-max=2097152
永久生效（写入配置并加载）：
echo "fs.file-max = 2097152" >> /etc/sysctl.conf sysctl -p
注意：该值建议设为单个 Nginx worker 最大连接数 × worker 数 × 1.2～1.5 倍冗余，避免其他系统进程（如日志轮转、监控 agent）争抢 FD 资源。
