slow_start可实现后端重启后的流量平滑预热，其本质是让Nginx在后端恢复健康后，将权重从0线性增至配置值；必须同时满足：负载算法为least_conn/ip_hash/hash consistent、启用健康检查（主动或被动）、weight显式配置。
直接用 slow_start 就能实现后端重启后的流量平滑预热，但必须配对关键条件，否则它完全不生效。
slow_start 的真实作用机制
它不是让服务“慢慢启动”，而是让 Nginx 在感知到某台后端恢复健康后，把它的分发权重从 0 开始，在指定时间内线性升到配置的 weight 值。流量随之自然增加，避免刚上线就扛全量请求。
- 第 0 秒：权重为 0，不转发任何请求
- 中间时刻：权重按比例实时计算，比如 30s slow_start 过半时权重是设定值的一半
- 计时结束：权重达到 full，完全参与负载
必须同时满足的三个前提
缺一不可，否则配置了也等于没写：
- 负载算法只能是
least_conn、ip_hash或hash consistent；round_robin（默认）不支持，写了无反应 - 必须启用健康检查机制：要么用
health_check主动探测，要么用max_fails/fail_timeout被动识别故障与恢复 -
weight必须显式写出，哪怕就是weight=1；不能省略，也不能和slow_start冲突
一个可直接复用的配置示例
适用于滚动发布或单点重启场景：
upstream app_backend {
least_conn;
server 10.0.2.10:8080 weight=3 slow_start=60s max_fails=3 fail_timeout=15s;
server 10.0.2.11:8080 weight=3 slow_start=60s max_fails=3 fail_timeout=15s;
}
说明：
- 两台后端都设了 60 秒慢启动，故障恢复后会各自独立走自己的计时流程
-
max_fails=3 fail_timeout=15s构成被动健康检查，Nginx 靠它判断“是否刚恢复” - 重启其中一台后，Nginx 在它通过健康检查瞬间启动 60 秒倒计时，期间流量逐步加压
常见误区与避坑提醒
这些情况会导致 slow_start 形同虚设：
- 只有一台后端服务器：该参数无效，至少需要两个
server才能体现权重变化效果 - 用
nginx -s reload重载配置：不会重置已有节点的 slow_start 计时器，只对“新恢复”或“首次加入”的节点触发 - 时间设得太短（如 5s）或太长（如 300s+）：前者起不到缓冲作用，后者让节点长期低效运行
- 误以为开源版不支持：Nginx 1.19.5+ 开源版已原生支持，无需 Plus 商业版
