worker_connections本身不提升事件处理速度，仅定义单worker连接上限；必须同步打通系统fd限制（ulimit、limits.conf、systemd）、nginx进程级声明（worker_rlimit_nofile）及事件模型（epoll+multi_accept），并按业务类型合理设值，否则配置无效。
worker_connections 本身不直接提升事件处理速度，它只是定义了单个 worker 进程能同时管理的连接上限。真正影响事件处理速度的是它能否在系统资源、Nginx 事件模型和业务连接行为之间“跑通”。设得再高，若底层卡住，连接连建立都失败，更谈不上处理。
必须同步打通三个层面，才能让连接真正被快速响应和调度：
-
系统文件描述符（fd）要够用
每个 TCP 连接至少占 1 个 fd，SSL 握手、日志写入、上游连接还会额外消耗。如果ulimit -n还是默认的 1024，哪怕worker_connections设成 65535，实际有效值就是 1024。
✅ 正确做法：- 在
/etc/security/limits.conf中为 nginx 用户（如nginx或www-data）设置：nginx soft nofile 65536 nginx hard nofile 65536
- 若使用 systemd，还需在
/etc/systemd/system/nginx.service.d/override.conf中加：[Service] LimitNOFILE=65536
- 重启会话或执行
systemctl daemon-reload && systemctl restart nginx
- 在
-
Nginx 进程级 fd 上限要声明
即使系统允许开 65536 个 fd，Nginx 不主动申请，也不会用满。
✅ 必须在nginx.conf的http块之外（即主上下文）添加：worker_rlimit_nofile 65536;
该值应 ≥
worker_connections，推荐设为相同值或略高（如1.2 × worker_connections），为日志、缓存、SSL session 等留余量。 -
事件模型与连接接收机制要匹配
worker_connections只是“容量”，而epoll+multi_accept才决定“吞吐效率”：
✅ 在events块中确保：use epoll; multi_accept on; accept_mutex on;
-
epoll是 Linux 下高性能事件驱动的基础，避免 select/poll 的 O(n) 扫描开销； -
multi_accept on让一个 worker 在一次事件循环中尽可能多地accept()新连接，减少排队延迟； -
accept_mutex on（默认开启）防止多个 worker 同时争抢新连接，避免“惊群”。
-
按业务类型设合理值，避免虚假高配拖慢真实速度
不是越大越好——过高会增加内存占用（每个连接约 2–4 KB）、加剧上下文切换、拉长内核 socket 队列等待时间：
- 短连接 API / 静态资源：
4096–16384，配合keepalive_timeout 15–30s； - WebSocket / HTTP/2 / 直播流：
2048–8192，重点保障worker_rlimit_nofile和file-max充足； - HTTPS 反向代理：
worker_connections建议不超过单进程 ulimit 的 80%，预留给 SSL session cache、OCSP stapling、证书读取等额外 fd。
验证是否真生效，不能只看 reload 成功
- 查运行中 worker 的实际限制：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"
- 压测时观察：
lsof -p $(pgrep nginx) | wc -l # 实际打开 fd 数 ss -s # 内核维护的 socket 总数（括号内数字更准）
若
lsof结果长期 >85% 配置值，或 error.log 出现accept() failed (24: Too many open files)，说明某一层没对齐。
不复杂但容易忽略的是：worker_processes auto; 和 worker_connections 的乘积才是理论全局并发上限，而真实瓶颈几乎总在系统层——调大配置只是第一步，资源链没打通，连接连进来都难，更别说处理快了。
