least_conn本身不是流量屏蔽策略，而是将新请求优先分发给活跃连接数最少的后端节点；在慢响应场景下，因连接堆积导致调度自然倾斜至健康节点，但无法识别卡死却未断连的节点，需配合proxy_next_upstream超时重试、fail_timeout/max_fails及主动健康检查才能实现可靠屏蔽。
最少连接（least_conn）本身不是流量屏蔽策略，它只是把新请求优先分发给当前活跃连接数最少的后端节点。当后端响应慢时，该节点连接数会持续堆积、迟迟不释放，least_conn 会自然“避开”它——这不是主动屏蔽，而是被动规避。
为什么 least_conn 在慢响应场景下能起到类似屏蔽效果
后端响应慢 → 连接长时间占用 → 该节点活跃连接数升高 → least_conn 调度器倾向选择连接更少的健康节点 → 流量自动倾斜过去
- 无需额外配置，是 least_conn 的天然行为
- 对短连接接口（如 REST API）效果明显；对长连接（如 WebSocket）需配合 keepalive_timeout 合理设置
- 不依赖健康检查结果，只要连接未断，就持续计入统计
但仅靠 least_conn 不足以可靠屏蔽慢节点
它无法识别“已卡住但连接未断”的节点（比如线程阻塞、数据库锁死），这类节点连接数可能不再增长，却已失去处理能力。此时 least_conn 仍可能继续转发请求。
- 慢响应 ≠ 连接数高：例如后端刚接受请求、尚未写响应头，连接数已计数，但实际已卡死
- 无超时感知：least_conn 不关心响应耗时，只看连接数量
- 缺乏故障隔离：单点缓慢会拖慢整体调度效率，但不会主动摘除
真正有效的流量屏蔽要叠加主动机制
least_conn 需搭配以下配置，才能形成闭环的慢节点识别与隔离：
- 启用 proxy_next_upstream timeout：设短 proxy_read_timeout（如 3–5s），让响应头迟迟不返回即触发重试，同时标记该 upstream 失败
- 配置 fail_timeout 和 max_fails：例如 max_fails=2 fail_timeout=30s，连续两次 timeout 后，Nginx 临时屏蔽该节点 30 秒
- 配合主动健康检查（推荐）：用 upstream_check_module 或 Nginx Plus 的 health_check，定期探测 /health 端点，失败则立即摘除
实际配置示例（含 least_conn + 屏蔽逻辑）
在 upstream 块中组合使用：
upstream backend {
least_conn;
server 10.0.1.10:8080 max_fails=2 fail_timeout=30s;
server 10.0.1.11:8080 max_fails=2 fail_timeout=30s;
keepalive 100;
}
location /api/ {
proxy_pass http://backend;
proxy_read_timeout 4s;
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 2;
}
这样，一旦某台机器连续两次在 4 秒内无法返回响应头，就会被踢出调度池 30 秒，least_conn 在此期间只会看到剩余健康节点，实现真正意义上的“流量屏蔽”。
