least_conn算法仅基于活跃连接数选择后端，不检测响应慢；动态剔除慢节点依赖健康检查机制——被动检查（proxy_next_upstream）靠请求失败触发，主动检查（nginx_upstream_check_module）通过定时探测识别“假活”节点，二者协同确保least_conn调度真实可用节点。
最少连接（least_conn）算法本身不直接剔除节点，它只负责在健康节点中选连接数最少的那个；真正实现“动态剔除响应缓慢节点”的，是健康检查机制——least_conn 与之配合，才能让流量自动绕开卡顿、变慢的后端。
least_conn 不处理“慢”，只响应“忙”
least_conn 的逻辑非常纯粹：每次新请求进来，Nginx 查看各后端当前的活跃连接总数（含 keepalive 空闲连接），挑最小的发过去。它不测响应时间、不看 CPU、也不主动发探针。所以：
- 一个后端正在处理耗时 10 秒的报表，连接数持续居高，least_conn 会自然避开它——这是“忙”的结果，不是“慢”的判断
- 但如果该后端因进程卡死而响应超时，却仍维持着 TCP 连接未断（比如线程阻塞但 socket 没 close），它的连接数可能没涨，least_conn 就不会察觉，仍会继续派请求过去
- 此时若没有健康检查兜底，慢节点就会持续吸走流量，造成雪崩式延迟升高
必须搭配被动健康检查（proxy_next_upstream）
这是开源 Nginx 最常用、无需编译的剔除方式，靠真实请求失败触发：
- 在 location 块中启用：proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
- 每个 server 必须配对设置：max_fails=2 fail_timeout=15s;（例如
server 10.0.1.10:8080 max_fails=2 fail_timeout=15s;） - 含义：15 秒内连续 2 次因超时或返回上述错误码，该节点被标记为 down，暂停调度 15 秒
- 注意：只有开启
proxy_next_upstream，失败才算数；否则 max_fails 形同虚设
推荐补充主动健康检查（更及时发现“假活”）
对于低峰期或长周期卡顿场景，被动检查有滞后性。主动探测能提前发现“连接通但服务僵死”的节点：
- 使用
nginx_upstream_check_module（OpenResty 默认支持，或需自行编译） - 典型配置：
check interval=3 rise=2 fall=3 timeout=1 type=http; - 搭配探测请求：
check_http_send "HEAD /health HTTP/1.0\r\n\r\n";，要求返回 2xx/3xx 才视为存活 - 节点被标记为 down 后，会定期重试；连续 2 次成功即自动恢复，无需人工干预
关键协同点：让 least_conn “看清”真实负载
即使算法和检查都配了，以下细节不到位，剔除效果也会打折：
-
keepalive 值不宜过大：upstream 中
keepalive 32是合理值；设成 200 会让空闲连接长期占位，虚高连接数，干扰 least_conn 判断 -
后端也要支持连接复用：如 Tomcat 需开启
maxKeepAliveRequests > 0，否则 Nginx 复用无效，连接频繁新建销毁，统计失真 - 避免单点故障放大：若只有一台后端，健康检查再准也无意义；least_conn 至少需要 2 台以上才体现调度价值
