调优 worker_connections 必须依据监控数据：active connections 持续 > 80% × (worker_connections × worker_processes) 表明配置吃紧；需结合 error.log 中 "too many open files" 错误、/proc/$(pgrep nginx)/limits 查句柄上限、lsof 统计实际 fd 占用，并按短连/长连/反向代理等请求模型差异化估算。
调优 worker_connections 不能靠拍脑袋，得看监控数据说话。它本质是“单个 worker 能同时维持多少连接”，而真实压力是否逼近上限、是否被系统卡住，全反映在几项关键指标里。
看活跃连接数（Active connections）是否长期贴顶
这是最直接的信号。Nginx 内置状态页（需启用 ngx_http_stub_status_module）或 Prometheus Exporter 都能拿到这个值：
- 如果 Active connections 持续 > 80% 的
worker_connections × worker_processes，说明当前配置已吃紧，新连接可能排队或被拒绝 - 注意区分 Active 和 Waiting：Waiting 是 keepalive 空闲连接，不占处理资源；真正要盯的是 Active 中持续增长且响应变慢的部分
- 若 Active 长期稳定在 2000 左右，而你设了 16384，那数值明显过剩，可适当下调，节省内存和上下文切换开销
查错误日志和系统句柄使用率
worker_connections 卡住时，往往不是报错，而是静默失败。重点排查：
-
error.log 出现
socket() failed (24: Too many open files)：说明系统级文件描述符不足，worker_connections再大也跑不通 - 用
cat /proc/$(pgrep nginx)/limits | grep "Max open files"查实际生效的句柄上限，必须 ≥worker_connections - 监控
nginx_process_open_fds（Prometheus）或lsof -p $(pgrep nginx) | wc -l，看真实占用是否逼近上限
结合请求模型看连接生命周期
同样的连接数，短连和长连对 worker_connections 的压力完全不同：
- HTTP/1.1 短连接 API（如 JSON 接口）：每个请求独占一个连接，
worker_connections要按峰值 QPS × 平均响应时间来估算 - WebSocket 或 HTTP/2 长连接：一个连接复用多次，更看重内存和空闲超时设置，
worker_connections可设低些，但keepalive_timeout要配合调长 - 反向代理场景：如果后端响应慢，连接会在 Nginx 中等待，此时
proxy_read_timeout比盲目调大worker_connections更有效
观察吞吐与资源消耗是否失衡
调大后不见效果？可能是其他瓶颈在拖后腿：
- CPU 使用率仍很低（use epoll 是否启用、
multi_accept on是否开启，避免连接接收效率低 - 内存使用明显上涨，且
Active connections未同步提升 → 连接数设得过高，每个连接占几 KB，积少成多造成浪费 - 5xx 错误率上升、
dropped requests增加 → 很可能是系统net.core.somaxconn或 backlog 队列满，不是worker_connections的问题
