least_conn模式按实时活跃tcp连接数负载，非请求数或缓存值；需确认配置生效、排除冲突指令、验证统计来源为established连接，并通过stub_status、后端监控及日志交叉比对验证一致性。
排查 Nginx least_conn 模式下连接数统计不准，核心是确认 Nginx 是否真实按活跃连接数（即当前正在处理的请求连接）做负载决策，而非误用了其他指标（如请求数、会话数或过期缓存值）。
确认 upstream 配置是否启用并生效
检查 upstream 块中是否明确写了 least_conn，且没有被其他指令覆盖：
- 确保未同时配置
ip_hash、hash或random—— 这些会直接禁用least_conn - 确认没有在
upstream外层（如server或location）通过proxy_pass指向了错误的 upstream 名称 - 执行
nginx -t并重载配置，避免配置未生效导致仍走默认轮询
验证连接数统计来源是否为“实时活跃连接”
least_conn 统计的是每个后端 server 的当前活跃 TCP 连接数（即已建立、尚未关闭的连接），不是请求数、响应数或连接池预建连接。常见偏差来源包括：
-
Keepalive 连接复用：客户端或上游服务保持长连接，Nginx 将其计入活跃连接，但实际无请求在处理。可通过
keepalive_requests和keepalive_timeout限制单连接请求数和空闲时长 -
后端未及时关闭连接：例如上游服务响应后不发 FIN，导致 Nginx 侧连接长时间处于
ESTABLISHED状态。可用ss -tnp | grep :<port></port>查看各 backend IP 的连接状态分布 -
HTTP/2 多路复用影响：一个 TCP 连接承载多个流，Nginx 仍只计为 1 个连接，但后端压力可能已高。此时
least_conn天然不感知流级负载
使用 stub_status + 自定义监控交叉比对
Nginx 官方不直接暴露每个 upstream server 的实时连接数，但可通过以下方式间接验证：
- 开启
stub_status，观察Active connections总量变化趋势，结合请求速率判断是否整体连接堆积 - 在每台 backend 上部署轻量监控（如
netstat -an | grep :<port> | grep ESTABLISHED | wc -l</port>），定时采集各节点实际 ESTABLISHED 连接数，与 Nginx 负载分发日志（开启$upstream_addr）对比：若某节点连接数持续偏高但 Nginx 却很少转发新请求，说明其内部统计滞后或异常 - 临时在
upstream中添加slow_start=30s和max_conns=1024，观察限流是否触发——若max_conns生效，证明连接计数逻辑本身是工作的
检查日志与运行时状态是否一致
启用详细 upstream 日志，定位偏差发生场景：
- 在
location中添加：log_format upstream_log 'upstream=$upstream_addr upstream_connect_time=$upstream_connect_time request_time=$request_time'; - 观察相同时间窗口内，各 backend 的
$upstream_addr出现频次是否与其实际连接数趋势反向（比如 A 节点连接数已达 800，但新请求仍不断打过去） - 注意：Nginx 的连接计数是“连接建立时采样”，非秒级动态刷新。若后端连接突增（如雪崩断连重连），存在短暂窗口无法及时反映
