least_conn是Nginx基于当前活跃连接数最少的后端进行转发的负载均衡算法，仅统计Nginx与后端的TCP长连接数，不感知CPU、内存等真实负载，需配合keepalive和健康检查使用。
在 Nginx 中，least_conn 是 upstream 模块提供的一个负载均衡算法，它不是“自动识别低负载节点”，而是基于当前活跃连接数最少的后端服务器进行转发——这是一种被动、实时的连接数感知机制，不涉及 CPU、内存、响应时间等真实负载指标。
least_conn 的工作原理
该算法会在每次请求到来时，遍历 upstream 中所有 server，选择当前已建立但尚未关闭的 TCP 连接数（active connections）最少的节点。若多个节点连接数相同，则按加权轮询（weight-aware）顺序选一个。
- 只统计 Nginx 与后端保持的长连接（如 keepalive 开启时），不统计后端自身处理耗时或资源使用率
- 不依赖健康检查结果（需单独配置
health_check或max_fails/fail_timeout） - 对突发短连接场景效果明显；对长连接（如 WebSocket、gRPC 流）更公平
基础 least_conn 配置示例
在 http 块中定义 upstream，并指定 least_conn 算法：
upstream backend {
least_conn;
server 192.168.1.10:8080 weight=3;
server 192.168.1.11:8080 weight=2;
server 192.168.1.12:8080;
}注意：weight 会影响同连接数下的选择倾向，但不会改变“最少连接”这一核心判断逻辑。
配合 keepalive 提升 least_conn 效果
默认情况下，Nginx 与后端使用短连接，每次请求新建+关闭连接，导致 least_conn 统计意义减弱。启用连接池可让连接复用，使连接数更真实反映服务压力：
upstream backend {
least_conn;
keepalive 32; # 每个 worker 进程保活连接数上限
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
<p>server {
location /api/ {
proxy_pass <a href="https://www.php.cn/link/65b5b8d1f89bf53a5713bc3afdd83e9e">https://www.php.cn/link/65b5b8d1f89bf53a5713bc3afdd83e9e</a>;
proxy_http_version 1.1;
proxy_set_header Connection '';</p><h1>其他 proxy_* 设置...</h1><pre class="brush:php;toolbar:false;"><code>}}
必须显式设置 proxy_http_version 1.1 和清除 Connection 头，否则后端可能关闭长连接。
常见误区与补充建议
误区一：“least_conn 能感知后端 CPU 忙闲” —— 它完全不采集系统指标，仅看 Nginx 自身维护的连接计数。
误区二：“开启 least_conn 就无需健康检查” —— 若某节点宕机但 TCP 连接未超时，Nginx 仍可能把新请求发过去，造成失败。务必搭配：
-
max_fails=3 fail_timeout=30s（被动检测） - 或
health_check interval=5s fails=2 passes=2（主动健康检查，需 Plus 版本或开源版配合第三方模块）
适用场景建议：API 网关、微服务入口、长连接服务（IM、实时推送）；不推荐用于响应极不均匀（如部分请求耗时秒级、部分毫秒级）且无连接复用的场景。
