要实现节点恢复后的平滑流量预热，必须使用slow_start参数并满足四个条件：启用least_conn等支持动态权重的负载算法、配置健康检查机制、显式设置weight值、在server指令中完整声明slow_start。
要在节点恢复后实现平滑流量预热，核心是让 Nginx 在该节点被判定为“健康”时，逐步提升其承接流量的能力，而不是一上来就分发全量请求。这靠的是 slow_start 参数，但它不是独立生效的，必须满足几个硬性条件。
必须启用支持动态权重的负载算法
默认的 round-robin（轮询）不支持 slow_start，写了也无效。真正起作用的只有：
- least_conn：按当前活跃连接数 + 权重选节点，权重变化会被实时感知
- ip_hash 或 hash $request_uri consistent：Nginx Plus 支持在状态恢复时响应权重渐进
配置开头必须明确声明，例如：least_conn;，不能省略。
必须搭配健康检查机制
slow_start 不是“一加进去就启动”，而是等节点从 down → up 的状态跃迁时才触发。这就要求 Nginx 能识别“刚恢复”这个事件：
- 被动检查：配
max_fails=2 fail_timeout=10s，连续失败后摘除，恢复后重新纳入并启动 slow_start - 主动检查（Nginx Plus）：用
health_check指向/actuator/health等真实业务就绪端点，比只通端口更可靠
没有健康检查，Nginx 就不知道节点何时“恢复”，slow_start 形同虚设。
weight 必须显式配置且与 slow_start 配合使用
slow_start 是在 weight 基础上做线性爬升，不是凭空生成权重。即使想用默认值，也得写出来：
- ✅ 正确：
server 10.0.1.20:8080 weight=5 slow_start=60s; - ❌ 无效：
server 10.0.1.20:8080 slow_start=60s;（缺少 weight）
时间单位支持 s 和 ms，比如 slow_start=300ms 适合极短预热场景；建议控制在 30–300 秒之间，过短没缓冲效果，过长影响扩容效率。
验证是否真正生效
没有图形界面，但可以靠日志和接口观察：
- 在
log_format中加入$upstream_addr和$time_iso8601，按秒统计新恢复节点的请求数，应呈近似线性增长 - 已部署
nginx-module-vts的，可访问/status查看各节点实时连接与请求分布 - 注意：
nginx -s reload不会重置正在运行的 slow_start 计时器，但nginx -s stop & start（即重启）会重新开始计时
