least_conn在高并发下更有效，因其按实时活跃连接数调度，兼顾健康状态、连接复用与容量感知；需配置least_conn、max_fails/fail_timeout、proxy_next_upstream、keepalive及max_conns，并用slow_start防雪崩。
最小连接算法（least_conn）在高并发场景下能显著提升后端响应率，但前提是它真正“看清”了后端的真实负载——不是靠理论值，而是靠健康状态、连接复用效率和容量感知的协同作用。
为什么 least_conn 在高并发下更有效
轮询策略按固定顺序派发请求，不感知后端实际占用。当某台机器正处理一个 5 秒报表或模型推理任务时，轮询仍会继续往它身上压新请求，连接数快速堆积，而其他节点空闲。least_conn 则实时比较活跃连接总数（含 keepalive 空闲连接），天然倾向轻载节点，尤其适合：
- 长连接多的场景（如 WebSocket、HTTP/2、大文件上传）
- 后端性能异构（不同规格机器混部）
- 接口响应时间波动大（20ms 缓存读 vs 8s 导出）
四个必须配齐的配置项
只写 least_conn; 不起作用。以下四项缺一不可：
-
显式启用 least_conn：upstream 块内必须声明
least_conn; -
每个 server 配 max_fails 和 fail_timeout：例如
server 10.0.1.10:8080 max_fails=2 fail_timeout=15s;，否则宕机节点不会被剔除 -
启用被动健康检查：通过
proxy_next_upstream error timeout http_500 http_502;触发重试，并结合 max_fails 生效 -
合理配置 keepalive：upstream 内加
keepalive 32;，后端也要开启连接池（如 Tomcat 的maxKeepAliveRequests > 0），避免短连接频繁建连干扰计数
用 max_conns 体现节点真实容量
least_conn 本身不支持 weight，但可通过 max_conns 实现软性限流与能力区分：
- 高性能节点设
max_conns=2000 - 普通节点设
max_conns=800 - 当某节点活跃连接数 ≥ max_conns 时，Nginx 自动跳过该节点，即使它当前连接数仍是“最少”之一
这比单纯依赖 weight 更贴近真实资源瓶颈，尤其在 CPU 或内存受限的计算密集型服务中效果明显。
上线新节点要防雪崩
扩容或替换实例时，直接加入 least_conn 组容易引发冷启动冲击。建议为新 server 加 slow_start=30s：
- 连接权重从 0 开始，30 秒内线性升至满额
- 避免瞬间涌入大量请求导致新节点过载、触发健康检查失败、又被踢出循环
- 配合 max_fails 使用，可平稳过渡流量
