least_conn算法仅依据各节点当前活跃连接数选择目标，不评估CPU、内存、响应时间等性能指标；它反映的是“空闲程度”而非“处理能力”，需配合健康检查、keepalive复用等机制提升实效性。
这个说法不准确。Nginx 的最少连接（least_conn）算法本身并不评估后端的处理能力，它只统计并比较各上游服务器当前的活跃连接数（active connections），然后把新请求发给数值最小的那个健康节点。
它看的是“忙不忙”，不是“强不强”
所谓“活跃连接数”，指的是已建立、尚未关闭的 TCP 连接数量，Nginx 通过内核 socket 状态实时获取，不涉及 CPU 使用率、内存占用、响应时间或吞吐量等性能指标。一台配置弱但刚空闲下来的机器，连接数为 0；另一台配置强但正处理 5 个长耗时任务，连接数为 5 —— least_conn 会选前者，不是因为它“能力强”，而是因为它“此刻更空闲”。
- 它无法识别某台机器 CPU 已满载但连接数仍低（比如大量异步非阻塞任务）
- 它也不感知响应延迟：一个连接数少但响应慢的节点，只要没超时或失败，就会持续被选中
- 权重（weight）仅影响初始分配倾向，不改变“选最少连接”这一核心逻辑
真正提升负载适配性的，是组合配置
least_conn 要发挥效果，必须依赖外部机制来逼近真实负载：
-
健康检查：靠
max_fails/fail_timeout或主动探针，及时剔除卡住但连接未断的节点，否则“最少连接”可能指向一个假活节点 - keepalive 复用：避免短连接频繁建连断连，让连接数统计稳定、可反映真实并发压力
-
proxy_next_upstream：配置
error timeout http_500 http_502，让超时或错误触发重试，间接推动流量离开过载节点 - slow_start：新节点上线时逐步加量，防止冷启动瞬间打满
什么时候适合用 least_conn？
它最适合的场景，是后端行为呈现强不确定性时：
- 请求耗时差异大（如 AI 推理 + 静态资源混合）
- 大量长连接（WebSocket、gRPC、HTTP/1.1 持久连接）
- 部分节点偶发慢查询或 GC 暂停，导致连接堆积
- 轮询下已观察到个别节点连接数持续偏高、超时增多
想让 Nginx “感知处理能力”，得靠监控系统+动态配置（如基于 Prometheus 指标调权），或改用商业版支持的动态负载模块。开源版 least_conn 本质是个轻量、低开销的连接级调度器，简单直接，但不智能。
