优化worker_connections需协同系统资源、内核参数与业务特征，实际并发上限取决于/proc/sys/fs/file-max、limits.conf中用户级nofile及nginx.conf中worker_rlimit_nofile三者最小值，并须配套use epoll、multi_accept on等参数调优。
worker_connections 本身不“实现”高负载，它是 Nginx 单个 worker 进程能同时处理的最大连接数上限。真正支撑高负载的是它与系统资源、内核参数、事件模型和业务特征协同运转的结果。调大这个数字只是起点，没对齐上下游限制，等于在高速路口修了八车道却只开一道闸机。
真正起作用的是三个限制的最小值
不是看 worker_connections 65535 就能扛住 6 万连接，而是以下三者谁小，上限就是谁：
- 系统总文件描述符上限：
/proc/sys/fs/file-max（建议设为worker_processes × worker_connections × 1.3～1.5） - 用户级单进程限制：
/etc/security/limits.conf中对 nginx 用户的nofile设置（如nginx soft nofile 65536） - Nginx 进程级声明：配置中
worker_rlimit_nofile 65536（必须 ≥worker_connections，推荐同值或略高）
按业务类型设合理值，不是越大越好
盲目堆高 worker_connections 会加剧内存占用（每个连接约 2–4 KB）和上下文切换开销：
- 静态资源或短连接 API（如秒杀页、H5 页面）：设
4096–16384，配合keepalive_timeout 0彻底禁用长连接 - WebSocket / HTTP/2 / 直播流等长连接场景：设
2048–8192，重点保障worker_rlimit_nofile和file-max充足 - HTTPS 反向代理：SSL session cache、OCSP stapling 等额外消耗 fd，
worker_connections建议不超过单进程 ulimit 的 80%
必须配套调整的关键参数
只改 worker_connections 几乎无效，必须同步生效以下配置：
-
use epoll;：Linux 下强制启用高效 I/O 模型，避免回退到有 1024 硬限的select/poll -
multi_accept on;：让一个 worker 在一次事件循环中尽可能多地 accept 新连接，缓解突发流量排队 -
accept_mutex on;：默认开启，防止多个 worker 同时争抢新连接导致“惊群” -
net.core.somaxconn = 65535：内核监听队列长度，需 ≥worker_connections，否则连接在进 Nginx 前就被丢弃
验证是否真正生效
配置 reload 成功不代表跑得通，要实测验证：
- 查运行中 worker 的实际限制：
cat /proc/$(pgrep nginx)/limits | grep "Max open files" - 压测时观察 fd 占用：
lsof -p $(pgrep nginx) | wc -l和ss -s - 监控
Active connections是否稳定在理论值的 70%–90%，过高可能资源耗尽，过低说明上游或业务逻辑成瓶颈
不复杂但容易忽略
