least_conn算法提升响应均衡性关键在于让请求落到真实空闲度更高的后端节点，需准确感知负载、及时剔除异常节点并复用连接；它仅统计活跃TCP连接数，不读取CPU或响应时间，适合长连接和响应差异大的场景，依赖健康检查与keepalive配置，weight和slow_start用于应对异构与扩容。
最少连接算法（least_conn）能提升响应均衡性，关键不在于“选连接少的”，而在于让请求真正落到当前空闲度更高的后端节点上——前提是 Nginx 能准确感知真实负载、及时剔除异常节点、并复用连接。
只看活跃连接数，不看 CPU 或响应时间
least_conn 统计的是 Nginx 与后端之间已建立、尚未关闭的 TCP 连接数量，反映的是“手头还有几个请求没处理完”。它不读取后端的 CPU 使用率、内存占用或接口响应时长。这意味着：
- 适合长连接场景（如 WebSocket、HTTP/2 流、大文件上传），因为连接持续存在，计数稳定
- 对响应时间差异大的服务更有效（比如同时提供毫秒级 API 和 5 秒报表导出），避免新请求打到正卡在慢任务上的节点
- 当多个后端连接数相同时，自动按 weight 加权轮询，weight 仍参与决策
健康检查必须显式配置，否则算法失效
least_conn 本身不具备故障识别能力。一台后端即使已宕机或卡死，只要 TCP 连接未超时断开，它的活跃连接数可能仍是 0，Nginx 就会继续转发请求。
- 推荐启用主动健康检查：
health_check interval=3 fails=2 passes=2，配合 match 块校验 HTTP 状态码和关键响应头 - 若用开源版，至少配被动探测：
proxy_next_upstream error timeout http_500 http_502，再结合max_fails=2 fail_timeout=15s让失败节点临时下线 - 没有健康检查的 least_conn，实际效果可能比轮询还差
keepalive 是算法生效的前提条件
如果每次请求都新建 TCP 连接，活跃连接数几乎等于请求数，least_conn 就退化为近似轮询——无法体现真实处理压力。
- upstream 中需配置
keepalive 32（数值按并发量调整） - 后端服务要开启 HTTP Keep-Alive，并设合理 timeout（如 Tomcat 的
maxKeepAliveRequests > 0） - Nginx 需加
proxy_http_version 1.1; proxy_set_header Connection '';，主动管理连接复用
weight 和 slow_start 配合应对异构与扩容
纯 least_conn 对硬件性能差异不敏感。例如某节点 CPU 是其他节点的两倍，但连接数相同时不会多分请求。
- 给高性能节点设更高 weight（如
server 10.0.1.10:8080 weight=2），连接数相近时倾向分配更多流量 - 新节点上线时加
slow_start=30s，避免冷启动瞬间涌入大量请求导致雪崩 - weight 和 slow_start 不影响 least_conn 主逻辑，只在连接数相等或节点刚恢复时起作用
