slow_start仅在least_conn、ip_hash或hash consistent等支持动态权重的负载算法下生效，round-robin默认不支持；必须配合健康检查（max_fails/fail_timeout或health_check）触发，且需显式配置weight值。
轮询（round-robin）算法本身不支持 slow_start，直接在默认轮询下配置 slow_start 不会生效——这是最容易踩的坑。
slow_start 只在特定负载策略下起作用
它要求 upstream 必须启用支持动态权重调整的算法，而原生 round-robin 是静态均分、无视权重变化的。真正能配合 slow_start 的是：
- least_conn：按当前活跃连接数 + 权重综合选节点，权重实时变化会被感知
- ip_hash / hash $request_uri consistent：虽属静态哈希，但 Nginx Plus 允许其在健康状态变更时响应权重渐进
如果你坚持用轮询逻辑，必须显式切换策略，例如：
upstream backend {<br> least_conn;<br> server 10.0.1.20:8080 weight=5 slow_start=90s;<br> server 10.0.1.21:8080 weight=5;<br>}
必须搭配健康检查才能触发
slow_start 不是“一加进去就启动”，而是等节点被 Nginx 判定为“刚恢复健康”时才开始计时。这意味着：
- 要配置
max_fails=3 fail_timeout=10s这类被动检查，或使用health_check（Nginx Plus）主动探测 - Java 应用需暴露
/actuator/health等端点，确保返回200才算“健康” - 节点从 down → up 的状态跃迁，才是 slow_start 的起点
weight 和 slow_start 要一起写
开源版 Nginx 不支持 slow_start；Nginx Plus 才有该参数。且它不能单独存在：
- 必须显式声明
weight（哪怕设为默认值 1），否则 slow_start 无基准可升 - 例如：
server 10.0.1.30:8080 weight=1 slow_start=60s; - 时间单位支持
s和ms，如slow_start=500ms适合极短预热场景
验证是否真正在工作
没有图形界面，但可通过日志和接口观察效果：
- 在
log_format中加入$upstream_addr和$time_iso8601，按秒统计新节点请求数，应呈近似线性增长 - 若已部署
nginx-module-vts，访问/status/format/json查看effective_weight字段，它会从 0 缓慢升到配置 weight - 注意：Nginx 重启后 slow_start 计时器重置，但 reload 不影响正在进行的 slow_start 周期
