least_conn连接数未递减本质是Nginx活跃连接统计虚高，主因后端未维持长连接、连接泄漏或健康检查缺失；需验证Connection头、keepalive配置、后端真实连接数及max_conns/slow_start干扰。
least_conn 连接数未正确递减，本质是 Nginx 统计的“活跃连接数”长期虚高或滞涨，导致调度失灵——它不是算法坏了，而是连接状态没被及时释放或准确感知。排查需聚焦“连接是否真关了”和“Nginx 是否真知道了”。
检查后端是否主动关闭长连接
若后端每次响应都带 Connection: close 头（常见于调试模式开启、WAF 插入、错误返回或 Spring Boot 未配置 keep-alive），Nginx 就无法复用连接，新请求建连后立刻断开，活跃连接数瞬间归零 → least_conn 退化为随机分发。
- 用 curl -I http://backend-ip:port/path 查响应头，确认无
Connection: close - 在 Nginx access_log 中加入
$upstream_http_connection变量，观察实际收到的 Connection 值 - 后端需显式启用长连接：Tomcat 设置
maxKeepAliveRequests > 0；Spring Boot 配置server.tomcat.connection-timeout=-1
验证 keepalive 复用是否生效且不过载
upstream 中 keepalive 32 只是每 worker 缓存上限，若后端不维持空闲连接，或 Nginx 复用池过大，会导致“账面连接数”长期卡在高位，least_conn 误判节点繁忙。
- 在后端执行
ss -tn state established | grep :8080 | wc -l，对比 Nginx stub_status 中对应 server 的 Active connections 是否一致 - 若 Nginx 显示连接数远高于后端真实 ESTABLISHED 数，说明连接泄漏或复用失败
- 降低
keepalive值（如从 64 改为 16），并配keepalive_timeout 30s，加快空闲连接回收
确认健康检查是否掩盖了连接堆积
least_conn 不剔除节点，只挑连接最少的。若某台后端因 GC、锁表或 I/O 卡顿，连接数缓慢上升但未触发失败（如始终返回 200），它会持续被选中，连接越积越多却“不降反升”。
- 检查
error.log中是否有大量upstream timed out或upstream prematurely closed connection，但该节点未被标记为 down - 确保启用了
proxy_next_upstream error timeout http_500 http_502，并为每个 server 配max_fails=2 fail_timeout=15s - 更优方案是启用主动健康检查（如
health_check interval=3 fails=2 passes=2 match=status_ok），避免依赖业务响应
排除 max_conns 和 slow_start 干扰调度逻辑
当某节点达到 max_conns 上限，Nginx 会直接跳过它参与 least_conn 比较——此时它的连接数“卡住不动”，并非未递减，而是被强制隔离。
- 访问
/nginx_status，查看各 upstream server 的 Active connections 是否接近或等于其max_conns值 - 若某节点 Active connections = max_conns 且长期不变，说明它已满负荷，least_conn 自然不再选它
- 新上线节点若配了
slow_start=30s，前 30 秒内连接数增长受限，也会表现为“不递减”假象
