least_conn必须配置在upstream块内首行，作为负载均衡算法参数；它仅基于活跃连接数调度，不支持参数，适用于处理时长不均的场景，需配合健康检查使用。
在 Nginx 的 http 块中配置 least_conn 调度算法，核心是将其写在 upstream 块内，而不是直接放在 http 块顶层。Nginx 本身不支持在 http 级别全局指定负载均衡方式，必须为每个 upstream 分组显式声明。
正确配置 least_conn 的位置
least_conn 是 upstream 指令的参数，只能用于定义上游服务器组时指定：
- 它必须紧跟在
upstream 名称 { ... }的开头大括号后，作为该块的第一条指令之一 - 不能写在
http块下、upstream外；否则会报错："least_conn" directive is not allowed here - 同一
upstream块中不能同时出现least_conn和ip_hash、hash等互斥策略
标准 least_conn 配置示例
以下是一个可用的最小化配置片段：
http {
upstream backend {
least_conn;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
server {
location / {
proxy_pass http://backend;
}
}
}
注意：least_conn 不接受参数（如权重、超时等），它只决定“当前活跃连接数最少的后端优先接收新请求”。连接数统计基于 Nginx 当前已建立但尚未关闭的长连接或正在处理的请求。
least_conn 的适用场景与限制
该算法适合请求处理时间差异大、连接生命周期不均的后端服务，例如：
- 部分请求耗时几毫秒，部分需数秒（如含数据库慢查或外部 API 调用）
- 后端节点性能不完全一致，靠连接数比轮询更能反映真实负载
但它不感知 CPU、内存等系统指标，也不考虑后端健康状态（需配合 health_check 或 max_fails/fail_timeout 使用）。若所有后端都不可用，Nginx 仍会尝试转发并返回 502/503。
验证 least_conn 是否生效
可通过以下方式确认调度行为：
- 使用
curl -I多次请求，结合后端 access log 查看各节点实际接收请求数是否趋向均衡（尤其在并发压测时） - 开启 Nginx stub_status 模块，访问
/nginx_status可看到各 upstream 的 active 连接数（需在 server 块中配置 location） - 注意：单次快速请求可能因 TCP TIME_WAIT 或复用连接导致连接数变化不明显，建议用持续并发（如 ab/wrk）观察趋势
