least_conn是Nginx 1.3.1起内置的动态负载均衡算法，基于实时活跃TCP连接数调度，优先分发请求至连接数最少的健康后端，适用于长连接、响应时间差异大或后端性能不均场景，需配合keepalive、健康检查及stub_status验证效果。
Nginx 本身不原生支持“最小连接数（Least Conn）”这种动态实时连接数感知的负载均衡算法，但可以通过 第三方模块 ngx_http_upstream_least_conn_module 实现——不过该模块早在 Nginx 1.3.1 版本中已被官方合并进核心，从 Nginx 1.3.1 起，least_conn 已是内置指令，无需额外编译或安装模块。
确认 Nginx 版本并启用 least_conn
确保你使用的 Nginx ≥ 1.3.1（推荐 ≥ 1.18 或最新稳定版）。可通过以下命令检查：
nginx -v若版本达标，直接在 upstream 块中使用 least_conn 指令即可：
upstream backend {least_conn;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
least_conn 的工作原理与适用场景
least_conn 策略不是基于请求响应时间或权重，而是将新请求优先分发给当前活跃连接数最少的后端服务器。它适用于：
- 后端服务处理时长差异大（如混合长连接、文件上传、流式响应等）
- 避免某台服务器因堆积大量慢连接而雪崩
- 与 keepalive 配合时，能更公平地摊平并发压力
注意：Nginx 统计的是它自身与后端建立的 当前活跃连接数（即已建立、尚未关闭的 TCP 连接），不包括等待 accept 的连接队列，也不感知后端应用层的线程/协程占用情况。
配合其他指令提升效果
单独用 least_conn 可能不够稳健，建议组合以下配置：
-
keepalive：在 upstream 中启用连接池，减少握手开销，使连接数统计更稳定
upstream backend {
least_conn;
keepalive 32;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
} - proxy_http_version 1.1 和 proxy_set_header Connection ''：确保上游复用 HTTP/1.1 连接
- 健康检查（active or passive）：避免把请求发给已失联但连接未超时的节点，例如搭配 max_fails 和 fail_timeout
常见误区与注意事项
- least_conn 不等于“最少请求数”或“最低 CPU”，它只看 Nginx 维护的连接计数器
- 在短连接（HTTP/1.0 或无 keepalive）场景下，连接数变化极快，least_conn 效果趋近于轮询
- 如果后端服务主动关闭连接较慢（如 linger 设置过长），Nginx 可能仍将其计入活跃连接，导致调度偏差
- 不支持为 least_conn 配置权重（weight），如需加权最小连接，需借助商业版 NGINX Plus 或 OpenResty 自定义逻辑
