关键不是看“是否超了”，而是确认Nginx是否已因该限制实际拒绝连接：查error.log中“accept() failed (11/24)”等错误，验证/proc/$(pgrep nginx)/limits中FD上限、stub_status中Active connections是否长期＞90%×worker_connections，并排除net.core.somaxconn溢出干扰。
排查客户端连接数超出 worker_connections，关键不是看“是否超了”，而是确认“Nginx 是否已因该限制而实际拒绝连接”。真正的问题往往藏在日志、系统资源和运行时状态的交叉印证中，而非单纯比对数字。
重点查 error.log 中的拒绝线索
Nginx 不会主动报“超出 worker_connections”，但会在无法接受新连接时留下明确错误。打开 /var/log/nginx/error.log，搜索以下关键词：
- accept() failed (11: Resource temporarily unavailable)：最常见，表示 accept 队列已满或 worker 连接槽位耗尽；
-
accept() failed (24: Too many open files)：说明进程级文件描述符（FD）已用尽，
worker_connections实际被系统限制卡死； - worker_connections are not enough while connecting to upstream：反向代理场景下，既需连客户端又需连后端，FD 消耗翻倍，易触发该提示。
验证 worker 进程真实可用的文件描述符上限
worker_connections 能否生效，取决于它是否 ≤ 当前 worker 进程被允许打开的最大 FD 数。执行三步验证：
- 查进程实际生效的 FD 上限：
cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files"； - 查 Nginx 配置中是否设了
worker_rlimit_nofile，且值 ≥worker_connections； - 查系统级限制：
ulimit -n（启动 Nginx 的用户环境），若为 1024 或 4096，即使配置了 65536 也无效。
观察 stub_status 实时连接状态
启用 ngx_http_stub_status_module 后访问 /nginx_status，重点关注：
-
Active connections：若长期 > 90% ×
worker_connections，说明逼近瓶颈； - Waiting 值持续偏高（如 > 80% Active），且 Accepts 增长停滞，代表新连接进不来，可能已被内核丢弃或排队失败；
- 对比
Active connections和worker_processes × worker_connections总和，若前者接近后者，说明整体连接池饱和。
排除内核 listen 队列溢出干扰
连接还没到 Nginx，就可能被内核丢弃。这会导致客户端看到“连接超时”或“Connection refused”，但 Nginx 日志无记录。检查：
- 当前全连接队列使用情况：
ss -lnt | grep :80，看 Recv-Q 列是否长期非零； - 系统
net.core.somaxconn值：sysctl net.core.somaxconn，建议设为 65535 并写入/etc/sysctl.conf； - 确保 Nginx 配置中开启
multi_accept on;，避免单次只取一个连接造成队列积压。
