least_conn算法需配合keepalive连接复用、健康检查及max_conns限流才能真实生效：必须置于upstream首行，禁用weight，启用http/1.1长连接，并通过stub_status验证连接数均衡。
直接在 upstream 块里写 least_conn; 就能启用该算法，但它要真正把请求导向“最空闲”的服务器，光靠这一行远远不够——得让 Nginx 看到的连接数真实反映后端压力，同时剔除那些看似空闲但实际已失效的节点。
基础配置：正确声明 least_conn
least_conn 必须放在 upstream 块的第一行，且不能和其他负载策略（如 ip_hash、hash）混用：
- 写法必须是
least_conn;，不带任何参数，也不支持 weight；加了 weight=2 会被忽略 - 示例配置：
least_conn;
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
}
让连接数统计真实有效
如果每次请求都新建短连接，活跃连接数跳变剧烈，least_conn 就容易选错。关键是要复用长连接，并控制其生命周期：
- 在 upstream 中启用 keepalive，比如
keepalive 32;，每个 worker 进程最多缓存 32 个空闲连接 - 在 location 块中显式开启 HTTP/1.1 并清空 Connection 头：
proxy_http_version 1.1;和proxy_set_header Connection ''; - 后端服务本身要支持长连接（如 Tomcat 配置 keepAliveTimeout，Node.js 默认支持）
- 对上传类或流式响应场景，可适当缩短 keepalive_timeout（如设为 5s），避免慢连接长期占位
排除“假空闲”节点
least_conn 只看连接数，不判断服务是否真能响应。一台机器进程卡死但 TCP 连接未断，它仍可能被当成“最空闲”：
- 必须搭配主动健康检查，例如用
nginx_upstream_check_module（需编译）或 OpenResty 的 check 指令 - 典型检查配置：
check interval=3 rise=2 fall=3 timeout=1 type=http;，定期发 GET /health 探针 - 配合
max_conns设置单节点硬上限（如server ... max_conns=200;），防止慢请求拖垮整条连接队列
验证是否生效
不能只看日志请求数，要观察实时连接分布：
- 开启 stub_status 模块，在 server 块中加
location /nginx_status { stub_status on; }，访问后查看各 server 的 active 连接数 - 压测时用 curl -I 多次请求，比对后端 access log 中各节点实际接收的连接数是否随时间趋于均衡
- 注意：连接数低 ≠ 后端一定空闲，但显著低于其他节点时，least_conn 就在起作用
