单靠调大worker_connections无法突破高并发限制，它只是资源链路的“终点刻度”；必须对齐系统file-max、用户级limits.conf、Nginx进程级worker_rlimit_nofile三层fd限制，并同步配置net.core.somaxconn、use epoll、multi_accept等内核与events参数，再按短连/长连/HTTPS等业务类型设定合理值并实测验证。
单靠调大 worker_connections 无法突破高并发连接限制。它只是整条资源链路的“终点刻度”，真正起作用的是系统文件描述符上限、Nginx 进程声明、内核网络队列和事件模型四者协同的结果。任一环节卡住，这个值就形同虚设。
必须对齐的三层文件描述符限制
每个 TCP 连接至少占用 1 个文件描述符（fd），而 Nginx 还需额外 fd 处理日志、SSL 缓存、上游连接等。实际可用连接数由以下三者最小值决定：
-
系统总上限：
/proc/sys/fs/file-max，建议设为worker_processes × worker_connections × 1.3～1.5 -
用户级限制：在
/etc/security/limits.conf中为 Nginx 用户（如www-data或nginx）添加：www-data soft nofile 65536www-data hard nofile 65536 -
Nginx 进程级声明：在
nginx.conf主块（http外）添加：worker_rlimit_nofile 65536;，该值应 ≥worker_connections，推荐设为相同或略高（如 1.2 倍）
配套内核与 events 参数不可少
连接还没进 Nginx 就被系统丢弃，再大的 worker_connections 也没意义：
-
内核监听队列：修改
/etc/sysctl.conf，设net.core.somaxconn = 65535，并执行sysctl -p生效 -
事件模型强制指定：在
events { }块中必须写明：use epoll;（Linux 下不写可能回退到有 1024 硬限的select）multi_accept on;（让一个 worker 单次事件循环尽可能多地接收新连接） -
避免惊群干扰：
accept_mutex on;默认开启即可，高频短连场景不必盲目关闭
按业务类型设合理值，不是越大越好
数值过高会加剧内存压力（每个连接占 2–4 KB）和上下文切换开销，应匹配真实连接行为：
-
短连接密集型（如秒杀页、API 轮询）：设
worker_connections 8192–16384，配合keepalive_timeout 0;快速释放连接槽位 -
长连接保活型（如 WebSocket、HTTP/2、直播流）：设
4096–8192，重点保障keepalive_timeout和worker_rlimit_nofile充足 -
HTTPS 反向代理：SSL session cache、OCSP stapling 等额外消耗 fd，
worker_connections不宜超过 ulimit 的 80%
验证是否真正生效
配置 reload 成功 ≠ 实际生效，必须实测确认：
- 查运行中 worker 的真实限制：
cat /proc/$(pgrep nginx)/limits | grep "Max open files" - 压测时观察连接分布：
ss -s | grep "TCP:"对比worker_processes × worker_connections - 检查错误日志是否有
worker_connections are not enough或Too many open files
