Nginx 中 worker?connections 怎么做才能提升稳定性

提升Nginx的worker_connections稳定性需系统资源、Nginx机制与业务行为三者对齐，缺一不可；仅调大数值会触发“Too many open files”或静默丢连接，必须同步调优系统级（fs.file-max）、用户级（limits.conf）、进程级（worker_rlimit_nofile）三层文件描述符限制，并匹配events块中use epoll、multi_accept、accept_mutex等参数。

提升 Nginx 的 worker_connections 稳定性，关键不是单纯调大数值，而是让它在系统资源、Nginx 运行机制和业务连接行为之间真正“稳得住”。否则容易触发 Too many open files、连接静默丢弃或 worker 频繁重启。

确保三层文件描述符限制对齐

实际可用连接数由三者中的最小值决定，缺一不可：

• 系统总上限：修改 /etc/sysctl.conf，设 fs.file-max = 2000000，再执行 sysctl -p
• 用户级限制：在 /etc/security/limits.conf 中为 Nginx 运行用户（如 www-data）添加：
  www-data soft nofile 65536
www-data hard nofile 65536
• Nginx 进程级声明：在 nginx.conf 主上下文（events 块外、http 块前）加：
  worker_rlimit_nofile 65536;（建议 ≥ worker_connections × worker_processes）

按业务类型设合理值，避免资源挤占

过高会加剧内存压力与上下文切换，过低则卡住流量：

• 短连接密集型（如 API 网关、H5 秒杀页）：设 4096–16384，配合较短的 keepalive_timeout 15–30s
• 长连接保活型（如 WebSocket、HTTP/2 上报、直播流）：设 2048–8192，重点保障 worker_rlimit_nofile 和内核 somaxconn 充足
• HTTPS 反向代理：SSL session cache、OCSP stapling 等额外消耗 fd，建议 worker_connections 不超过 ulimit 的 80%

配套 events 参数必须协同生效

只改 worker_connections 几乎无效，必须同步优化事件处理效率：

• use epoll;：Linux 下必须显式写，避免回退到有硬限的 select/poll
• multi_accept on;：让一个 worker 在一次事件循环中尽可能多地接收就绪连接，缓解突发排队
• accept_mutex off;：高并发多 worker 场景下减少锁争抢（尤其搭配 reuseport 时更有效）
• 检查 listen 指令是否带 backlog=4096，并确保内核 net.core.somaxconn ≥ 该值

验证是否真正生效

reload 成功不等于配置落地，需实测确认：

• 查运行中 worker 的实际限制：cat /proc/$(pgrep nginx)/limits | grep "Max open files"
• 压测时观察：lsof -p $(pgrep nginx) | wc -l（当前 fd 占用）和 ss -s（连接状态分布）
• 监控 Active connections 是否长期 >85% 且伴随 Accepts/Handled/Requests 比例异常下降