Nginx 中 Upstream 如何配合慢启动 slow_start 参数平滑接入新节点

新节点上线预热需满足三条件：启用支持权重的负载算法（如least_conn）、配置健康检查触发恢复事件、显式设置weight与slow_start。否则预热失效，流量仍会瞬间打满。

要让新节点上线时不被瞬间打满，关键不是加个 slow_start 就完事，而是让它真正“动起来”。这个参数只在特定条件下才起作用，配置错一个环节，它就完全静默——流量照常猛灌，预热形同虚设。

必须用支持动态权重的负载算法

slow_start 只对能感知权重变化的调度策略生效。默认的 round-robin 是静态均分，完全无视权重调整，写了也白写。

1. 推荐 least_conn：按实时连接数 + 权重综合选节点，权重一变它立刻响应，最适合预热场景
2. ip_hash 或 hash $request_uri consistent 也可用，但要注意 ip_hash 会固定路由，slow_start 效果体现在单节点权重渐进上
3. 别用 hash（无 consistent）、random 或没声明任何算法的 upstream —— 这些都不支持

必须搭配健康检查才能触发

slow_start 不是“一加进去就启动”，而是等 Nginx 判定节点“刚恢复健康”时才开始计时。没有健康状态跃迁，就不会有慢启动。

1. 开源版用被动检查：配 max_fails=3 fail_timeout=15s，节点连续失败后被摘除，15 秒后重试；一旦探测成功，立即启动 slow_start 计时
2. Nginx Plus 或 OpenResty 可用主动检查：如 health_check interval=5 fails=2 passes=2，更精准，避免“端口通但应用挂”的假上线
3. Java 应用建议暴露 /actuator/health 等端点，确保返回 200 才算健康，不能只看端口连通性

weight 和 slow_start 必须一起写

slow_start 是在 weight 基础上做线性爬升，不是独立参数。不写 weight，它就没有基准可升。

1. 即使想用默认值 1，也要显式写成 weight=1 slow_start=60s
2. 若设 weight=10 slow_start=90s，效果是：第 0 秒权重 ≈ 0，第 45 秒 ≈ 5，第 90 秒 = 10
3. 时间单位支持 s 和 ms，例如 slow_start=500ms 适合极短预热需求

验证是否真正在工作

没有图形界面，但可通过日志和请求分布观察效果：

1. 在 log_format 中加入 $upstream_addr 和 $time_iso8601，按秒统计新节点请求数，应呈近似线性增长
2. 查看 error.log 是否出现 upstream server temporarily disabled → re-enabled，确认恢复事件被识别
3. 新节点应用日志中观察请求量是否随时间缓慢上升，而非上线即峰值