least_conn真正起效需确保连接数真实反映后端负载，须通过主动健康检查、合理keepalive配置、max_conns容量控制及实时监控协同实现，而非仅选连接最少节点。
least_conn 看似简单，实际在高并发、长连接或后端不稳的场景下，很容易“选了最少连接的节点，却打到了最慢的机器”。问题往往不出在算法本身，而在于它依赖的底层数据是否真实、健康判断是否及时、连接复用是否到位。排查要从“Nginx看到的连接数”是否等于“后端真实的负载压力”这个核心出发。
一、确认 least_conn 是否真正生效
很多人配了 least_conn 却没效果，第一步先验证它有没有被正确加载和触发：
- 检查 upstream 块中是否明确写了 least_conn; —— 它必须单独成行，不能跟在 server 后面；
- 运行 nginx -t 确保配置语法无误，再用 nginx -V 2>&1 | grep -o 'with-http-upstream' 确认模块已编译；
- 打开 stub_status（需编译时含 http_stub_status_module），访问 /nginx_status，观察各 server 的 Active connections 是否随请求动态变化且分布不均——如果始终接近相等，说明 least_conn 没起作用，大概率是 keepalive 未生效或后端强制断连；
- 用 curl -I 多次请求，配合 tcpdump -i lo port 8080 抓包，看新连接是否真的落在连接数更少的后端 IP 上。
二、检查连接数统计是否失真
least_conn 只看“Nginx 到后端的活跃 TCP 连接数”，但这个数字极易被短连接、空闲连接、连接池配置错误扭曲：
- 后端响应头是否含 Connection: close？哪怕只在 500 错误或调试模式下出现，都会让连接无法复用，导致每次请求都新建+关闭，least_conn 统计瞬间归零，退化为随机分发；
- upstream 中 keepalive 值是否合理？设为 200 会导致大量空闲连接长期占位，把“账面连接数”人为拉高；建议按 worker 数 × 后端单实例平均并发反推，常见值为 16–64；
- location 块中是否漏了 proxy_http_version 1.1 和 proxy_set_header Connection ''？缺一不可，否则 Nginx 会沿用 HTTP/1.0 默认行为，主动发送 Connection: close；
- 后端服务是否开启连接池？例如 Tomcat 要设 maxKeepAliveRequests > 0、keepAliveTimeout > 5s，Spring Boot 对应 server.tomcat.max-keep-alive-requests。
三、验证健康检查是否及时剔除“假空闲”节点
连接数少 ≠ 服务健康。一个卡在 GC、锁表或 I/O 等待的后端，可能连接数很低，但所有新请求都超时。least_conn 会持续把流量打过去，加剧雪崩：
- 被动检查（proxy_next_upstream）太滞后：必须配 error timeout http_500 http_502，并设 max_fails=2 fail_timeout=10s，否则故障节点要等多次失败才下线；
- 主动检查更可靠：Nginx Plus 或打过 health_check 补丁的开源版，可用 health_check interval=3 fails=2 passes=2 match=status_ok，每 3 秒探测一次，避免“HTTP 200 但业务已死”；
- 健康检查路径务必轻量、绕过缓存与鉴权，否则检查本身会压垮后端；
- 检查 error.log 是否有类似 upstream timed out (110: Connection timed out) 或 no live upstreams 的日志，这是健康检查已生效的关键信号。
四、排查 TCP 长连接协议是否走错模块
WebSocket、gRPC、Redis、MySQL 等不是 HTTP 协议，HTTP 上游的 least_conn 完全不生效：
- 运行 nginx -V | grep with-stream，确认 stream 模块已启用；
- 检查配置是否写在 stream { ... } 块内，而非 http 块；
- stream upstream 中同样支持 least_conn 和 max_conns，但不支持 proxy_* 指令，要用 proxy_pass + proxy_timeout 等 stream 专用指令；
- 若用 Ubuntu/Debian 官方源安装，需手动 load_module /usr/lib/nginx/modules/ngx_stream_module.so；CentOS 则需额外安装 nginx-mod-stream 包。
五、监控与交叉验证真瓶颈
只盯 active connections 是最大误区。连接数低但延迟高，说明问题不在连接层：
- 用 $upstream_connect_time 和 $upstream_header_time 分别记录建连耗时与首字节返回时间；前者突增 → 网络或 Nginx 侧问题，后者稳定但 $upstream_response_time 飙升 → 后端业务逻辑瓶颈；
- Prometheus + nginx-lua-prometheus 可采集每个 upstream server 的连接数、失败数、响应时间直方图，做多维下钻；
- 上线新节点务必加 slow_start=30s，避免冷启动瞬间涌入连接冲垮后端连接池；
- max_conns 不是可选项，而是安全阀：高性能节点设 max_conns=3000，普通节点 max_conns=1200，一旦达到即跳过，比单纯依赖连接数更贴近真实容量。
