提升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 65536www-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比例异常下降
