least connections 算法在短连接高频请求场景下不推荐使用，因其活跃连接数趋近于零导致调度失效，无法反映真实负载，且健康检查与重试易失灵；推荐改用加权轮询、启用 keepalive 或前置限流。
Least Connections 算法在短连接高频请求场景下不推荐使用，核心原因是它失去调度依据——连接数统计失效，算法退化为近似随机分发。
短连接导致“活跃连接数”瞬间归零
短连接指每个 HTTP 请求都新建 TCP 连接、响应结束后立即关闭。Nginx 统计的“活跃连接数”只包含 已建立但尚未关闭 的连接。在短连接模式下：
- 请求到达时建连 → 计数 +1
- 后端响应返回、Nginx 转发完毕 → 连接立刻关闭 → 计数 -1
- 实际观测到的活跃连接数长期趋近于 0 或剧烈抖动（如 0–2 之间）
此时所有后端节点的连接数几乎总是相等，least_conn 失去区分能力，最终行为接近轮询甚至伪随机。
无法反映真实负载，反而掩盖问题
短连接高频场景下，真正瓶颈常在后端处理耗时、线程池排队或数据库连接池争用，而非网络连接数。least_conn 却只盯着一个失真的数字：
- 一台后端因 GC 暂停卡住 5 秒，但连接已断，不会被 least_conn “看见”
- 另一台响应快但刚处理完请求，连接也已释放，连接数同为 0
- 新请求仍可能打向慢节点，而算法毫无感知
它既不能规避慢节点，也无法体现资源饱和，等于放弃动态调度价值。
健康检查与重试机制容易失效
短连接本身无状态，被动健康检查（如 max_fails）依赖连续失败响应。但在高频短连接中：
- 单个请求失败可能是瞬时网络抖动，不代表节点不可用
- 若未配
proxy_next_upstream timeout，超时请求不会触发重试，故障节点持续接收新请求 - 主动健康检查虽可用，但短连接模式下探测包本身也易受干扰，误判率上升
更合适的替代方案
面对短连接高频请求，应优先考虑：
- 加权轮询（weight）：按机器规格静态分配流量，稳定可控
-
配合合理超时与重试：如
proxy_next_upstream error timeout http_502 http_504+proxy_next_upstream_timeout 10s - 启用 keepalive（推荐）：将短连接升级为长连接复用，让 least_conn 重新获得有效统计基础
- 前置限流或队列：用 Nginx 的 limit_req 或后端熔断机制控制入流节奏，比依赖连接数调度更直接
