直接调高worker_connections但不解决系统文件描述符限制无效，Nginx会静默降级并报“accept() failed (24: Too many open files)”，需同步调齐系统级limits.conf、进程级worker_rlimit_nofile和内核级fs.file-max三层限制，并验证活跃连接与fd上限匹配。
直接调高 worker_connections 但不解决系统文件描述符限制，等于没调——Nginx 会静默降级到实际允许的上限，日志里反复出现 accept() failed (24: Too many open files) 或 worker_connections are not enough，新连接被丢弃，用户看到的是 502/504。
先确认是不是真卡在 fd 上限
别一看到报错就改配置。快速验证三件事：
- 查当前活跃连接：
ss -s | grep "TCP:"或netstat -ant | grep ESTABLISHED | wc -l，对比worker_processes × worker_connections是否长期 >90% - 看错误日志：
grep "Too many open files\|worker_connections" /var/log/nginx/error.log，重点找是否提示资源限制不足 - 查进程真实 fd 上限：
cat /proc/$(pgrep nginx) /limits 2>/dev/null | grep "Max open files"，注意 soft 和 hard 值是否够用
必须同步调齐三层 fd 限制
worker_connections 每个值都对应至少 1 个文件描述符（fd），而 fd 受三层控制，缺一不可：
-
系统级：通过
/etc/security/limits.conf设置（对 nginx 用户或 *），例如：
nginx soft nofile 65536
nginx hard nofile 65536 -
进程级：在 nginx.conf 的 main 块中加
worker_rlimit_nofile 65536;，这是 Nginx 主进程向内核主动申请的上限，必须 ≤ limits.conf 中的 hard 值 -
内核级：确保
/proc/sys/fs/file-max足够大，建议 ≥worker_processes × worker_connections × 1.5（预留 TIME_WAIT、SSL 缓存、日志等开销）
反向代理场景要翻倍预留
普通静态服务一个请求占 1 个连接；但反向代理下，每个客户端请求通常同时打开两个连接（client ↔ nginx + nginx ↔ upstream），如果 upstream 响应慢、keepalive 开启或 HTTPS 多路复用，fd 消耗更快。例如设 worker_connections 8192，实际建议按 16384 的 fd 需求来规划系统限制。
配套调优 events 参数提升效率
光放开上限不够，还要让连接处理更高效：
- 明确指定
use epoll;（Linux 必配，比 select/poll 高效得多） - 开启
multi_accept on;，让单次系统调用尽可能多地接受连接，减少唤醒次数 - 搭配
accept_mutex on;（默认）防惊群，避免多个 worker 同时争抢 accept
