least_conn连接突增需查后端实时活跃连接分布、客户端行为、后端响应能力及配置干扰；核心是验证连接是否真实反映负载，而非算法本身。
排查 Nginx least_conn 模式下短时间连接数突增，核心是确认“谁在连、连得是否合理、后端是否扛得住、Nginx 是否误判”。重点不是看算法本身，而是验证实际连接分布是否符合预期，以及背后的真实负载来源。
查 upstream 实时连接状态
Nginx 自带的 stub_status 只显示总体连接数，无法区分 upstream。必须用 ngx_http_upstream_module 提供的变量或第三方模块（如 nginx-module-vts）获取每个 upstream server 的活跃连接数：
- 启用
nginx-module-vts后访问/status页面，查看Upstreams → [your_upstream] → Active列，确认各 backend 的实时活跃连接是否严重不均（比如某台从 20 突增至 200，而其他仍为个位数） - 若无法加模块，可临时开启
error_log debug并配合log_format记录$upstream_addr和$connection，再用日志抽样分析连接倾向 - 注意：
least_conn仅比较“当前活跃连接数”，不考虑响应时间、队列长度或健康检查延迟，所以某台机器因 GC/锁阻塞导致连接堆积，会被持续选中，形成恶性循环
确认客户端行为是否异常
连接突增往往源于上游调用方变化，而非 Nginx 配置错误：
- 检查 access log 中
time_local和request_time，筛选突增时段内长连接（keepalive复用）或高频短连接（如每秒数百次Connection: close）请求 - 关注 User-Agent、Referer 或特定 Header（如
X-Forwarded-For），识别是否来自新接入的爬虫、监控探针、或某业务方未按约定使用连接池 - 用
ss -nt src :$nginx_port | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20快速定位连接来源 IP 分布，看是否集中于个别客户端
检查后端健康与响应能力
least_conn 前提是后端“能正常响应”，一旦某节点响应变慢或卡住，连接会滞留并越积越多：
- 对比同一时段内各 backend 的
upstream_response_time日志，看是否有节点平均响应时间陡增（如从 20ms 升至 2s+），即使没超proxy_read_timeout，也会拖慢连接释放 - 检查 backend 进程 CPU、线程数、文件描述符使用率（
lsof -p $pid | wc -l）、GC 日志（Java）或慢查询（DB 依赖场景），确认是否存在资源瓶颈 - 留意健康检查配置：若
max_fails=1 fail_timeout=10s，但 backend 偶发 503，Nginx 可能刚恢复就立刻被 flood，加剧不均衡
验证 least\_conn 是否被干扰
某些配置会让 least_conn 失效或效果打折：
- 确认没有混用
ip_hash或hash $arg_token consistent—— 这些指令会覆盖least_conn，导致固定路由 - 检查是否启用了
proxy_buffering off+proxy_request_buffering off，可能导致请求体未读完就转发，后端提前断连，Nginx 误判为“连接已释放”而重复分发 - 若 upstream 使用了
zone（共享内存），确保所有 worker 进程都能访问该 zone；否则各 worker 独立计数，least_conn退化为随机选择
不复杂但容易忽略：先盯住单个 backend 的连接生命周期，再回溯请求来源和 Nginx 决策依据，比直接调参更有效。
