worker_connections是Nginx并发能力的配置上限，需与系统file-max、用户limits.conf、nginx.conf中worker_rlimit_nofile三者对齐，再结合业务类型（短连/长连/HTTPS）、events参数（epoll/multi_accept）及内核调优（somaxconn）协同生效，否则单独调大必失败。
worker_connections 本身不是“实现”并发的机制，而是 Nginx 并发能力的一个配置上限。真正实现高效并发，靠的是它与系统资源、内核参数、Nginx 事件模型和业务特征四者协同运转。单独调大这个值，几乎必然失败。
对齐三层文件描述符限制
每个连接至少占用 1 个文件描述符（fd），而实际生效的并发上限，取决于以下三者的最小值：
-
系统总上限：/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
再执行systemctl daemon-reload && systemctl restart nginx，用cat /proc/$(pgrep nginx)/limits | grep "Max open files"验证 -
Nginx 进程级声明：在 nginx.conf 的 main 块（http 外）添加：
worker_rlimit_nofile 65536;
该值应 ≥ worker_connections，推荐设为相同或略高（如 1.2 倍）
匹配业务连接类型设合理值
数值不是越大越好——过高会吃内存、增调度压力，过低则卡住真实长连接。关键看连接生命周期：
-
短连接为主（如 H5 秒杀页、CDN 回源）：连接建立快、关闭快，可设
4096–16384，重点保障吞吐速度 -
长连接保活型（如 WebSocket、HTTP/2 上报、直播流）：单连接复用时间长，fd 占用稳定但总量大，建议
2048–8192，并配合keepalive_timeout 15–30s控制空闲释放 - HTTPS 反向代理：除 socket 外还需 SSL session cache、OCSP stapling 等额外 fd，worker_connections 不宜超过单进程 ulimit 的 80%
启用高效事件模型与接收策略
没有 epoll 和 multi_accept，worker_connections 再高也跑不起来：
- use epoll;：Linux 下必须显式指定，避免回退到 select/poll（有 1024 硬限）
- multi_accept on;：让一个 worker 在一次事件循环中尽可能多地 accept 新连接，缓解突发流量排队
- accept_mutex on;（默认开启）：防止多个 worker 同时争抢新连接导致“惊群”
-
配套内核调优：修改 /etc/sysctl.conf：
net.core.somaxconn = 65535net.core.netdev_max_backlog = 25000
执行sysctl -p生效
验证是否真正跑得通
reload 成功 ≠ 配置生效。压测时需交叉验证：
- 查进程实际限制：
cat /proc/$(pgrep nginx)/limits | grep "Max open files" - 观察实时 fd 占用：
lsof -p $(pgrep nginx) | wc -l - 统计连接状态分布：
ss -s，关注 ESTABLISHED 占比是否 >85%，TIME_WAIT 是否 - 监控 error_log，警惕
socket() failed (24: Too many open files)或静默拒绝现象
