真正卡住的往往不是worker_connections本身，而是其背后系统文件描述符、worker_rlimit_nofile、内核网络队列等资源未对齐；需依错误日志、连接数、ulimit及配套配置逐层排查验证。
看到连接被拒绝，别急着改 worker_connections。真正卡住的往往不是这个数字本身，而是它背后一整套资源限制没对齐。排查要从现象出发，一层层验证是不是真被这个值堵住了。
看错误日志，确认是不是真报这个错
打开 Nginx 错误日志：grep "worker_connections" /var/log/nginx/error.log
重点找这两类提示：
-
worker_connections are not enough—— 明确指向连接数上限不足 -
accept() failed (24: Too many open files)—— 实际是文件描述符不够，worker_connections只是“表现”
如果没这两条，问题大概率在别处：后端超时、网络丢包、DNS 解析慢，或者客户端压测工具本身并发设置不合理。
查当前连接数，对比理论上限
运行命令，看看真实压力到了什么程度：
-
ss -s | grep "TCP:"—— 查 ESTABLISHED 连接总数 -
netstat -ant | grep :80 | wc -l—— 粗略统计监听端口上的连接 - 算一下理论最大值：
worker_processes × worker_connections
如果 ESTABLISHED 数长期接近甚至超过这个乘积，就高度可疑。但注意：反向代理场景下，一个请求会占至少 2 个连接（client + upstream），所以实际连接数可能比 QPS 高好几倍。
验系统和进程级文件描述符限制
这是最容易忽略却最关键的一步。Nginx 每个连接都要一个文件描述符（fd），没 fd 就连不上。
- 查当前用户限制：
ulimit -n—— 默认常是 1024，远不够 - 查 Nginx 进程实际能用多少：
cat /proc/$(pgrep nginx)/limits | grep "Max open files" - 查系统总容量：
cat /proc/sys/fs/file-max—— 建议 ≥10 万
如果 ulimit -n 或进程 limits 明显小于你设的 worker_connections，那调大 worker_connections 就是白忙活。
核对配套配置是否同步到位
只改 worker_connections 是无效的。以下三项必须一起动：
-
系统级限制：在
/etc/security/limits.conf加两行（把nginx换成实际运行用户）：nginx soft nofile 65536nginx hard nofile 65536
再确认/etc/pam.d/common-session有session required pam_limits.so -
Nginx 进程级限制：在
nginx.conf的 main 上下文（http 块外）加：worker_rlimit_nofile 65536;
这个值应 ≥worker_connections -
内核接收队列：修改
/etc/sysctl.conf：net.core.somaxconn = 65535net.core.netdev_max_backlog = 25000
然后执行sysctl -p
改完记得先 nginx -t 检查语法，再 nginx -s reload，别直接 restart。
