least_conn统计不准的根本原因是nginx的活跃连接数与后端真实负载脱节，主因包括keepalive未启用、后端连接未及时释放、日志字段误读、版本或配置冲突等。
least_conn 统计不准，本质是 Nginx 看到的“活跃连接数”和后端真实承载压力脱节。问题不在算法本身，而在连接生命周期管理是否到位——短连接、keepalive 失效、后端不复用、日志字段误读，都会让这个数字失真。
检查 keepalive 是否真正启用并生效
没有 upstream keepalive，least_conn 就失去意义：每个请求新建连接又立刻关闭，Nginx 统计的活跃连接数始终趋近于 0，调度退化为随机分配。
- 确认 upstream 块中明确配置了 keepalive 32;（建议值 16–64，按 worker 进程数调整）
- 在 proxy_pass 所在的 location 中，必须同时设置：
proxy_http_version 1.1;
proxy_set_header Connection ''; - 后端服务也要支持长连接：Tomcat 调大
keepAliveTimeout，Spring Boot 检查server.tomcat.max-keep-alive-requests，FastAPI/Uvicorn 设置--keep-alive 5 - 验证方法：压测时在后端执行
ss -tn state established | grep :8080 | wc -l，若连接数远低于并发量且波动剧烈，说明 keepalive 未生效
排查后端连接未及时释放或卡死
least_conn 只看 TCP 连接是否 ESTABLISHED，不管它是否在干活。一个慢查询、GC 停顿、线程阻塞，会让连接长期挂起却不关闭，Nginx 却以为“它还空着”，持续导流。
- 登录各后端服务器，运行
ss -tn state established '( sport = :8080 )' | wc -l，对比各节点数值；若某台显著偏高，再查其应用线程状态（如 Java 的jstack、jstat -gc） - 检查数据库连接池监控（HikariCP 的
ActiveConnections、Druid 的ActiveCount），确认是否因慢 SQL 或连接泄漏导致连接堆积 - 观察 Nginx error_log 中是否频繁出现 "upstream connection is busy"——这表示 keepalive 连接池已空，Nginx 被迫新建连接，least_conn 统计逻辑被绕过
核对日志字段是否反映真实连接归属
别只看 $upstream_addr，它记录的是本次转发目标，但无法体现该连接是否复用、是否来自同一客户端长连接。错误归因常源于混淆“请求数”和“连接数”。
- 在 log_format 中加入 $connection_requests 字段，它表示该 TCP 连接上已处理的请求数；若某后端的该值持续增长（如从 1 到 124），说明连接未被重分配，least_conn 实际未参与后续调度
- 避免用
awk '{print $NF}' access.log | sort | uniq -c统计请求数来反推连接分布——短连接下请求数多 ≠ 连接数多 - 正确做法：结合
$upstream_addr和$upstream_response_time，筛选出响应时间 >3s 的请求，看它们是否集中打向同一台后端；再比对该后端的实际 ESTABLISHED 连接数
验证 Nginx 版本与配置是否被意外覆盖
least_conn 行为受版本、模块和共存指令影响，低版本或冲突配置会导致降级为轮询。
- 运行 nginx -V 确认版本 ≥ 1.3.1；若为 1.15+，可使用加权 least_conn（
server x.x.x.x weight=3仍有效） - 执行 nginx -T 全量输出配置，搜索是否在 upstream 外层 location 或 server 块中误启用了
ip_hash、hash $request_uri或sticky，这些会强制绑定，直接覆盖 least_conn - 检查是否有
max_fails=1 fail_timeout=1s这类过于敏感的失败策略，导致节点被频繁剔除，剩余节点被迫承接全部流量，连接数统计失真
