排查nginx负载均衡集群节点连接异常，核心是区分“连不上”（tcp层失败，需检查telnet/nc、防火墙、监听状态）与“连得上但不工作”（应用层问题，如健康检查误判、keepalive失效、$connection_requests持续增长暴露连接未重分配）。
排查 Nginx 负载均衡集群节点连接异常，核心是分清“连不上”和“连得上但不工作”的区别——前者卡在 TCP 层，后者往往藏在连接复用、健康检查或协议协商细节里。
先确认四层连通性是否真实成立
别跳过这步。很多“连接异常”其实是网络基础没通：
- 在 Nginx 服务器上执行 telnet 后端IP 端口 或 nc -zv 后端IP 端口，看能否建立 TCP 连接；失败说明防火墙、安全组、路由或后端未监听
- 若 telnet 成功但业务不通，再用 curl -H "Host: example.com" http://后端IP:端口/health 测试应用层响应，排除 TLS 握手、证书、HTTP 头等干扰
- 注意：云环境要检查目标组注册状态（如 AWS ALB）、服务发现配置（如 Consul）、以及容器网络（如 Docker bridge 或 CNI 插件是否隔离了流量）
查健康检查是否在“误判”或“失能”
节点明明活着，却被标记为 DOWN，这是高频假象：
- 检查健康检查路径是否真实存在且返回 2xx —— 比如配了
/healthz，但后端只暴露/actuator/health - 确认
max_fails和fail_timeout是否过严：高延迟链路下max_fails=3 fail_timeout=10s容易把慢节点反复踢出 - 若用第三方模块（如
nginx_upstream_check_module），需验证 check 接口是否可访问、返回码是否匹配配置；原生proxy_next_upstream只转发失败请求，不摘除节点
看连接状态分布是否真实均衡
连接数少 ≠ 负载低，长连接可能卡死在某节点：
- 启用
log_format加入 $upstream_addr 和 $connection_requests，观察同一客户端的多次请求是否始终落到同一台后端；若$connection_requests持续增长（如 1→124），说明连接未被重分配 - 在各后端机器运行 ss -tn state established | grep :端口 | wc -l，对比实际 ESTABLISHED 连接数；若某节点远高于其他，再查它是否处理慢、线程阻塞或连接池耗尽
- 关注 error_log 中 "upstream connection is busy" —— 这表示 keepalive 连接池空了，Nginx 被迫新建连接，导致 least_conn 失效
抓关键日志交叉验证行为
单看 access_log 或 stub_status 都不够，必须三处对齐：
-
access_log：确认请求是否真发往后端（
$upstream_addr非空）、是否超时（$upstream_response_time显著偏高） - error_log debug 级：开启后重点搜 "no live upstreams"（所有节点 max_conns 满）、"connect() failed (111)"（后端拒绝）、"upstream timed out"（连接或响应超时）
-
stub_status + 后端 ss 统计：Nginx 的 Active connections 是总连接数，需结合后端
ss -s中的 TCP 行，判断是客户端到 Nginx 卡住，还是 Nginx 到后端卡住
