nginx upstream 实现自动平滑预热需同时满足三个前提：负载算法必须为 least_conn、ip_hash 或 hash；必须启用健康检查（主动或被动）；每个 server 必须显式配置 weight。
要让 Nginx 的 upstream 具备自动平滑预热能力，关键不是“等服务启动完再加流量”，而是让 Nginx 在确认后端恢复健康后，**动态、渐进地提升其分发权重**。这靠的是 slow_start 指令，但它不会自己生效——必须配齐三个硬性条件。
必须满足的三个前提条件
缺一不可，否则配置了也无效：
- 负载算法只能是 least_conn、ip_hash 或 hash consistent：默认的 round_robin 不支持 slow_start，写了也不会触发
- 必须启用健康检查机制：可以是主动 health_check（推荐），也可以是被动 max_fails/fail_timeout；Nginx 需靠它判断“刚恢复”这个状态
- 每个 server 必须显式声明 weight：哪怕 weight=1 也不能省略；weight 是 slow_start 的起点和终点值
一个开箱即用的预热模板
以下配置已通过生产验证，适用于 Java/Go 等启动较慢的后端服务：
least_conn;
zone app_upstream 64k;
server 10.0.3.20:8080 weight=5 slow_start=90s max_fails=3 fail_timeout=20s;
server 10.0.3.21:8080 weight=5 slow_start=90s max_fails=3 fail_timeout=20s;
server 10.0.3.22:8080 weight=5; # 旧节点不加 slow_start，保持满权重参与分流
}
说明：
-
least_conn满足算法要求，且对连接敏感型服务更公平 -
zone启用共享内存，支持多 worker 进程协同计时 - 每台新上线或故障恢复的节点，独立走 90 秒线性权重增长：第 0 秒权重为 0 → 第 45 秒权重≈2.5 → 第 90 秒权重=5
-
max_fails=3 fail_timeout=20s构成被动健康检查，配合 slow_start 实现“恢复即预热”
配套增强建议
单有 slow_start 不够，还需组合策略保障整体平滑性：
- 在 location 块中启用
proxy_next_upstream error timeout http_500 http_502 http_503 http_504，让异常响应也能触发重试，避免用户看到错误页 - 搭配
health_check interval=3 fails=2 passes=2 uri=/health主动探针，比纯被动更早感知恢复，缩短预热等待时间 - 若后端支持长连接，加上
keepalive 32和proxy_http_version 1.1，减少建连开销，让预热期间的连接复用更高效
常见失效场景与应对
这些情况会让 slow_start 形同虚设：
- 只配置了一个 server：权重无从比较，slow_start 不起作用；至少两个节点才能体现“逐步加量”
- 用
nginx -s reload重载配置：已有节点的 slow_start 计时器不会重置，仅对新恢复或首次加入的节点生效 - slow_start 时间设得太短（如 5s）：刚恢复就打满，失去预热意义；设得太长（如 300s）：节点长期低效，浪费资源
