新节点上线预热需满足三条件：启用支持权重的负载算法（如least_conn）、配置健康检查触发恢复事件、显式设置weight与slow_start。否则预热失效，流量仍会瞬间打满。
要让新节点上线时不被瞬间打满，关键不是加个 slow_start 就完事，而是让它真正“动起来”。这个参数只在特定条件下才起作用，配置错一个环节，它就完全静默——流量照常猛灌，预热形同虚设。
必须用支持动态权重的负载算法
slow_start 只对能感知权重变化的调度策略生效。默认的 round-robin 是静态均分，完全无视权重调整，写了也白写。
- 推荐 least_conn：按实时连接数 + 权重综合选节点，权重一变它立刻响应，最适合预热场景
- ip_hash 或 hash $request_uri consistent 也可用，但要注意 ip_hash 会固定路由，slow_start 效果体现在单节点权重渐进上
- 别用
hash（无 consistent）、random或没声明任何算法的 upstream —— 这些都不支持
必须搭配健康检查才能触发
slow_start 不是“一加进去就启动”，而是等 Nginx 判定节点“刚恢复健康”时才开始计时。没有健康状态跃迁，就不会有慢启动。
-
开源版用被动检查：配
max_fails=3 fail_timeout=15s，节点连续失败后被摘除，15 秒后重试；一旦探测成功，立即启动 slow_start 计时 -
Nginx Plus 或 OpenResty 可用主动检查：如
health_check interval=5 fails=2 passes=2，更精准，避免“端口通但应用挂”的假上线 - Java 应用建议暴露
/actuator/health等端点，确保返回 200 才算健康，不能只看端口连通性
weight 和 slow_start 必须一起写
slow_start 是在 weight 基础上做线性爬升，不是独立参数。不写 weight，它就没有基准可升。
- 即使想用默认值 1，也要显式写成
weight=1 slow_start=60s - 若设
weight=10 slow_start=90s，效果是：第 0 秒权重 ≈ 0，第 45 秒 ≈ 5，第 90 秒 = 10 - 时间单位支持
s和ms，例如slow_start=500ms适合极短预热需求
验证是否真正在工作
没有图形界面，但可通过日志和请求分布观察效果：
- 在
log_format中加入$upstream_addr和$time_iso8601，按秒统计新节点请求数，应呈近似线性增长 - 查看 error.log 是否出现
upstream server temporarily disabled → re-enabled，确认恢复事件被识别 - 新节点应用日志中观察请求量是否随时间缓慢上升，而非上线即峰值
