最少连接算法（least_conn）通过将请求导向当前连接数最少的后端节点来降低并发冲突率，它依赖实时连接数这一真实压力指标，尤其适用于长连接与响应时间差异大的场景，并需配合健康检查、upstream keepalive及后端连接复用配置才能生效。
最少连接算法（least_conn）能有效降低后端连接并发冲突率，关键在于它把请求导向“当前最空闲”的节点，而不是按顺序或随机分配。它不依赖预测，只看实时连接数——这个数字直接反映后端是否正在被长任务占用、是否已接近连接瓶颈。
为什么能减少并发冲突
并发冲突常源于多个请求同时挤向同一台正处理慢任务的后端，比如一个 5 秒的报表导出还没结束，新请求又持续打过去，导致连接堆积、队列拉长、超时频发。least_conn 从源头规避这个问题：
- 连接数是真实压力指标：每个未关闭的 TCP 连接代表一个尚未完成的事务，统计它比轮询更贴近后端实际负载
- 长连接场景下优势明显：WebSocket、HTTP/2 流、大文件上传等会让单连接长期存活，least_conn 能识别这种“隐性占用”，而轮询完全无感
- 响应时间差异大时更公平：毫秒级查询和 10 秒级计算混跑时，least_conn 自然绕开卡住的节点，避免雪崩式堆积
必须配合的三项配置
单独写 least_conn 不足以生效，以下三项缺一不可：
-
启用健康检查：用
max_fails=2 fail_timeout=15s或主动health_check，否则宕机但连接未断的节点仍会被选中，反而加剧失败重试 -
开启 upstream keepalive：例如
keepalive 32，让 Nginx 复用后端空闲连接；否则短连接频繁建连断连，连接数波动剧烈，least_conn 判断失真 -
后端需支持连接复用：如 Tomcat 设置
maxKeepAliveRequests，Node.js 启用keepAliveTimeout，否则 Nginx 的 keepalive 无法落地
用 max_conns 体现节点真实容量
least_conn 本身不认 weight，但可通过 max_conns 实现软性限流，让高配机器多扛压、低配机器不超载：
- 高性能节点设
server 192.168.1.10:8080 max_conns=2000 - 普通节点设
server 192.168.1.11:8080 max_conns=800 - 当某节点活跃连接数达到 max_conns，Nginx 会跳过它，即使它当前连接数仍略低于其他节点
这比单纯靠连接数排序更精细，尤其适合混合部署场景。
验证是否真正起效
别只看日志，要结合监控确认算法在“看清真实负载”：
- 通过
stub_status或 Prometheus 指标观察各后端active connections是否均衡（波动范围建议控制在 ±20% 内） - 对比
$upstream_connect_time和$upstream_header_time：前者稳定但后者飙升，说明问题在后端业务逻辑，不是负载策略失效 - 检查
$upstream_addr分布是否随连接数动态偏移——如果某台始终高频出现，大概率是健康检查没生效或 keepalive 未复用
