最少连接策略通过将请求导向当前活跃连接数最少的后端服务器来提升高负载稳定性，需配合max_fails/fail_timeout剔除故障节点、谨慎设置weight、合理配置keepalive timeout，并适用于处理时间差异大或长连接多的场景。
最少连接策略在 Nginx 中不是“万能解药”，但它确实在高负载场景下显著提升了处理稳定性——核心在于它让请求主动避开繁忙节点，而不是机械轮转。
为什么能稳住高负载？
当并发请求激增时，轮询或加权轮询可能把新请求继续发给已堆积大量长连接（如文件上传、WebSocket、慢查询）的后端，导致响应延迟雪崩。最少连接策略实时感知每个 upstream server 的活跃连接数（即当前正在处理的请求），只把新请求导向连接数最低的那台。这相当于给系统装了一个“动态避堵导航”，天然抑制热点集中。
配置要点不只写 least_conn
光在 upstream 块里写 least_conn 远不够。真正影响稳定性的关键配置包括：
- max_fails / fail_timeout：必须配合使用。否则故障节点不会被临时摘除，仍会参与 least_conn 计算，导致请求持续打到不可用服务上；
- weight 参数要谨慎设：加权最少连接（Weighted Least Conn）并非简单按权重放大连接数阈值，而是按权重调整“期望连接数比例”。若某台机器权重设得过高但实际处理能力跟不上，反而会更快达到其“加权后连接上限”，引发不均衡；
- keepalive 连接需关注：Nginx 与后端复用的 keepalive 连接也会计入活跃连接统计。如果后端未及时关闭空闲长连接，会导致 least_conn 误判“该节点已满”，建议后端配合设置合理的 keepalive timeout；
它适合什么场景，不适合什么？
适合：请求处理时间差异大（比如既有毫秒级 API，也有秒级报表导出）、存在较多长连接、后端实例性能较接近的集群。
不太适合：所有后端响应时间高度一致且极短（此时轮询更简单高效）；或者后端能力差异极大且无规律波动（这时需结合自定义健康检查或动态权重上报）。
验证是否真起作用
不能只看 upstream 状态页里的“Active”数字。建议在真实压测中观察两项指标：
- 各后端的 平均响应时间分布 是否趋近（而非某台明显拖慢整体）；
- Nginx access log 中 $upstream_addr 字段的分配是否随负载变化动态偏移——高峰期应看到连接数低的节点承接更多新请求。
