Nginx slow_start生效需同时满足三条件：启用least_conn等支持权重的负载算法、配置健康检查（max_fails/fail_timeout或health_check）、显式声明weight值；slow_start=60s表示权重从0线性增至配置值，仅在节点由不健康恢复时触发。
Nginx 的 slow_start 参数是专为后端冷启动设计的流量渐进机制——它让新恢复或新上线节点的权重从 0 开始，在设定时间内线性增长到配置值，从而避免首波请求压垮尚未预热的服务（如 Java 应用连接池未满、缓存未加载、JIT 未生效等）。
要真正生效，不能只写 slow_start=60s，必须同时满足三个硬性条件，缺一不可。
必须启用支持动态权重的负载算法
slow_start 只在能感知权重变化的调度策略下起作用：
- ✅
least_conn（推荐）：按实时连接数 + 权重分发，最适配预热场景 - ✅
ip_hash或hash $request_uri consistent：静态哈希类策略也支持权重调整 - ❌
round_robin（默认）：完全忽略权重，写了slow_start也无效
示例：
upstream app_backend {
least_conn; # 必须显式声明
server 10.0.1.10:8080 weight=5 slow_start=60s;
server 10.0.1.11:8080 weight=5 slow_start=60s;
}必须配置健康检查机制
Nginx 仅在“节点状态由不健康变为健康”时触发 slow_start 计时。没有健康感知，就不会启动权重爬升。
-
被动检查（开源版通用）：用
max_fails+fail_timeoutserver 10.0.1.10:8080 weight=5 slow_start=60s max_fails=3 fail_timeout=15s;
含义：连续失败 3 次后摘除，15 秒后尝试恢复；一旦恢复成功，立即开始 60 秒 slow_start。
-
主动检查（需 Nginx Plus 或 OpenResty）：更精准，推荐用于生产
health_check interval=5 fails=2 passes=2;
必须显式声明 weight
slow_start 是在 weight 基础上做线性提升，不是覆盖或替代。即使想用默认权重 1，也必须写出来：
- ✅
server x.x.x.x:8080 weight=1 slow_start=45s; - ❌
server x.x.x.x:8080 slow_start=45s;（weight 省略 → slow_start 不生效）
时间设置要贴合真实预热周期
- Java 应用常见冷启动耗时：30–60 秒（连接池填充、缓存加载、Spring 上下文就绪）
- 推荐值：
slow_start=45s或60s，比实测稳定时间多留 10 秒缓冲 - 避免过短（如
5s）：权重瞬间拉满，等于没设 - 避免过长（如
180s）：节点长期低效，拖慢扩容响应
验证它是否真在工作
光看配置不够，得观察实际行为：
- 查
error.log：出现upstream server restored表示 slow_start 已触发 - 开启带
$upstream_addr的 access_log，按秒统计各后端请求数，应看到新节点请求占比从接近 0 缓慢上升 - 使用
nginx-module-vts插件，调/status/format/json，查看对应 server 的effective_weight字段是否随时间线性增长
不复杂但容易忽略。
