最小连接算法（least_conn）需配合健康检查、连接复用、超时控制和权重配置才能真正优化负载均衡；脱离协同机制易导致流量不均或延迟加剧。

最小连接算法（least_conn）本身不直接“提升性能”，它只是把新请求导向当前活跃连接数最少的健康后端。真正起作用的是它背后的一整套协同配置——健康检查、连接复用、超时控制和权重逻辑。脱离这些，least_conn 很可能让流量更不均衡，甚至加剧延迟。

健康状态必须可感知

Nginx 默认不主动探测后端是否存活。如果某台服务器已卡死或响应极慢，但没被标记为不可用，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，让失败响应触发被动健康检查
• 有条件时启用主动健康检查（需商业版或 patch），比如每 5 秒发一个 HEAD 请求验证服务可用性

连接数统计必须真实可靠

所谓“最少连接”，前提是 Nginx 能准确知道每台后端正在处理多少连接。短连接频发、keepalive 配置缺失或后端未开启连接池，都会导致连接刚建即断，计数频繁归零，使算法退化为近似随机分发。

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

• upstream 内必须加 keepalive 32;（数值按并发量调整，通常 16–64）
• 后端服务要启用连接池：Tomcat 设置 maxKeepAliveRequests > 0，Spring Boot 的 server.tomcat.max-keep-alive-requests 同理
• 避免在 location 中误配 proxy_http_version 1.0 或关闭 Connection: keep-alive 头

权重与冷启动必须可控

新扩容节点上线瞬间直接参与 least_conn 调度，容易因无历史连接积累而被大量请求打满，引发雪崩。同时，若后端性能差异大但未设权重，算法无法体现真实处理能力差异。

• 给新实例加 slow_start=30s，连接权重从 0 线性增长到 full，缓冲初始压力
• 对 CPU 更强或内存更大的节点，合理设置 weight，例如 server 10.0.1.12:8080 weight=5;
• 注意：权重不影响“谁连接最少”的判断，只影响多个服务器连接数相同时的倾向性选择

长连接与突发流量场景最受益

least_conn 在 WebSocket、gRPC 流式接口、文件上传等长耗时请求中优势明显。轮询策略下，一台机器一旦被分配一个 10 秒的上传请求，接下来 9 秒内它就比其他空闲机器多出 1 个连接；而 least_conn 会自动绕开它，把后续请求导给连接数为 0 的节点。

• 压测显示：含 10% 长连接的 200 QPS 场景中，least_conn + 健康检查可将 P95 延迟稳定在 320ms，轮询则升至 490ms+
• 关键不是算法快，而是它让 Nginx “看清”了真实负载——连接数只是表象，背后是健康、复用、超时三者的共同结果