直接在upstream块首行写least_conn;即可启用该策略，无需参数或模块；需配合keepalive、健康检查及max_conns配置才能真实生效，多节点连接数相同时fallback至weight加权轮询。
直接在 upstream 块里写 least_conn; 就能启用，不需要参数，也不用额外安装模块——Nginx 1.3.1 起已内置支持，当前稳定版（如 1.20+）完全可用。
基础配置写法
只需三步：声明策略、列出后端、确保版本达标。
- 检查 Nginx 版本：
nginx -v，确认 ≥ 1.3.1（推荐 ≥ 1.18） - 在
http块中定义 upstream，开头加上least_conn; - 后端 server 行可带健康检查参数（如
max_fails=3 fail_timeout=30s），但不支持weight直接影响 least_conn 决策
示例：
upstream api_backend {
least_conn;
server 10.0.1.10:8000 max_fails=3 fail_timeout=30s;
server 10.0.1.11:8000 max_fails=3 fail_timeout=30s;
server 10.0.1.12:8000 backup;
}
必须配合 keepalive 才有效
least_conn 统计的是 Nginx 与后端之间的活跃 TCP 连接数。如果每次请求都新建连接，连接数瞬间归零，策略就退化成轮询。
- 在 upstream 块内加
keepalive 32;（建议值 16–64），每个 worker 复用空闲连接 - 在 proxy_pass 对应的 location 中启用 HTTP/1.1 复用：
proxy_http_version 1.1;和proxy_set_header Connection ''; - 后端服务也要支持 keep-alive，例如设置合理的
keepalive_timeout（如 75s）
避免调度失准的关键补充
least_conn 只看连接数，不感知节点是否健康或是否卡死，必须叠加保护机制。
- 用
max_conns限制单节点并发上限，体现服务器能力差异（如高性能机设max_conns=2000，普通机设800） - 开启主动或被动健康检查，防止请求发给已失联但连接未关闭的节点
- 多节点连接数相同时，least_conn 会 fallback 到按
weight加权轮询（weight 此时起作用，但只是第二顺位）
验证是否真正生效
配置 reload 后不能只看是否启动成功，要确认行为符合预期。
- 开启
stub_status模块，在 server 块中加：location /nginx_status { stub_status; }，访问后观察各后端Active connections是否趋于均衡 - 在后端机器上执行
ss -s | grep 'estab'或netstat -an | grep :端口 | grep ESTAB | wc -l，比对连接数是否与 Nginx 统计一致 - 压测时关注日志中的
$upstream_addr字段，确认请求确实落在连接数更少的节点上
