least connections算法易致雪崩，需配合slow_start渐进加权、主动健康检查识别真实就绪状态、max_conns硬限流及灰度发布人工干预。
Least Connections 算法本身不区分“空闲”和“刚启动”，只要连接数为 0 或极低，就会被优先选中——这在节点扩容或重启后极易引发雪崩。真正起作用的不是算法，而是配套的渐进式接入机制。
用 slow_start 实现平滑冷启动
这是最直接有效的防护手段：新节点上线时，Nginx 不会立即让它参与 full load 调度，而是逐步提升其权重，让连接数自然爬升。
- 在 upstream 的 server 行中添加 slow_start=30s（单位为秒），例如：
server 192.168.1.20:8080 slow_start=30s; - Nginx 会在 30 秒内将该节点的权重从 0 线性提升至配置值（未设 weight 则为 1）
- 期间 least_conn 仍生效，但该节点初始权重低，被选中的概率大幅下降
- 注意：slow_start 仅对新加入或刚恢复的节点生效；已在线节点重启后需手动触发状态重置（如 reload 配置 + 清除健康检查状态）
配合健康检查避免“假空闲”
刚启动的节点可能服务未就绪（如 Spring Boot 正在初始化 Actuator、数据库连接池未填满），但 TCP 已通、连接数为 0，least_conn 会误判为可用。
- 必须启用主动健康检查，探测真实业务就绪状态，例如：
check interval=5 rise=3 fall=2 timeout=2 type=http match=health; - 定义匹配规则
match health { status 200; body ~ "UP"; }，确保只在 /health 返回成功且含 UP 字样时才标记为 healthy - 被动检查（
proxy_next_upstream）无法识别“启动中”状态，仅靠它不够
设置 max_conns 防止单点过载
即使 slow_start 和健康检查都到位，突发流量仍可能在权重上升过程中压垮节点。max_conns 提供硬性容量兜底。
- 为新节点设置保守上限，例如：
server 192.168.1.20:8080 slow_start=30s max_conns=100; - 当该节点活跃 upstream 连接 ≥ 100，Nginx 自动跳过，继续找下一个连接数最少的健康节点
- 该值应略高于节点预估的初始承载能力（如线程池大小 × 平均并发系数），而非峰值容量
运维侧配合：控制上线节奏与可观测性
配置只是基础，人工介入同样关键：
- 灰度发布时，先将新节点 weight 设为 1（默认），再加 slow_start 和 max_conns，避免与其他高权重大节点直接竞争
- 上线后紧盯
/nginx_status中该节点的 Active connections 和 Requests 数，确认是否按预期缓慢上升 - 若发现连接数飙升快于 slow_start 曲线，立即临时标记
down或调低max_conns，排查后端初始化瓶颈（如慢 SQL、缓存未预热）
