worker_connections不是孤立配置项，而是需与系统file-max、用户limits.conf、nginx.conf中worker_rlimit_nofile三者对齐的资源链一环；任一环节偏低都会导致“too many open files”或连接静默拒绝。
worker_connections 不是单独调大的数字，而是整个文件描述符资源链中的一环。设得再高，若系统限制、进程声明或业务模型没对齐，实际连接数照样卡住，甚至出现 too many open files 或连接静默拒绝。
确保三层文件描述符限制对齐
真正生效的是以下三者的最小值，任一环节偏低都会拖后腿：
-
系统总上限：
/proc/sys/fs/file-max，建议设为worker_processes × worker_connections × 1.3～1.5，预留 TIME_WAIT、SSL 缓存、日志等开销 -
用户级限制：在
/etc/security/limits.conf中为 Nginx 运行用户（如nginx或www-data）添加：nginx soft nofile 65536nginx hard nofile 65536
修改后需重载 systemd 或重新登录会话 -
Nginx 进程级声明：在
nginx.conf的主块（http外）添加：worker_rlimit_nofile 65536;
该值应 ≥worker_connections，推荐设为相同值或略高（如 1.2 倍）
按业务连接特征设合理数值
不同场景下 fd 消耗差异大，盲目设高反而浪费内存、加剧上下文切换：
-
短连接 API 或静态资源服务（如 H5 秒杀页）：设
4096–16384，配合keepalive_timeout 15–30s -
长连接型服务（如 WebSocket、HTTP/2 上报、直播流）：设
32768–65535，重点保障worker_rlimit_nofile和file-max充足 -
HTTPS 反向代理：除 socket 外还需 SSL session cache、OCSP stapling 等额外 fd，建议
worker_connections不超过单进程 ulimit 的 80%
配套 events 参数必须同步启用
只改 worker_connections 效果有限，关键协同参数如下：
-
use epoll;：Linux 下必须显式指定，避免回退到有硬限的select/poll -
multi_accept on;：让一个 worker 在一次事件循环中尽可能多地 accept 新连接，缓解突发流量排队 -
accept_mutex on;（默认开启）：防止多个 worker 同时争抢新连接导致“惊群” - 关闭未启用的日志写入，或启用
access_log ... buffer=64k flush=1s;，减少每个请求占用的 fd
验证是否真正生效
reload 成功不等于配置落地，务必实测验证：
- 查运行中 worker 的实际限制：
cat /proc/$(pgrep nginx)/limits | grep "Max open files" - 压测时观察 fd 占用：
lsof -p $(pgrep nginx) | wc -lss -s查看 ESTAB/SYN-RECV 状态分布 - 监控实际使用率是否长期 >85%，若接近上限但吞吐未提升，说明存在其他瓶颈（如上游延迟、磁盘 I/O 或内核队列溢出）
