worker_connections设错会引发负载雪崩或资源虚耗：过低导致连接拒绝、客户端重试、后端堆积；过高却未同步调优ulimit、worker_rlimit_nofile和file-max，则触发“too many open files”或加剧内存与CPU压力，必须按短连/长连/HTTPS等业务场景协同配置三者最小值及epoll、multi_accept等参数。
worker_connections 本身不直接增加 CPU 或内存负载，但它设错了，就会让系统在看不见的地方“憋着劲儿干活”，最终表现为高负载、响应慢、连接失败。
worker_connections 过低：连接被拒 → 客户端重试 → 负载雪崩
单个 worker 进程一旦达到 worker_connections 上限，新连接要么被内核 listen 队列排队（受 net.core.somaxconn 限制），要么直接拒绝，返回 503 或静默丢包。客户端感知卡顿后频繁重试，请求量翻倍，后端堆积，Nginx 自身也因大量短连接建连/断连、日志写入、TIME_WAIT 处理而推高 CPU（尤其是 sy%）和网络开销。
- 典型现象：nginx_stub_status 中 Accepts/Handled 比值明显低于 1，netstat -s | grep "listen overflows" 有非零计数
- 短连接场景（如秒杀接口）尤其敏感：每秒 2000 请求 + worker_connections=1024 → 大量连接在 accept 前就积压或丢弃
worker_connections 过高但未配套调优：资源虚耗 → 真实瓶颈卡在别处
盲目设成 65535 而不提升系统文件描述符限制（ulimit -n）、不配 worker_rlimit_nofile、不调大 file-max，Nginx 启动会失败，或运行中报 “too many open files”。即使启动成功，每个连接仍占几 KB 内存，过高值会放大内存压力、加剧上下文切换，尤其当 worker_processes 远超物理核心数时，CPU 时间片争抢反而抬高系统负载。
- 必须同步满足三者最小值：/proc/sys/fs/file-max ≥ worker_processes × worker_connections × 1.3；limits.conf 中 nginx 用户 nofile ≥ 该值；nginx.conf 中 worker_rlimit_nofile ≥ worker_connections
- worker_processes 设为 auto 未必最优——容器环境或 16 核以上物理机，显式设为 8 或 12 更稳，避免超线程误判和调度抖动
连接模式决定真实资源消耗，不是数字越大越“能扛”
同样设为 32768，对短连接 API 和长连接 WebSocket 的压力完全不同：
- 短连接：连接生命周期短，fd 快速释放，重点是吞吐率，需保障 ulimit 和 somaxconn 充足，可关 keepalive 或设短 timeout
- 长连接（HTTP/2、MQTT）：fd 长期占用，更吃总 fd 上限和内存，要确保 worker_rlimit_nofile 和 file-max 预留足够余量（建议 1.3～1.5 倍）
- HTTPS 反向代理：除 socket 外还消耗 SSL session cache、OCSP stapling、证书读取等额外 fd，worker_connections 建议不超过单进程 ulimit 的 80%
真正影响负载的，是它和其他参数的配合效果
单独改 worker_connections 几乎没用。必须和以下参数联动才能把连接能力真正落地：
- use epoll;：Linux 下必须显式开启，否则回退到 select/poll，有 1024 硬上限
- multi_accept on;：一次事件循环尽可能多收连接，缓解突发流量排队
- accept_mutex on;：默认开启，防止多个 worker 同时争抢 accept 导致“惊群”
- 关闭未用日志、启用 buffer+flush：减少每个请求额外占用的 fd 和磁盘 I/O
验证不能只看 reload 成功。要查 cat /proc/$(pgrep nginx)/limits | grep "Max open files"，压测时用 lsof -p $(pgrep nginx) | wc -l 和 ss -s 看实际 fd 占用与连接状态分布。监控超过 85%，就得回头检查哪一层限制没对齐。
