nginx权重平滑过渡需人为分阶段调权+热重载：新节点初始设低weight（如1），再逐步升至与老节点一致（如10），每次修改后nginx -t校验并reload；同时结合健康检查（rise=3/fall=2）确保服务就绪后再导流，并避免全量同步reload、忽略后端就绪状态及长连接影响。
在 Nginx 中，权重（weight）本身不带时间延迟或自动渐进逻辑，但它是实现新老服务器平滑过渡最直接、最可控的手段——关键在于“人为控制权重变化节奏”+“配合热重载”，而非依赖某个隐藏指令。
初始低权重接入新节点
新服务器上线时，不要直接设为和老节点相同的 weight（比如都设 10），而应压低其初始权重，让流量只按比例少量进入，避免冷启动冲击：
- 老节点保持高权重（如
weight=10或weight=20） - 新节点设极低权重（如
weight=1），相当于仅承接约 5%～10% 的轮询请求（取决于 upstream 中节点数量与权重总和） - 配置示例：
upstream backend {<br> server 192.168.1.101:8080 weight=10;<br> server 192.168.1.102:8080 weight=10;<br> server 192.168.1.103:8080 weight=1; # 新机器，低调入场<br>}<br>
分阶段 reload 提升权重
Nginx 不会自动“随时间增加 weight”，必须通过外部脚本驱动配置变更并触发重载。建议每 5–10 分钟执行一次权重上调 + reload：
- 第一次：新节点
weight=1→weight=3 - 第二次：→
weight=6 - 第三次：→
weight=10（与老节点一致） - 每次修改后务必先
nginx -t校验，再nginx -s reload - reload 是热操作：旧 worker 继续处理存量请求，新 worker 按新权重分发新连接，全程无中断
结合健康检查自动“就绪才导流”
仅靠 weight 控制不够鲁棒。若新服务启动慢、依赖未就绪，低权重仍可能带来失败请求。建议叠加主动健康检查（需 OpenResty 或编译 ngx_http_upstream_check_module）：
- 配置 HTTP 探针（如访问
/health返回 200） - 设置
rise=3 fall=2：连续 3 次成功才纳入轮询池，连续 2 次失败即摘除 - 这样新节点即使已写入配置，也会等真正就绪后才开始收流量，天然形成“等待完成”效果
避免常见陷阱
平滑过渡失效，往往不是配置写错，而是协同环节被忽略：
- 不校验后端 readiness：新服务进程虽启动，但数据库连不上、缓存未预热，此时导流等于制造错误
- 所有 Nginx 实例同时 reload：集群中多个 LB 节点若未错峰操作，可能引发瞬时连接抖动，建议加随机 sleep 或用 Ansible rolling update
-
忽略长连接影响：WebSocket 或 HTTP/1.1 keepalive 连接不会因 reload 立即切换，需确保 proxy_read_timeout 足够长，并启用
proxy_http_version 1.1和proxy_set_header Connection ""
