least_conn算法本身不保证请求分配绝对均匀，仅优先将新连接分发至活跃连接数最少的节点；真正避免不均需依赖健康检查（如proxy_next_upstream配合max_fails）、keepalive两端对齐（Nginx upstream配keepalive、后端开启长连接）、合理设置weight或max_conns体现节点能力差异，并通过stub_status验证Active connections真实分布。
最少连接算法本身不保证请求分配绝对均匀，它只确保新连接优先落到当前活跃连接数最少的节点上。真正避免分配不均，靠的是让这个“连接数”真实反映后端负载——而不是靠算法单打独斗。
健康检查必须启用，否则宕机节点还在排队
默认情况下，Nginx 不主动探测后端是否存活。一台服务器已卡死或进程崩溃，但 TCP 端口仍通，它就会持续被选中，连接不断堆积、超时、重试，造成“伪低连接数”假象。
- 配置 passive 检查：在 location 或 upstream 中加
proxy_next_upstream error timeout http_500;，配合每个 server 的max_fails=2 fail_timeout=15s - 更推荐 active 健康检查（需商业版或开源 patch）：定期发 HTTP HEAD 请求，失败立即标记为不可用
keepalive 必须两端对齐，否则连接数统计失真
如果 Nginx 和后端都未复用连接，每个请求建一次 TCP、关一次，连接数瞬间归零，“最少连接”就退化成随机调度。
- Nginx upstream 内加
keepalive 32;（建议值 16–100，按并发量调整） - 后端服务也要开启长连接支持：如 Tomcat 设置
maxKeepAliveRequests > 0，Spring Boot 配置server.tomcat.connection-timeout=-1 - 客户端侧也别频繁断连，比如浏览器或 SDK 默认 keep-alive 多数可用，但某些脚本可能显式关闭
权重与容量控制要匹配实际能力
一台机器 CPU 是另一台的 2 倍，但没配 weight，least_conn 会把它和弱机同等对待；反过来，若强机 max_conns 设太低，又会人为制造瓶颈。
- 性能强的节点可设
weight=2或更高，让其在“连接数相近”时获得更高概率 - 有明确容量上限的节点（如数据库连接池限制），用
max_conns=100软限制，超出后自动跳过 - 避免 weight 和 max_conns 同时滥用——前者影响调度倾向，后者影响硬性准入，二者逻辑不同，别混用
连接数统计依赖真实活跃状态，不是请求数
least_conn 统计的是当前 ESTABLISHED 状态的 TCP 连接，不是已完成的请求数。所以长连接（如 WebSocket、SSE、HTTP/2 流）会让连接数长期存在，这反而是它的优势场景；但短连接+高 QPS 下，连接数波动快，需靠 keepalive 稳住基线。
- 可通过
stub_status模块查看各 upstream server 的Active connections实时值，验证是否符合预期 - 压测时观察 P95 延迟和各节点连接数分布，比单纯看平均值更有意义
- 若发现某节点连接数持续偏高且响应慢，先查它是否被健康检查遗漏，再查后端 GC、锁竞争或慢 SQL
