least_conn策略下负载不均主因是连接数统计失真或节点未被正确纳入调度：需排查weight/max_conns干扰、健康检查误剔、keepalive配置不一致、conntrack限制及前置LB连接复用等隐性因素。
在 Nginx 的 least_conn 负载均衡策略下，理论上新连接会优先落到当前活跃连接数最少的上游节点上。但实际中常出现部分异构节点（如性能、配置、网络路径不同）负载远高于其他节点，甚至持续空闲，这通常不是算法本身缺陷，而是受多种隐性因素干扰。排查需聚焦“连接数统计是否真实反映负载”和“节点是否被正确纳入比较范围”两个核心。
确认 upstream 配置未意外启用权重或其它干扰策略
Nginx 的 least_conn 仅对处于健康状态且未被临时摘除的节点生效。若配置中混用了 weight、max_conns 或开启了 slow_start，会显著改变调度行为：
- weight 不为 1 时，least_conn 实际按 “当前连接数 / weight” 比值比较，高权重节点更容易被选中，即使其连接数绝对值更大；
- 设置了 max_conns 且某节点已达上限，该节点会被跳过，后续连接不断压向剩余节点，造成雪球效应；
- slow_start 启用期间，新恢复节点连接数权重逐步上升，初期几乎不承接流量，易被误判为“不均”。
检查配置中所有 server 行是否干净：无 weight、无 max_conns、无 slow_start，或明确理解其影响后再保留。
验证节点健康检查是否一致且及时
least_conn 只在 健康节点池 中选择。若某节点因健康检查失败被标记为 unavailable（即使它实际可用），它将完全退出调度，所有连接涌向其余节点：
- 检查
health_check或proxy_next_upstream相关配置，确认各节点的检查间隔、超时、失败次数阈值是否统一； - 特别注意异构节点响应时间差异——慢节点可能频繁触发
http_504或timeout判定，被反复踢出； - 用
curl -I http://nginx_status（需启用stub_status）或 OpenResty 的ngx.var.upstream_addr日志，观察实际参与调度的节点列表是否稳定。
检查连接生命周期是否被非预期截断或复用
least_conn 统计的是 当前活跃的 TCP 连接数，而非请求数。若某些节点上连接被快速关闭（如客户端短连接 + keepalive 关闭）、或另一些节点被强制长连接复用，会导致连接数失真：
- 确认后端服务是否统一开启/关闭 HTTP keepalive，避免部分节点维持大量 idle 连接而“虚高”连接数；
- 检查 Nginx 是否配置了
proxy_http_version 1.1和proxy_set_header Connection ''，否则默认用 HTTP/1.0 与后端通信，无法复用连接，导致连接数剧烈抖动； - 抓包或用
ss -tnp | grep :port在 Nginx 机器上实时观察各 upstream IP 的 ESTAB 连接数，对比nginx -T | grep -A 20 "upstream"输出的理论节点列表，确认统计源是否一致。
排除内核或网络层连接跟踪干扰
在高并发场景下，Linux conntrack 表满、TIME_WAIT 过多、或 SNAT/NAT 设备会话老化异常，可能导致 Nginx 看到的连接状态与真实不符：
- 运行
conntrack -S查看 conntrack 表使用率，若entries接近max，需调大net.netfilter.nf_conntrack_max； - 执行
ss -s | grep -i "time_wait"，若 TIME_WAIT 连接远超正常水平（如 >6w），检查是否后端主动关闭连接，考虑调整net.ipv4.tcp_tw_reuse或后端连接管理逻辑； - 若 Nginx 前有 LVS/F5/云 LB，确认其是否做了连接复用或连接池，导致 Nginx 视角下的“连接数”不能反映后端真实压力。
