least_conn在高并发下有效依赖连接数真实反映负载，关键在于健康检查主动灵敏、keepalive大小适中、max_conns体现真实容量、上线节奏平滑可控。
least_conn 在高并发下不是“选连接少的节点”就完事，它真正起效的关键，在于连接数能真实反映后端实际负载。如果连接数失真——比如节点卡死但连接还挂着、空闲长连接占满计数、新节点一上来就被打爆——那 least_conn 反而会加剧不均衡。优化核心是四个协同环节：健康检查要主动灵敏、keepalive 要大小适中、max_conns 要体现真实容量、上线节奏要平滑可控。
主动健康检查必须启用，不能只靠被动重试
被动检查（靠 proxy_next_upstream 触发）只能在请求失败后才标记节点异常，对“连接挂着但不响应”的假活状态完全无感——比如后端线程阻塞、GC 暂停或数据库锁表。此时 least_conn 仍会把新请求分过去，导致超时堆积。
- 优先启用 active health_check：interval=3s、fails=2、passes=2，并用 match 校验 HTTP 状态码和关键响应头（如 X-App-Status: ok）
- 若只能用 passive 模式，至少配 proxy_next_upstream error timeout http_500 http_502，配合 max_fails=2 fail_timeout=15s，让异常节点快速隔离
- 健康检查路径务必独立：轻量、绕过缓存和鉴权，避免检查本身加重后端压力
keepalive 值要反推后端承载力，不是越大越好
upstream 中的 keepalive 会把空闲连接计入活跃连接总数。设得过大，空闲连接长期占着连接数，least_conn 就会误判某台机器“很忙”；设得太小，又频繁建连，抵消算法收益。
- 按后端单实例平均并发连接数反推：若稳定承载 20–30 并发、worker_processes 为 4，建议 keepalive 32（单 worker 最多复用 8 条）
- 配套设置 keepalive_timeout 60s 和 keepalive_requests 1000，避免连接长期空闲或单连接处理过多请求导致状态污染
- 务必开启 proxy_http_version 1.1 和 proxy_set_header Connection ""，显式关闭客户端 Connection 头；同时检查后端响应是否含 Connection: close（常见于错误返回或 WAF 干预），否则连接池会失效
用 max_conns 替代 weight 实现容量感知调度
least_conn 原生不支持 weight，但 max_conns 是更贴近真实瓶颈的软性约束。当某节点活跃连接数 ≥ max_conns，Nginx 直接跳过它参与比较，哪怕它当前连接数仍是“最少”之一。
- 高性能节点（如 32C64G）可设 max_conns=3000，普通节点（16C32G）设 max_conns=1200
- 注意：max_conns 是硬限制，不会排队等待；上线新节点时加 slow_start=30s，让连接权重从 0 线性升至满额，避免冷启动冲击
- 这比单纯调 weight 更有效——尤其在 CPU 或内存受限的计算密集型服务中，能防止小规格节点率先打满
监控要盯住“活跃连接趋势”，不是瞬时快照
least_conn 的效果最终要靠数据验证。单看某次请求选了哪台机器没意义，重点是观察各节点活跃连接数随时间的变化曲线是否平滑收敛。
- 关注指标：upstream\_server\_active（每个 upstream server 的当前活跃连接数）、upstream\_server\_max\_conns（配置上限）、upstream\_server\_health（健康状态）
- 警惕“连接数低但延迟高”的节点——可能已卡住但尚未触发健康检查失败，需结合响应时间日志交叉判断
- 建议用 Prometheus + nginx-vts-exporter 或商业版 Nginx Plus 的实时仪表盘，每 5 秒采集一次趋势，而非依赖单点采样
