least_conn不降低延迟，而是避免新请求进入已卡住节点以抑制雪崩；它仅统计活跃连接数，不感知响应时长，需配合主动健康检查、proxy_next_upstream timeout、合理keepalive及max_conns才能有效。
Nginx 最少连接算法（least_conn）在高延迟后端环境中不是“自动变聪明”，而是暴露问题更快、放大调度偏差更明显——它本身不降低延迟，但能避免把新请求继续塞给已经卡住的节点，从而抑制延迟雪崩。
高延迟场景下 least_conn 的真实行为
它只看“当前有多少连接没关”，不看这些连接花了多久还没返回
比如某台后端因数据库锁或 GC 暂停，30 个请求卡在响应阶段，连接数持续为 30；另一台刚空闲，连接数为 0。least_conn 会立刻把新请求导过去，而不是等那 30 个慢请求结束。连接数统计是实时的，但“慢”不等于“不可用”
只要 TCP 连接还活着、没超时、没被健康检查标记为失败，least_conn 就认为它“可用”，仍参与比较。所以高延迟节点可能长期维持中低连接数（比如 5–10），却持续拖慢整体 P95 延迟。多节点连接数相近时，退回到加权轮询，而权重无法反映实际处理速度
若三台机器连接数都是 8，least_conn 不会挑“响应快的”，而是按weight分发——此时 weight 若未根据性能动态调整，就变成静态偏置，反而加剧不均。
关键配置必须同步强化，否则 least_conn 会失效
-
健康检查必须主动且敏感
被动检查（靠max_fails+fail_timeout）依赖失败响应，对高延迟节点无效——它不报错，只是慢。必须启用主动健康检查：upstream backend { least_conn; # 主动探测，3秒一次，连续2次失败即摘除 health_check interval=3 fails=2 passes=2; match http_2xx; server 10.0.1.10:8080; server 10.0.1.11:8080; } -
proxy_next_upstream 至少包含 timeout 和 http_504
后端响应慢到超时（默认 60s），Nginx 默认不会重试。需显式开启：proxy_next_upstream error timeout http_504; proxy_next_upstream_timeout 10s; # 整体重试时限 proxy_next_upstream_tries 2; # 最多重试 2 次
-
keepalive 设置要克制，避免空闲连接虚高连接数
如果 upstream 配了keepalive 200，而某台后端空闲维持了 150 条 keepalive 连接，它的“账面连接数”就是 150 ——哪怕实际业务请求为 0，least_conn 也会绕开它。建议设为 16–32，并配合：proxy_http_version 1.1; proxy_set_header Connection '';
-
用 max_conns 实现软性容量隔离
高延迟往往伴随资源耗尽。可限制单节点最大并发接入量，防止拖垮整组：upstream backend { least_conn; server 10.0.1.10:8080 max_conns=500; # 旧机型，易堆积 server 10.0.1.11:8080 max_conns=1200; # 新机型，吞吐强 }当连接数达上限，Nginx 会跳过该节点，选下一个最少的——这是 least_conn 的隐含保护机制。
监控上怎么看是否真起效
别只盯 $upstream_connect_time，重点看三个指标组合：
- 各后端的
active connections（通过/stub_status或 Prometheus）是否随延迟升高而显著分化 -
upstream_header_time稳定但upstream_response_time拉长 → 问题在后端逻辑，least_conn 正常分流 - 两者同步拉长，且某节点
active connections持续高位 → 健康检查没生效，或max_conns设得过大
本质上，least_conn 在高延迟环境里不是“解药”，而是“探针”——它让负载不均和节点异常更快浮出水面，但能否治好，取决于你配不配得准、查不查得勤、切不切得快。
