worker_connections 是每个 worker 进程能处理的活跃连接上限，实际生效值取决于系统 file-max、用户 ulimit 和 worker_rlimit_nofile 三者的最小值，需配套调优事件模型与业务场景。
Nginx 的 worker_connections 不是“并发连接总数”，而是每个 worker 进程能同时处理的活跃连接上限。它的实际效果受系统资源、Nginx 自身声明和内核网络栈三重约束，单独调大几乎无效，反而容易触发 Too many open files 错误或连接静默拒绝。
worker_connections 实际生效依赖三层限制
真正起作用的是以下三者的最小值：
-
系统总文件描述符上限：
/proc/sys/fs/file-max，建议设为worker_processes × worker_connections × 1.3～1.5，预留日志、SSL 缓存、TIME_WAIT 等开销 -
用户级文件描述符限制：在
/etc/security/limits.conf中为 Nginx 运行用户（如www-data或nginx）设置：nginx soft nofile 65536 nginx hard nofile 65536
若使用 systemd，还需在
/etc/systemd/system/nginx.service.d/override.conf中添加：[Service] LimitNOFILE=65536
-
Nginx 进程级句柄声明：在
nginx.conf主块（events外、http前）添加：worker_rlimit_nofile 65536;
该值应 ≥
worker_connections，推荐设为相同值或略高（如 1.2 倍）
按业务类型设合理数值
数值不是越大越好，需匹配连接行为与资源消耗：
-
短连接密集型（如 H5 秒杀页、API 接口）：设
4096–16384，配合keepalive_timeout 0彻底禁用长连接，避免槽位被空闲连接占用 -
长连接保活型（如 WebSocket、HTTP/2 上报、直播流）：设
32768–65535，重点保障worker_rlimit_nofile和file-max充足，并调低keepalive_timeout（如15–30）控制空闲时长 -
HTTPS 反向代理：除 socket 外还需 SSL session cache、OCSP stapling、证书文件等额外 fd，建议
worker_connections不超过单进程 ulimit 的 80%
events 块必须配套调优
仅改 worker_connections 效果有限，需同步启用高效事件机制：
-
use epoll;：Linux 下必须显式指定，避免回退到有 1024 硬限的select/poll -
multi_accept on;：让一个 worker 在一次事件循环中尽可能多地 accept 新连接，缓解突发流量排队 -
accept_mutex on;：默认开启，防止多个 worker 同时争抢新连接造成“惊群”
验证是否真正生效
配置 reload 后不能只看语法通过，要实测确认：
- 查运行中 worker 的实际限制：
cat /proc/$(pgrep nginx)/limits | grep "Max open files" - 压测时观察：
lsof -p $(pgrep nginx) | wc -l（当前 fd 占用）、ss -s（连接状态分布） - 监控
Active connections是否稳定在worker_processes × worker_connections的 70%～90%，过高说明资源吃紧，过低说明瓶颈在上游或业务逻辑
不复杂但容易忽略
