least_conn负载不均主因是连接数统计失真或后端健康状态异常，需验证活跃连接是否真实反映压力、检查keepalive复用、健康检查配置及客户端/后端连接行为一致性。
排查 least_conn 模式下后端负载不均，核心不是怀疑算法本身失效，而是要验证「连接数」是否真实反映了后端实际压力，以及 Nginx 是否按预期感知和分发连接。
确认 upstream 中的 least_conn 配置已生效
检查 Nginx 配置中 upstream 块是否明确启用了 least_conn，且没有被其他指令覆盖：
- 确保写法是
least_conn;（不能漏掉分号），且位于upstream块内，不在server行上 - 排除干扰：确认没混用
ip_hash、hash $request_uri等会覆盖负载策略的指令 - 重载后验证：执行
nginx -t && nginx -s reload，再用nginx -T输出当前生效配置，搜索least_conn确认位置和上下文
观察真实活跃连接数是否“可比”
least_conn 只看每个后端当前的活跃 TCP 连接数（即 keepalive 连接 + 正在处理的请求连接），不考虑响应时间、CPU、队列长度等。若连接行为差异大，就会失衡：
- 检查后端是否启用并复用 HTTP/1.1 keepalive：若某些后端主动关闭连接（如设置
Connection: close或短 timeout），其连接数始终偏低，Nginx 就会持续往它身上打流量 - 检查客户端行为：长连接客户端（如 App、gRPC）vs 短连接浏览器请求，会导致连接数统计维度失真
- 用
ss -tn src :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr或netstat -anp | grep :80 | grep ESTAB | awk '{print $5}' | cut -d: -f1 | sort | uniq -c在 Nginx 本机统计各后端 IP 的 ESTABLISHED 连接数，对比upstream_addr日志或stub_status模块输出是否一致
检查后端健康状态与连接异常回收
Nginx 在连接失败（如 reset、timeout）后会临时标记 server 为不可用，并减少分发——但这个过程可能放大不均：
- 查看 error.log 是否频繁出现
connect() failed、connection refused、connection timed out，尤其集中在某台后端，说明它可能偶发卡顿或丢包，导致连接快速失败又重建，Nginx 误判为“轻负载”而多派发 - 确认
max_fails和fail_timeout设置是否过松（如默认max_fails=1 fail_timeout=10s），一次超时就触发摘除，恢复后又立即加回，形成震荡 - 用
curl -I http://your-nginx-ip/nginx_status（需启用ngx_http_stub_status_module）查看各 upstream server 的Active connections数，结合Accepted / Handled / Requests推断是否某台长期 Active 很低但 Requests 却高（说明连接短命、复用差）
验证请求特征是否绕过 least_conn 逻辑
某些场景下，请求根本没走 least_conn 路径：
- 使用了
proxy_pass http://upstream_name，但 upstream 名字拼错，Nginx 回退到 DNS 解析或默认轮询，日志里会出现no resolver defined或直接报 502 - 启用了
proxy_buffering off+ 大文件上传，可能导致连接长时间 hang 在 read 阶段，Nginx 仍计为 active，但后端实际已卡住，后续请求却因“连接数少”继续打过去 - 存在多个 upstream 块或嵌套 if + proxy_pass，实际路由未落到配置了
least_conn的那个块
不复杂但容易忽略：least_conn 不是万能均衡器，它只解决“谁此刻连接最少”，而不是“谁此刻最空闲”。真正压不平，往往要配合后端连接池调优、统一 keepalive 设置、加上主动健康检查，甚至换用更智能的方案如一致性哈希 + 权重动态调整。
