加权轮询节点恢复后流量冲击源于nginx未平滑过渡权重及健康状态同步，关键在恢复时机、健康检查配置（如max_fails/fail_timeout）与权重生效逻辑配合；开源版不支持主动健康检查，reload会重建upstream导致“零缓冲”承接流量，且ip_hash/least_conn等策略可能绕过weight。
加权轮询节点恢复后出现流量冲击，本质是Nginx在节点“下线→上线”过程中未平滑过渡权重或未同步健康状态，导致请求集中涌向刚恢复的节点。关键不在权重数值本身，而在恢复时机、健康检查机制与权重生效逻辑的配合。
确认节点是否真正完成健康检查恢复
Nginx默认不主动探测后端存活，需显式配置健康检查（如 max_fails + fail_timeout），否则节点标记为“down”后，即使进程已重启，Nginx仍可能延迟数秒至数十秒才重新纳入调度。此时若手动 reload 配置或节点自动重试成功，会瞬间接收按权重比例分配的全部流量，造成冲击。
- 检查 upstream 中是否启用故障剔除：每个 server 行应含类似
max_fails=3 fail_timeout=30s - 验证恢复行为：临时将某节点停掉，观察 access log 是否停止收请求；再启动服务，用
curl -I http://upstream-ip/health确保返回 200，再等满fail_timeout时间后，才观察日志是否开始收新请求 - 注意：开源版 Nginx 不支持主动健康检查（
health_check指令仅限 Plus 版），依赖被动失败计数触发恢复
检查权重变更是否被平滑加载
直接修改 weight 值后执行 nginx -s reload，会导致整个 upstream 组重建，旧连接逐步关闭、新连接立即按新权重分发——对刚恢复的节点而言，等于“零缓冲”承接流量。
- 避免在业务高峰 reload 权重配置；如需调整，建议先设较低初始权重（如
weight=1），待稳定后再逐步调高 - 不要依赖 reload 实现“热加权”，开源 Nginx 无运行时权重热更新能力；若需动态调节，需结合外部控制脚本 + 共享内存或 Lua 模块（如 lua-upstream-nginx-module）
- 可通过
stub_status或nginx_upstream_check_module（第三方）监控各节点当前活跃连接数，对比权重占比是否匹配
观察请求分配是否受其他策略干扰
加权轮询不是孤立生效的。若 upstream 块中混用了 ip_hash、least_conn 或 proxy_cache 相关设置，实际调度逻辑可能绕过 weight。
- 确认 upstream 块内未同时启用
ip_hash（它会强制会话绑定，完全忽略 weight） - 检查是否误配了
least_conn——该策略优先发往连接数最少的节点，当恢复节点连接数为 0 时，会瞬间吸引大量新长连接 - 查看 location 块中是否有
proxy_next_upstream设置（如error timeout http_500），它可能在上游失败时触发重试，间接放大对恢复节点的试探性请求
模拟压测验证恢复过程是否可控
真实冲击往往出现在自动恢复瞬间，而非人工操作时。建议构建可复现的测试路径：
- 用
iptables -A INPUT -s 192.168.1.x -j DROP模拟节点宕机，触发 Nginx 标记为 down - 等待超过
fail_timeout后，放开 iptables，并立刻用 ab 或 wrk 发起阶梯式并发（如 10 → 50 → 200 QPS） - 实时 tail -f 各后端 access.log，统计每秒请求数；重点关注恢复节点在第 1/5/30 秒的请求占比是否显著高于权重预期值
- 若冲击明显，说明
fail_timeout过短或权重设置过高，应延长故障窗口或降低初始权重
