最小连接调度（least_conn）需配套健康检查、keepalive复用和慢启动机制才有效：健康检查及时剔除故障节点，keepalive避免连接数失真，slow_start防止冷节点雪崩。
最小连接调度（least_conn）本身不直接提升“稳定度”，它只是把新请求发给当前活跃连接最少的健康后端。真正让集群更稳的，是它背后必须配套的一整套机制：健康检查能及时剔除卡死节点，keepalive复用避免连接数虚高，超时与重试策略防止请求堆积在故障服务上。
必须配齐的健康检查机制
只写 least_conn 不起作用。Nginx 默认不主动探测后端是否真活着——进程卡死、GC停顿、线程阻塞但 TCP 连接未断，这类节点仍会被选中。要让 least_conn “看得清”，得靠健康检查：
- 开源版建议用 proxy_next_upstream error timeout http_500 http_502 + 各 server 的 max_fails=2 fail_timeout=15s，靠失败反馈被动摘除
- 商用版或打过 check_module 补丁的，可配置主动探活：health_check interval=3 fails=2 passes=2 match=ok，每 3 秒发一次 GET /health
- match 块里至少校验 HTTP 状态码为 200，再加一个关键响应头（如 X-Status: ok），防止单纯端口通但业务不可用
keepalive 复用直接影响调度灵敏度
least_conn 统计的是“活跃连接数”，包括 keepalive 空闲连接。如果后端不支持复用，或 Nginx 没配 keepalive，每请求建新连又秒关，连接数始终在 0–1 波动，算法退化成随机分发；反之，若空闲长连接太多，连接数居高不下，又会误判节点繁忙。
- upstream 内加 keepalive 32，限制每个 worker 到单台后端的最大空闲连接数
- 后端服务必须开启连接池：Tomcat 设 maxKeepAliveRequests > 0，Node.js 用 agent.keepAlive = true
- 配合 proxy_http_version 1.1 和 proxy_set_header Connection ''，显式关闭响应头中的 Connection: close，让复用生效
权重与慢启动防止冷节点冲击
集群扩容或重启节点后，直接加入 least_conn 组容易引发雪崩——新实例无预热，瞬间承接大量请求，可能因 JVM 预热、缓存未加载而响应变慢，连接快速堆积，反而拖垮整个组。
- 新加 server 时加上 slow_start=30s，它的连接权重从 0 线性升到 1，30 秒后才完全参与调度
- 若节点硬件差异大（如 8C 与 4C 机器混部），用 weight 显式标注：server 10.0.1.10:8080 weight=2 max_fails=2;
- 避免仅靠连接数做唯一依据，对 CPU 密集型服务，weight 可补偿处理能力差异，让调度更贴近真实负载
验证是否真生效的三个观察点
别只看日志里 $upstream_addr 落在哪台，那只是结果。要确认 least_conn 在起作用，得盯住底层状态：
- 用 stub_status 或 Prometheus exporter 查各 upstream server 的 active connections，正常应动态接近、无长期偏离（比如一台持续为 2，另一台长期 20+）
- 压测时对比 $upstream_connect_time 和 $upstream_header_time：前者突增说明连接建立慢（网络或后端 accept 队列满），后者突增才是业务层问题
- 开启 log_format 记录 $upstream_cache_status，排除因缓存失效导致重复打到后端，干扰连接数分布判断
