“worker_connections are not enough”表明Nginx单worker进程并发连接数超限，需同步核查worker_connections、worker_rlimit_nofile及系统ulimit -n三者是否匹配，并结合upstream连接翻倍、长连接占用或后端延迟等场景精准调优。
error_log 是排查 Nginx 并发连接断开问题最直接、最可靠的线索入口——它不记录“发生了什么请求”，而是忠实记录“为什么连接没能维持住”。很多断连看似随机，实则已在 error.log 中反复报错，只是被默认的 error 级别过滤掉了。
重点看 error_log 里的连接级错误关键词
不是所有断连都表现为 502 或超时，真正指向并发连接层问题的线索往往藏在底层 errno 和上下文描述中：
-
worker_connections are not enough→ 单 worker 进程连接数已达硬上限，新连接被直接拒绝（非超时，是立即失败） -
upstream prematurely closed connection→ 后端提前断开，若高频出现，说明 upstream 连接池耗尽或长连接复用失效，间接加剧 Nginx 连接压力 -
recv() failed (104: Connection reset by peer)→ 客户端或中间设备主动重置，常见于空闲连接被防火墙/NAT 切断，此时proxy_read_timeout和 TCP keepalive 若未协同生效，就会批量触发 -
connect() failed (111: Connection refused) while connecting to upstream→ 反向代理场景下，后端拒绝连接，若伴随upstream connection is busy，说明 Nginx 的 upstream keepalive 池已满，被迫频繁新建连接，迅速耗尽worker_connections
调高日志级别才能暴露真实瓶颈
默认 error 级别会掩盖关键前置信号。针对并发断连，建议在对应 server 或 location 块中临时启用：
error_log /var/log/nginx/debug_conn.log info;
info 级即可捕获连接建立、keepalive 复用、upstream 选择等关键路径；若需深挖，再升至 debug（需编译时含 --with-debug）。重点关注：
-
http proxy connect→ 是否每次请求都新建 upstream 连接？ -
upstream connection reusedvsupstream connection created→ 复用率是否异常低？ -
keepalive timeout→ 是否因proxy_socket_keepalive未开启，导致坏连接未及时清理？
结合日志与运行时状态交叉验证
单看日志容易误判。必须同步检查：
-
curl http://127.0.0.1/nginx_status→ 观察Active connections是否持续逼近worker_connections × worker_processes -
ss -s | grep "tcp:"→ 真实 ESTABLISHED 连接数是否远超配置预期 -
lsof -p $(pgrep nginx | head -1) | wc -l→ 单个 worker 打开的 fd 数是否接近worker_connections上限
注意反向代理场景的连接倍增效应error_log 中若报错带 while connecting to upstream 后缀，说明瓶颈不在客户端接入侧，而在 Nginx 主动连后端环节。此时一个请求实际占用 2 个连接（client ↔ nginx + nginx ↔ upstream），若后端响应慢或未启用 keepalive，连接堆积速度翻倍——但多数人只按 client 侧估算 worker_connections，导致配置严重低估。
不复杂但容易忽略
