slow_start通过让新恢复节点权重从0线性增至配置值实现冷启动保护，需同时满足三个前提：使用least_conn等支持动态权重的算法、启用健康检查（主动或被动）、显式配置weight；时间建议设45–60秒。
用 slow_start 保护刚上线的后端节点，核心是让 Nginx 在节点“恢复健康”后，不立刻分发全量请求，而是把它的权重从 0 开始，在设定时间内线性升到配置值——流量自然跟着平缓增长。
必须配齐的三个前提条件
缺一不可，否则写了也无效：
-
负载算法不能用默认 round_robin：必须显式指定
least_conn、ip_hash或hash $request_uri consistent。只有这些算法支持动态调整权重。 -
必须启用健康检查机制：要么用主动探测（
health_check，需 Nginx Plus 或 OpenResty），要么用被动探活（max_fails=3 fail_timeout=15s）。Nginx 靠它识别“这台刚从 down 变成 up”，才会触发slow_start计时。 -
weight 必须显式写出：哪怕就是
weight=1，也不能省略。slow_start是在该weight基础上做线性提升，不是凭空生效。
时间设置要贴合真实预热耗时
Java 应用冷启动常见瓶颈包括 HikariCP 连接池填满、Redis 客户端初始化、Caffeine 缓存加载、Spring 上下文就绪等。实测这些操作通常需要 30–50 秒。建议：
- 设
slow_start=45s或60s，比实测耗时多留 10–15 秒缓冲； - 避免设成
5s或10s——起不到缓冲作用； - 也不建议超过
120s——节点长期低效，拖慢扩容节奏。
典型配置示例（开源版 Nginx 可直接用）
以下配置启用被动健康检查 + 权重渐进 + 连接数均衡：
upstream app_backend {
least_conn;
server 10.0.1.10:8080 weight=3 slow_start=60s max_fails=3 fail_timeout=15s;
server 10.0.1.11:8080 weight=3 slow_start=60s max_fails=3 fail_timeout=15s;
}
说明：
- 两台后端独立计时，重启其中一台，另一台不受影响；
-
max_fails=3 fail_timeout=15s构成被动检查：连续 3 次失败后摘除，15 秒内不发请求，之后尝试恢复； - 一旦某台被标记为 healthy，Nginx 立即启动 60 秒
slow_start，权重从 0 → 3 线性增长。
怎么确认它真的在工作
不能只看配置有没有写，得验证是否真正触发：
- 查 Nginx error log：出现
upstream server restored表示节点已恢复健康，slow_start此时才开始； - 开启带
$upstream_addr的 access_log，按秒统计各后端请求数，画出趋势图——应看到上线节点的请求占比从接近 0 缓慢上升； - 使用
nginx-module-vts插件，调用/status/format/json接口，查看对应 server 的effective_weight字段，它会实时反映当前权重值。
