Nginx least_conn策略最核心优势是每次请求到来时，实时将新请求分发给当前活跃连接数最少的健康后端，该计数精确到单个TCP连接、不估算、不跨worker共享、无状态无延迟，直接反映此刻真实负载压力。
Linux Nginx 的 least_conn 策略在动态请求处理中最核心的优势，是它不依赖预设规则或历史数据，而是每次请求到来时，实时把新请求分发给当前活跃连接数最少的健康后端——这个“最少”是精确到单个 TCP 连接的即时计数，不是估算、不是平均、不跨 worker 共享，但足够反映此刻的真实负载压力。
精准响应真实并发压力
动态请求常伴随响应时间剧烈波动（如 20ms 缓存读 vs 8s 报表导出），轮询会继续向正处理长任务的节点派发新请求，造成隐性排队。least_conn 直接盯住“已建立未关闭”的连接数，相当于读取每台后端的实时待办清单长度，自然绕开堆积连接的节点。
- 连接数高 ≠ CPU 高，但大概率意味着有请求正在阻塞或等待响应
- 连接数低 ≠ 绝对空闲，但显著降低了新请求被拖慢的风险
- 对 WebSocket、HTTP/2 流、AI 推理等长连接场景特别有效，因连接持续存在，统计稳定可靠
无需外部依赖的轻量实时决策
整个调度过程完全由 Nginx 自身在内存中完成：每个 worker 进程独立维护各 upstream server 的连接计数器，请求建立或断开时同步增减。不调用外部监控、不依赖指标上报、不查数据库、不走 API。
- 决策发生在请求进入 upstream 模块的瞬间，无缓存、无延迟、无状态
- 健康检查失败的节点自动跳过，不参与比较
- 开源版原生支持，无需商业模块或定制编译
天然适配异构与突发流量场景
当后端性能不均（如混用 16 核与 8 核机器）或流量突发（如秒杀开场），least_conn 能快速响应变化：卡顿节点连接数迅速上升，后续请求立刻转向空闲节点，避免雪崩式延迟累积。
- 突发时不会像轮询那样“平均喂食”，而是主动避让已堆积的节点
- 连接数相同时，自动回退到 weight 加权逻辑，可用 weight 反映硬件能力差异
- 配合
slow_start还能平滑接入新实例，防止冷启动冲击
关键生效前提不能省略
least_conn 不是开箱即用的银弹。它高度依赖后端连接行为的真实性与 Nginx 自身配置的协同：
- 必须启用健康检查（主动
health_check或至少被动proxy_next_upstream + max_fails），否则“假活”节点会持续吸走流量 - 必须配置
keepalive N并搭配proxy_http_version 1.1和proxy_set_header Connection ''，否则短连接频繁新建会让连接数失真 - 后端需开启连接池（如 Tomcat 的
maxKeepAliveRequests）、合理设置超时，避免 Nginx 想复用而服务端已断连
