least_conn算法通过将新请求优先分发给当前活跃连接数最少的健康后端节点，有效缓解长耗时请求导致的负载不均；它必须置于upstream块首行，不可与ip_hash等策略混用，且需配合健康检查、keepalive复用及max_conns容量控制才能生效。
最少连接调度算法（least_conn）能提升响应质量，关键不在“选连接少的机器”，而在于让请求避开正在处理长任务的节点——尤其适合后端耗时差异大、计算资源波动明显的场景。
least_conn 必须放在 upstream 块内部
它不是 http 块下的全局指令，必须作为 upstream 定义的第一条语句出现：
- 正确写法：
upstream backend { least_conn; server 10.0.1.10:8080; ... } - 错误写法：把
least_conn;放在upstream外或http块顶层，Nginx 会报错 “directive is not allowed here” - 不能和
ip_hash、hash等策略共存于同一 upstream 块
只靠 least_conn 不够，必须配健康检查
算法只看连接数，不判断后端是否真可用。若某台机器卡住但 TCP 连接未断，least_conn 仍会持续转发请求过去。
- 至少配置
max_fails=2 fail_timeout=15s在每个server行后 - 启用被动检查：
proxy_next_upstream error timeout http_500 http_502; - 有条件建议加主动健康检查（如 Nginx Plus 或开源 patch），每 3 秒探测一次 HTTP 状态码
连接复用直接影响算法效果
如果每次请求都新建 TCP 连接，活跃连接数瞬间增减，least_conn 就变成伪随机分配。
- upstream 内加
keepalive 32;，复用空闲连接 - 后端服务也要开启连接池（如 Tomcat 的
maxKeepAliveRequests> 0） - 转发时显式设置：
proxy_http_version 1.1; proxy_set_header Connection '';
结合权重与慢启动应对真实负载差异
服务器硬件性能不同，或新实例上线时，纯 least_conn 可能引发不均衡或雪崩。
- 按 CPU/内存比例设
weight，比如高配节点写server x weight=2; - 扩容时给新节点加
slow_start=30s，让连接权重从 0 平滑升至满额 - 避免单点过载：监控各后端
active connections，持续接近worker_connections上限时需扩容或优化后端逻辑
