least_conn算法通过实时比较各健康后端的当前活跃连接数，将新请求优先分发给连接数最少的节点，从而动态避让繁忙节点、减少排队与超时；需配合健康检查、keepalive连接复用及合理超时设置方可生效。
确实如此。Nginx 最少连接算法（least_conn）提升吞吐的核心逻辑，不是靠增加资源，而是让请求“自动绕开正在忙的节点”，从而压缩整体响应时间、减少排队和超时，最终提高单位时间内的有效请求数。
它怎么识别“忙”和“闲”
算法本身只看一个指标：当前活跃连接数（active connections）——即已建立、尚未关闭的连接，包括正在传输请求头、等待后端响应、或正向客户端发送响应的连接。它不猜测 CPU 或内存使用率，也不依赖外部监控数据，而是用这个轻量、实时、Nginx 自身可精确统计的数字作为负载代理。
- 连接数低 ≠ 后端一定空闲，但大概率意味着它没被长任务阻塞；
- 连接数高 ≠ 后端一定过载，但显著增加了新请求排队或被慢响应拖住的风险。
为什么能减少忙闲差异
轮询策略下，请求按顺序分发，不管 A 节点刚接了 5 个耗时 8 秒的报表请求、B 节点刚空下来，第 6 个请求仍可能落到 A 上。而最少连接策略在每次请求到达时都重新比较：
- 若 A 当前有 5 个活跃连接，B 有 0 个，新请求直接给 B；
- 若 A 和 B 都是 2 个，且配置了 weight，就按权重比例再分配；
- 若某节点因故障连接堆积但未断连（如卡在 GC），必须配合健康检查才能及时剔除，否则算法会误判它“闲”。
真正起效离不开三个协同动作
单独写 least_conn 几乎没用。它需要：
-
健康检查：用
max_fails/fail_timeout或主动 health_check，确保“连接数最少”的候选者确实是可用的； -
连接复用：upstream 配
keepalive 32，并设proxy_http_version 1.1+proxy_set_header Connection ''，避免短连接频繁新建，干扰连接数统计； -
合理超时：
proxy_read_timeout和proxy_connect_timeout要匹配后端实际处理能力，太短会频繁重试，太长会让“忙节点”持续吸走请求。
适合这类业务场景
它不是万能解药，但在以下情况效果明显：
- 后端存在明显长耗时操作（AI 推理、PDF 渲染、复杂 SQL）；
- 请求处理时间波动大、不可预测；
- 已有 WebSocket/gRPC 等长连接服务；
- 扩容困难，需榨干现有机器的并发潜力。
本质上，它把“静态调度”变成了“动态避让”，让吞吐提升落在实处，而不是堆机器数量上。
