least_conn在upstream块首行启用，优先调度至活跃连接数最少的后端，适用于长连接多、处理时长差异大的场景；需配合keepalive、max_conns容量控制及健康检查使用。
直接在 upstream 块首行写 least_conn;，Nginx 就会把新请求优先发给当前活跃连接数最少的后端节点。它不看响应时间、不按顺序轮询，只比“谁手头正连着的请求更少”，适合长连接多、处理时长差异大的场景。
基础配置写法
必须放在 http 块内，不能嵌套在 server 或 location 中：
-
least_conn;必须作为upstream块的第一条指令之一，不能加参数 - 每个
server行后面可以写weight，但least_conn实际不使用它做调度依据（仅在初始建连阶段有微弱参考作用） - 健康检查参数如
max_fails=2 fail_timeout=30s可照常配置，不影响最小连接逻辑
适配性能不均的后端
当部分服务器明显更强时，单靠连接数不够公平，可用 max_conns 设定硬性上限：
- 高性能节点设
server 192.168.1.10:8080 max_conns=2000; - 普通节点设
server 192.168.1.11:8080 max_conns=800; - 一旦某节点达到
max_conns，后续请求自动跳过，相当于“带容量感知的动态调度”
必须配合 keepalive 才能发挥效果
没有连接复用，least_conn 容易因频繁建连失真：
- 在
upstream块中加keepalive 32;（建议 ≥16，太小会导致空闲连接池不足） -
location中启用 HTTP/1.1 并清空连接头：proxy_http_version 1.1;和proxy_set_header Connection ''; - 确认后端服务支持长连接（如 Tomcat 的
keepAliveTimeout已开启）
验证与调优要点
配置生效后，重点观察是否真正实现动态均衡：
- 开启
stub_status模块，访问/nginx_status查看各server的active连接数变化趋势 - 若某节点长期连接数偏高，先查是否
max_conns设得太低，再排查该节点响应是否异常变慢或卡死 -
least_conn不主动探测服务状态，务必配max_fails/fail_timeout或第三方健康检查模块防止单点拖累整体
