least_conn算法通过将新请求优先分发给当前活跃连接数最少的健康后端节点，有效缓解长耗时请求导致的负载不均；它实时依据tcp连接数（含keepalive空闲连接）调度，需配合健康检查、max_conns限流和合理keepalive配置才能生效。
最少连接算法（least_conn）能有效缓解系统压力尖峰，关键不在于“选连接少的机器”，而在于它让新请求主动绕开正在处理长耗时任务的节点，避免连接堆积引发的级联延迟和超时雪崩。
为什么轮询扛不住压力尖峰
轮询是静态分发，不管后端是否卡住。比如一个报表导出接口要 8 秒，而其他接口只要 20ms。轮询仍会把第 5 个请求继续打到那台正忙于导出的服务器上——它的活跃连接数快速堆高，后续请求排队、超时、重试，形成恶性循环。监控上看是连接数飙升但 CPU 并不高，典型的“隐性过载”。least_conn 则实时感知这个状态，把新请求导向连接数为 0 的空闲节点，天然切断堆积链路。
真正起效的三个必要条件
-
健康检查必须启用：least_conn 不会自动剔除宕机或假死节点。必须配置
max_fails和fail_timeout，或使用主动 health_check，否则连接数为 0 的故障节点仍会被持续选中 -
keepalive 要配且配得合理：Nginx 与后端之间的空闲长连接会计入活跃连接总数。若 upstream 中
keepalive 100，每 worker 就会为每个后端预留最多 100 条空闲连接，可能虚高账面连接数。建议从 16–32 开始调优 -
后端需支持连接复用：如果后端每次响应完就断开 TCP 连接（即无 keep-alive），那么活跃连接数 ≈ 当前请求数，least_conn 实际退化为近似轮询。Tomcat 需设
maxKeepAliveRequests > 0，Spring Boot 可配server.tomcat.connection-timeout
应对异构与突发的进阶用法
当后端性能不均（如混用 8 核与 4 核机器）或流量突发时，单靠 least_conn 不够：
- 用
max_conns做软性容量控制：高性能节点设max_conns=2000，普通节点设max_conns=800，超出即排队或返回 503 - weight 仍有作用：多个节点连接数相同时，least_conn 会退回到加权轮询逻辑，所以仍可设
weight=2提升高配节点被选中的概率 - 配合
proxy_next_upstream error timeout http_500 http_502：后端因过载返回 502 或超时时，Nginx 自动换节点重试，不卡死在已压垮的实例上
验证是否真起效的方法
别只看日志或平均响应时间。重点观察：
- 通过
stub_status或 Prometheus 指标，确认各后端Active connections是否长期均衡（如波动在 ±3 内），而非某台持续高于均值 30% 以上 - 对比
$upstream_header_time和$upstream_response_time：前者稳定、后者飙升，说明问题在后端业务；两者同步升高，才可能是 Nginx 层瓶颈（如worker_connections不足） - 压测时模拟含 10% 长连接（如 WebSocket）+ 5% 超时请求，看 P95 延迟是否比轮询低 30% 以上
