least_conn策略下连接数统计异常的核心是Nginx仅统计ESTABLISHED/SYN_RECV等活跃长连接，不包含TIME_WAIT或空闲keepalive连接；需通过upstream_zone+stub_status、ss命令比对、检查ip_hash覆盖、健康检查干扰及debug日志验证。
排查 least_conn 策略下连接数统计异常，核心是确认 Nginx 实际使用的“连接数”是否与预期一致——它只统计当前活跃的、尚未关闭的长连接（即处于 ESTABLISHED 或 SYN_RECV 等内核 socket 状态的连接），不包含已进入关闭流程（如 TIME_WAIT）或请求处理完但连接未释放的空闲 keepalive 连接。
检查 upstream 中各 server 的实时活跃连接数
Nginx 自身不直接暴露每个 upstream server 的当前连接数，但可通过以下方式间接验证：
- 启用
stub_status模块并配合upstream\_zone（需 Nginx ≥ 1.9.0）：在upstream块中添加zone backend 64k;，再通过status接口（如/nginx_status）或第三方模块（如nginx-module-vts）查看各 server 的 active connection 数； - 用系统命令比对：在 worker 进程绑定的端口上执行
ss -tn src :，观察后端 IP 的连接分布是否符合 least_conn 的倾向；| awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr - 注意：若后端启用了 keepalive，且客户端复用连接，Nginx 可能长期持有到后端的空闲连接（
keepalive指令控制），这些连接仍被计入least_conn统计，导致“看似不均”。
确认 least\_conn 是否被其他配置覆盖或绕过
least_conn 是 upstream 的负载均衡算法，但某些场景下它不会生效：
- 存在
ip_hash、hash、random等其他负载均衡指令时，least_conn会被忽略； - 使用了
proxy_next_upstream且发生失败重试，默认会跳过原选中的 server，下次选择可能不再走 least_conn 逻辑（尤其在 fastcgi_pass / grpc_pass 等非 proxy 场景下行为略有差异）； - 启用了
least_time（需商业版 NGINX Plus）或第三方模块，会完全替代least_conn； - upstream 中某 server 被标记为
down或因健康检查失败被临时摘除，剩余 server 的连接数可能快速累积，显得“不均衡”实为被动集中。
验证健康检查与连接生命周期是否干扰统计
least_conn 统计的是“当前由该 worker 持有并活跃”的连接，而健康检查（如 health_check）本身也建连，可能短暂抬高某 server 的计数：
- 检查
health_check配置的 interval 和 jitter，避免高频探测造成连接抖动； - 确认后端服务是否及时关闭连接：若后端响应后不主动 close，Nginx 侧的连接会持续计入，直到超时（
proxy_read_timeout/proxy_send_timeout）或客户端断开； - 用
tcpdump抓包对比：在 Nginx 和后端之间抓取 SYN/SYN-ACK/FIN 包，确认连接建立与释放节奏是否与least_conn表现一致。
日志与调试辅助定位
开启详细日志可帮助回溯每次请求的 upstream 选择过程：
- 在 http 或 upstream 上下文中添加
log_format upstream_log '... $upstream_addr $upstream_bytes_received';，观察实际转发目标； - 启用
error_log /path/to/error.log debug;（需编译时含--with-debug），搜索"least_conn"或"select peer"相关行，可看到每次选点时各 server 的连接数快照； - 注意：debug 日志量极大，仅用于短时排查，生产环境慎用。
