least_conn算法按实时活跃连接数分配请求，优先选择连接数最少的健康后端，不依赖响应时间或资源指标，需配合健康检查与max_conns配置才能生效。

least_conn 算法本身不“动态调整权重”，而是每次请求到达时，实时比较各健康后端的当前活跃连接数（即 Nginx 与该后端之间已建立、尚未关闭的 TCP 连接数），直接把新请求发给连接数最少的那个节点——这个决策是即时、无状态、每请求一次的，不需要预先配置或运行时干预。

least_conn 的核心机制：只看“手头还剩几个活儿”

它不依赖响应时间、CPU、内存或历史吞吐量，只统计当前活跃连接数。这意味着：

• 一个刚处理完长耗时任务（如报表导出、AI推理）的节点，连接数迅速回落，会立刻被选中
• 另一个还在维持多个 WebSocket 或 HTTP/2 流的节点，即使 CPU 很低，也会被跳过
• 连接数为 0 的节点，天然拥有最高优先级；连接数达上限（max_conns）则自动剔除

让 least_conn 发挥实效的关键配置

算法生效的前提，是配置准确且配套机制到位：

• 在 upstream 块中明确声明 least_conn，无需参数，一行即可
• 必须配合 健康检查（如 check 指令或 nginx_upstream_check_module），否则故障节点仍会被计入连接数统计，流量照打不误
• 用 max_conns 为异构节点设软性容量上限，例如高性能机设 max_conns=2000，普通机设 800，实现带保护的倾向性调度
• 避免混用 weight —— 开源版 Nginx 会忽略 weight，若需加权能力，需考虑商业版或结合健康检查做逻辑分流

适合 least_conn 的真实业务信号

不必凭感觉切换，观察以下现象再启用更稳妥：

• 监控显示某些后端 conn_established 持续偏高，但 CPU/内存使用率却明显偏低
• 接口响应时间标准差大（比如 P50=120ms，P99=3.2s），说明请求耗时不均
• 存在大量长连接场景：WebSocket、SSE、流式文件下载、HTTP/2 多路复用
• 轮询模式下已出现个别节点连接堆积、超时增多、甚至触发连接池拒绝

它不是万能解药：短连接场景效果有限

对于典型 HTTP/1.1 短平快请求（平均连接生命周期