least_conn策略需在upstream块首行启用，配合keepalive、健康检查及HTTP/1.1长连接复用才生效；多节点连接数相同时回退加权轮询。
直接在 upstream 块中写 least_conn; 即可，但要真正生效，必须满足几个关键条件：Nginx 版本 ≥ 1.3.1（推荐 ≥ 1.18）、启用连接复用、配合健康检查，并确保配置位置正确。
基础配置写法
least_conn 是 Nginx 内置指令，无需安装模块。它必须作为 upstream 块的第一条指令，且不能与 ip_hash、hash 等策略共存：
-
正确示例：
upstream backend {
least_conn;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
} -
错误写法：放在
location或http块里；写成least_conn on;或带参数；与ip_hash同时出现——都会导致启动失败。
必须配合 keepalive 才有效
如果后端每次请求都新建并关闭 TCP 连接，活跃连接数几乎恒为 0 或 1，least_conn 就退化为随机分配。要让它反映真实压力，需启用连接池：
- 在
upstream中添加keepalive 32;（每个 worker 最多缓存 32 个空闲连接） - 在
location中启用 HTTP/1.1 并清除 Connection 头：
proxy_http_version 1.1;
proxy_set_header Connection ''; - 后端服务也需支持 Keep-Alive，且 timeout 设置合理（如 60s），否则连接过早断开，统计失真。
加上健康检查避免“假空闲”
least_conn 不判断后端是否可用。一台宕机的服务器若 TCP 连接尚未超时，连接数可能仍显示为 0，请求就会被错误转发。
- 使用被动健康检查：为每个
server添加max_fails=3 fail_timeout=30s，连续失败 3 次后，30 秒内不再调度 - 如需主动探测（如定期 GET /health），需借助
ngx_http_upstream_check_module（开源版需编译）或商业版 NGINX Plus 的health_check - 故障节点会被自动剔除，不参与 least_conn 计算；恢复后自动重新加入调度池。
验证是否按连接数调度
光看配置没用，得确认行为符合预期：
- 开启
stub_status模块，在某个 location 中配置：
location /nginx_status { stub_status; }
访问该地址可实时查看各后端的Active connections - 用
ab -n 1000 -c 50或wrk并发压测，再比对各后端 access log 中的请求数分布 - 注意：多个节点连接数相同时，least_conn 会 fallback 到加权轮询（按
weight分配），所以 weight 仍有效，但不可用于“加权最小连接”——那是 NGINX Plus 的功能。
