worker_connections直接决定单个worker进程并发连接数，设太低会成qps硬瓶颈，设太高若未同步调优系统限制则引发丢连、502/503或性能反降；必须与ulimit、net.core.somaxconn、epoll等协同配置才能释放真实并发能力。
worker_connections 直接决定单个 worker 进程能同时处理的连接数，它不直接“提升 QPS”，但设得太低会成为 QPS 的硬瓶颈；设得过高又可能因系统资源未同步跟进而引发故障或性能反降。真实影响取决于是否与业务模式、系统限制和 Nginx 其他参数形成协同。
worker_connections 过低：QPS 被卡在入口
当该值小于实际并发连接需求时，新连接会被内核 listen 队列排队（受 net.core.somaxconn 限制）或直接拒绝，表现为：
- 客户端收到 503 或超时，触发重试 → 请求量虚高但有效吞吐不增
- nginx_stub_status 中 Accepts/Handled 比值明显低于 1（理想应接近 1）
- netstat -s | grep "listen overflows" 显示非零溢出计数
- 短连接场景（如 API、秒杀）尤其敏感：每秒 2000 请求 + worker_connections=1024，大量连接甚至没进入 accept 阶段就被丢弃
worker_connections 合理调高：释放并发潜力
配合系统级调优后，QPS 提升显著，因为更多连接可被及时接纳和分发：
- 实测案例：worker_connections 从 1024 提升到 4096，QPS 从 12.3k 增至 18.7k（+51.6%）
- 进一步升至 65535 并配齐 ulimit、worker_rlimit_nofile、file-max，8C16G 服务器可稳定支撑 10 万+ QPS
- 关键前提是：use epoll; multi_accept on; accept_mutex off; 并启用 keepalive 复用连接，避免频繁建连开销
worker_connections 设太高但未配套：QPS 不升反抖
盲目设大而忽略底层约束，会导致资源争抢或错误，反而压制 QPS：
- ulimit -n 或 worker_rlimit_nofile 小于 worker_connections × worker_processes → 启动失败或静默降级（日志 warn 后按低值运行）
- 每个连接占用几 KB 内存，过高值放大内存压力，尤其在长连接（WebSocket、HTTP/2）场景下易触发 OOM 或 swap
- worker_processes 远超物理核心数时，上下文切换加剧，CPU sy% 上升，Nginx 自身事件循环效率下降
- 文件描述符耗尽后，Nginx 无法建立 upstream 连接或写缓存，出现 502/504 或“failed to open log file”等错误
按业务类型选值比盲目堆数字更重要
同样设为 32768，对不同连接模式的压力完全不同：
- 短连接 API：重点在吞吐速率，需保障 somaxconn 充足、keepalive_timeout 较短（如 10–30s），并关闭不必要的模块减少事件路径
- 长连接服务（MQTT、实时推送）：fd 长期占用，更依赖总 fd 上限和内存余量，建议 file-max ≥ worker_processes × worker_connections × 1.3～1.5
- HTTPS 流量：SSL 握手本身更耗 CPU，连接数上限受 CPU 解密能力制约，不宜单靠提高 worker_connections 突破
