least_conn策略通过实时选择连接数最少的后端实现负载均衡，需配合健康检查、keepalive复用及max_conns配置才能生效；多节点连接数相同时按weight加权轮询。
直接在 upstream 块里写 least_conn; 就能启用最小连接数策略，但它不是“设个阈值就自动限流”，而是实时挑当前最空闲的后端——关键在连接数统计是否真实、节点是否可用、连接是否复用。
核心配置很简单，但得配对才生效
只需在 upstream 中声明指令，无需参数：
- 写法示例：
upstream backend {<br> least_conn;<br> server 10.0.1.10:8000;<br> server 10.0.1.11:8000;<br> server 10.0.1.12:8000;<br>} -
least_conn本身不支持weight，但可以混用max_conns来体现能力差异（比如高性能节点设max_conns=2000，普通节点设800） - 健康检查必须额外开启——
least_conn不会自动剔除故障节点，要靠max_fails/fail_timeout或主动 health_check 模块
连接复用直接影响调度效果
如果后端每次请求都新建 TCP 连接，活跃连接数 ≈ 当前请求数，least_conn 就和轮询差不多；要让它真正反映“谁更忙”，就得让连接复用起来：
- 在 upstream 里加
keepalive 32;（推荐 16–64），每个 worker 复用空闲连接 - 后端服务需支持 HTTP Keep-Alive，并设置合理超时（如
keepalive_timeout 75s） - 注意：
keepalive连接会计入活跃连接总数，值设太大可能让“空闲连接”虚高，干扰判断
多节点连接数相同时怎么选
不是随机挑，而是有 fallback 逻辑：
- 先过滤掉不可用节点（down / fail / 超出 max_conns）
- 在剩余节点中找出连接数最小的一批（可能不止一个）
- 这批节点之间按
weight做加权轮询——所以 weight 并非完全无效，只是退居第二顺位
验证和调优要点
上线后不能只看配置有没有写对，得确认行为是否符合预期：
- 开启
stub_status或用$upstream_addr日志字段，观察请求实际落到哪台机器 - 用
ss -s或netstat -an | grep :端口 | grep ESTAB | wc -l查各后端真实 ESTABLISHED 连接数 - 如果发现某台长期空闲，检查它是否有隐式连接泄漏（如后端未 close 连接）、网络延迟高、或防火墙拦截健康检查
