nginx最少连接算法本身不提升qps上限，而是通过负载矫正提升qps稳定性与实际吞吐效率：在长耗时、长尾延迟场景下，它绕开卡顿节点，避免连接堆积和雪崩，使相同硬件跑出更高更稳qps；其生效需三个前提——连接真实反映负载（依赖http/1.1长连接复用）、节点健康可感知（需max_fails+fail_timeout或主动健康检查）、连接容量差异化约束（用max_conns替代weight）。
Nginx 最少连接调度算法本身不直接提升集群 QPS 上限，但它能显著提升 QPS 的稳定性、一致性与实际吞吐效率——尤其在接口耗时长、算力重、存在长尾延迟的场景下，让有限的后端资源被更公平、更真实地利用。
它不是“加速器”，而是“负载矫正器”：把请求从“卡住”的节点上主动绕开，避免因单点响应变慢导致的连接堆积、超时重试和雪崩传导，从而让整体系统在相同硬件条件下跑出更高、更稳的 QPS。
最少连接算法真正起效的三个前提条件
-
连接必须真实反映工作负载
后端每处理一个请求就断连（短连接），活跃连接数始终接近 0，least_conn 就退化为轮询。必须启用 HTTP/1.1 长连接复用：- upstream 中配置
keepalive 32; - location 中设置
proxy_http_version 1.1; proxy_set_header Connection ''; - 后端服务开启 keep-alive（如 Uvicorn 的
--keep-alive 5）
- upstream 中配置
-
节点健康状态必须可感知
若某台机器因 GPU 内存不足卡死但 TCP 连接未断，least_conn 仍会往它派请求（连接数低但实际不可用）。必须配：-
max_fails=2 fail_timeout=10s（被动检查） - 或启用 active health check（如 OpenResty 的
check指令） -
proxy_next_upstream error timeout http_500;配合重试逻辑
-
-
连接容量需差异化约束
weight在 least_conn 下被忽略，不能靠权重表达性能差异。改用max_conns：- 高性能节点：
server 10.0.1.10:8000 max_conns=1200; - 普通节点：
server 10.0.1.11:8000 max_conns=600; - 超过 max_conns 的节点自动剔出调度池，防止慢请求锁死连接队列
- 高性能节点：
它对 QPS 的实际影响路径
- 降低平均延迟：避免请求扎堆到已堆积连接的节点，P95 延迟更贴近后端 P99 处理时间，而非叠加排队等待
-
减少失败重试：健康检查及时摘除异常节点，避免大量
502/504和客户端重发，节省无效 QPS 消耗 -
提升连接复用率：配合
keepalive_timeout 5s和keepalive_requests 1000，单连接承载更多请求，降低建连开销 - 缓解长尾放大效应：AI 推理类接口一次卡顿可能拖住 10+ 秒，least_conn + max_conns 能快速隔离该节点，保护其余节点吞吐不受影响
对比轮询策略的真实压测结果（200 QPS，含 10% 长连接）
| 指标 | 轮询 | least_conn + 健康检查 + keepalive |
|---|---|---|
| 各节点连接数分布 | 12–41（严重不均） | 15–19（高度均衡） |
| 平均响应延迟 | 490 ms | 320 ms |
| P95 延迟波动 | ±180 ms | ±30 ms |
| 错误率（5xx） | 3.2% | 0.1% |
关键不在算法多聪明，而在是否让 Nginx 看见真实的“手头活儿”——连接数只是表象，背后是健康状态、超时容忍、复用效率共同决定的调度质量。
