least_conn是nginx基于实时活跃连接数调度的负载均衡策略，优先将请求分发给当前活跃连接数最少的后端服务器，适用于长连接多、响应时间差异大或后端性能异构的场景。
Nginx 的 least_conn 负载均衡策略，并不是“找当前连接数最少的节点”，而是“在活跃连接数最少的后端中选一个”——它只比较已建立但尚未关闭的长连接（比如 keepalive 连接），不感知请求处理耗时、CPU 或响应时间。所以它不能保证把请求发给“最空闲”的节点，但对防止某台服务器被短连接风暴打垮有一定帮助。
least_conn 的真实行为
当多个 upstream server 都处于健康状态时，Nginx 会：
- 统计每个 server 当前已建立、尚未关闭的 TCP 连接数（即活跃连接）；
- 选出连接数最小的那个（若有多个并列最小，则按配置顺序取第一个，或配合 hash/ip_hash 等进一步分配）；
- 把新请求发给该 server。
注意：它不看请求是否正在处理、响应是否返回、后端线程是否繁忙，也不读取后端返回的负载指标。
如何正确配置 least_conn
在 upstream 块中启用即可，无需额外参数：
示例：
upstream backend {
least_conn;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
搭配建议：
- 开启
keepalive（连接复用）能让least_conn更有效，否则短连接下各节点连接数几乎总是 0，退化为轮询； - 配合
max_conns限制单节点最大并发连接，避免某台机器过载； - 使用
health_check（需 Nginx Plus 或开源版 1.11.5+ 搭配第三方模块）自动剔除不可用节点。
它不适合什么场景？
如果你需要真正“按实时负载分发”，least_conn 不够用，因为：
- 它不知道后端 CPU、内存、队列长度；
- 无法区分“连接已建立但请求刚进来”和“连接里压着 100 个未响应请求”；
- 对 HTTP/2 多路复用连接，一个连接可能承载大量并发流，此时连接数完全失真。
这类需求建议：
- 后端主动上报指标（如 Prometheus + 自定义 health check）；
- 用 Nginx Plus 的 least_time（基于响应时间）；
- 或前置一层更智能的 LB（如 Envoy、Traefik、自研调度器）。
验证 least_conn 是否生效
可通过 Nginx stub_status 模块观察：
- 开启
stub_status（需编译时含该模块）； - 访问
/nginx_status，查看Active connections和 upstream 各 server 的连接分布； - 用 ab / wrk 持续压测，观察连接数是否明显向低连接节点倾斜（注意关掉 keepalive 测试效果会很弱）。
也可以加日志变量 $upstream_addr 记录每次转发的目标地址，再统计分布。
