least_conn算法使Nginx将新请求优先分配给当前活跃连接数最少的后端服务器，适用于性能不均、响应波动大或长连接多的场景；需在http块内配置upstream并启用keepalive及健康检查。
least_conn 算法让 Nginx 把新请求优先发给当前活跃连接数最少的后端服务器，不看权重、不按顺序，只看“谁手头活儿最少”。它特别适合后端性能不齐、响应时间波动大或长连接多的场景，能有效避免某些节点连接堆积而其他节点空闲的问题。
基础配置写法
在 nginx.conf 的 http 块内定义 upstream，首行直接写 least_conn：
- upstream 必须放在 http 块下，不能嵌套在 server 或 location 中
- server 行后面不加 weight（least_conn 会忽略 weight，仅用作初始调度参考）
- 健康检查参数如 max_fails 和 fail_timeout 可照常使用，不影响 least_conn 逻辑
适配性能差异大的后端
当部分服务器明显更强时，可用 max_conns 间接体现容量差异：
- 给高性能节点设更高的 max_conns，比如 2000；普通节点设 800
- least_conn 仍选连接数最小者，但一旦某节点达到 max_conns，后续请求自动跳过它
- 这相当于一种“带硬上限的动态调度”，比纯 weight 更贴近真实承载能力
配合 keepalive 提升复用效果
单独用 least_conn 容易因频繁建连削弱效果，必须搭配 keepalive 才能稳定发挥：
- 在 upstream 块中显式添加 keepalive 指令，例如 keepalive 32（每个 worker 最多缓存 32 个空闲连接）
- location 中需启用 HTTP/1.1 并清空 Connection 头：proxy_http_version 1.1; proxy_set_header Connection ''
- 后端服务本身要支持长连接（如 Tomcat 开启 keepAliveTimeout，Node.js 默认支持）
验证与调优建议
配置生效后，可通过 stub_status 模块查看各 upstream server 的活跃连接数变化趋势：
- 观察是否出现某节点连接数长期显著高于其他节点——可能是 max_conns 设置不合理或后端响应异常
- keepalive 数值不宜过小（如 ≤4），否则多 worker + 多 server 下实际可用空闲连接极少
- least_conn 不自动剔除故障节点，务必单独配置 health_check 或 max_fails/fail_timeout
