least_conn需配合健康检查、keepalive、keepalive_requests和max_conns四要素才有效：否则因连接统计失真或长连接绑定导致负载倾斜。
least_conn 本身不直接“处理”倾斜，而是通过动态选择连接数最少的后端来降低倾斜发生的概率。但它真正起效的前提是一整套协同配置——单独加一行 least_conn 很难见效，甚至可能看不出变化。
为什么 least_conn 容易失效
常见失效场景不是算法问题，而是 Nginx 看不到真实负载：
- 后端节点宕机或卡死，但没被健康检查及时剔除，仍参与 least_conn 比较
- 客户端或后端未开启长连接，每个请求都新建 TCP 连接，活跃连接数始终接近 0，least_conn 变成轮询或随机
- 某台机器响应慢、连接长期挂起，却因缺少
max_fails和fail_timeout未被隔离，连接越堆越多 - 后端存在连接泄漏（如未正确关闭 socket），Nginx 统计的连接数比实际高，误导调度决策
必须配齐的四个基础项
缺一不可，否则 least_conn 就是摆设：
- 在 upstream 块中显式写上
least_conn;（不能省略，也不能混在其他策略里） - 每个
server行加上max_fails=2 fail_timeout=15s，启用被动健康检查 - 配置
proxy_next_upstream error timeout http_500 http_502;，让失败请求自动重试其他节点 - 启用 upstream 级 keepalive：
keepalive 32;，并确保后端服务（如 Tomcat、Node.js）也支持连接复用
配合 keepalive_requests 控制连接驻留时长
长连接容易导致请求长期绑定某台后端，加剧倾斜。这时 keepalive_requests 就很关键：
- 设为较小值（如 25–50），让一个 keepalive 连接只处理有限请求数，之后主动关闭回归连接池
- Nginx 在下次请求时重新执行 least_conn，提升再分配机会
- 避免设过大（如 1000+），否则一个连接可能持续打到同一台后端几百次
- 需与
keepalive_timeout协同：比如timeout 30s; requests 25;，任一条件满足即回收连接
用 max_conns 实现软性容量控制
当集群中机器性能不均时，仅靠 least_conn 不够，max_conns 能补足这一环：
- 为高性能节点设置更高上限，例如
server 10.0.1.10:8080 max_conns=2000; - 为普通节点设较低值，例如
server 10.0.1.11:8080 max_conns=800; - 一旦某节点达到
max_conns，least_conn 会自动跳过它，新请求转向连接数更少且未达上限的节点 - 这相当于一种“带容量边界的 least_conn”，比单纯 weight 更贴近真实并发承载力
