排查Nginx worker_connections是否达到限制，应优先检查error.log中“accept() failed”等错误记录，再结合/proc下worker进程fd数量、配置值及stub_status中Active connections占比综合判断。
排查 Nginx 中 worker_connections 是否达到限制，核心是看错误日志里有没有连接拒绝相关的记录，而不是直接查配置值。真正触发限制时，Nginx 会主动拒绝新连接，并留下明确线索。
看 error.log 里是否有 “accept() failed” 或 “too many open files”
当 worker 进程无法接受新连接（比如已达到 worker_connections 上限），Nginx 会在 error.log 中记录类似：
-
accept() failed (24: Too many open files)—— 这通常意味着系统级文件描述符用尽，间接导致 worker 无法新建连接； -
accept() failed (11: Resource temporarily unavailable)—— 更常见于连接洪峰时内核 backlog 溢出或 worker 已满； -
epoll_ctl() failed (2: No such file or directory)或eventfd() failed等，也可能指向事件驱动模型资源不足，与连接数瓶颈相关。
注意：这些错误不一定 100% 是 worker_connections 配置太小，但它是首要排查方向。
确认当前 worker 进程打开的文件描述符数量
Linux 下每个 worker 进程能使用的最大文件描述符数，受限于系统限制（ulimit -n）和 Nginx 的 worker_rlimit_nofile 设置。如果 worker_rlimit_nofile 小于 worker_connections，实际生效的是前者。
- 查运行中 worker 进程的 fd 数量：
ls -l /proc/$(pgrep nginx | head -1)/fd | wc -l； - 对比配置：
grep "worker_connections\|worker_rlimit_nofile" /etc/nginx/nginx.conf； - 检查系统限制：
cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files"。
观察连接数是否持续接近配置上限
Nginx 提供 stub_status 模块（需编译启用并配置 location），可实时查看活跃连接状态：
- 开启后访问
/nginx_status，输出如：Active connections: 1023<br/>server accepts handled requests<br/> 123456 123456 789012<br/>Reading: 2 Writing: 10 Waiting: 1011
； - 其中
Active connections值若长期 > 90% 的worker_connections，说明逼近瓶颈； - 特别关注
Waiting数值高且Accepts增长停滞，可能表示新连接被丢弃或排队失败。
排除其他干扰因素
不是所有连接拒绝都源于 worker_connections：
- 客户端频繁短连接 + keepalive 时间短 → 连接反复创建销毁，放大压力；
- 上游服务响应慢或超时 → worker 被长时间占用，看似连接数高；
- 未开启
multi_accept on，导致单次 epoll 事件只处理一个连接，降低吞吐； - 使用了 http_v2 且并发流过多，实际连接数虽未超限，但内存/句柄消耗剧增。
建议结合 netstat -an | grep :80 | wc -l 和 ss -s 对比系统层面连接统计，交叉验证。
