least conn 在高并发下通过实时选择连接数最少的后端实现精准负载均衡，尤其适用于响应时间差异大、长连接多、节点能力不均的场景；需配合 keepalive、http/1.1、max_conns 和健康检查才能发挥实效。
Least Conn 在高并发下不是“自动变强”，而是更精准地把请求分给真正空闲的后端——它不靠预设规则，只看此刻谁手头的活儿最少。这对响应时间差异大、长连接多、节点能力不均的场景特别有效，但用不好反而会放大失衡。
为什么高并发时轮询容易失效
高并发本身不直接触发 least_conn 的优势，真正起作用的是并发请求背后的“耗时离散性”。比如：同一秒内既有 50ms 的缓存读取，也有 6 秒的报表生成；或者大量 WebSocket 连接长期挂起。轮询按顺序派单，不管某台机器是否正卡在慢请求里，结果就是连接越堆越多，而其他机器闲置。监控上常看到某节点 conn_established 持续飙升，CPU 却不高——这正是 least_conn 要解决的“隐性过载”。
关键配置必须到位，否则形同虚设
- upstream 中必须显式写 least_conn，不能只靠默认或注释掉
- 必须配合 keepalive N（如 keepalive 32），否则每个请求都新建连接，活跃连接数≈请求数，least_conn 退化为近似轮询
- location 块要启用 HTTP/1.1 并透传 Connection 头：proxy_http_version 1.1 和 proxy_set_header Connection ""
- 后端服务需支持长连接，例如 Tomcat 设置 keepAliveTimeout，Node.js 确保未禁用 keep-alive
应对节点能力差异：用 max_conns 替代 weight
least_conn 不识别 weight，但你可以用 max_conns 实现软性容量控制。它不是硬限流，而是在 least_conn 决策时参与比较：当某节点连接数达到 max_conns，Nginx 就不再选它，哪怕它当前连接数仍是全场最低之一。
- 高性能节点可设 max_conns=2000
- 普通节点设 max_conns=800
- 该值应略低于后端实际连接处理上限，留出缓冲空间
健康检查不可省，least_conn 自己不排障
least_conn 只统计连接数，不判断后端是否存活。一台宕机的机器，只要 TCP 连接还没超时断开，它的连接数可能还是 0，流量就会持续打过去。必须搭配主动健康检查：
- HTTP 场景：用 check interval=3 rise=2 fall=3 timeout=1
- TCP 场景：用 health_check 或 use_healthcheck
- 被动探测也可作为补充：max_fails=3 fail_timeout=30s
