最可靠方式是直接模拟故障并观察恢复行为。Nginx故障转移依赖fail_timeout窗口与后续请求探测，非秒级心跳恢复，测试需包含时间等待和真实请求验证；后端需返回唯一标识便于追踪流量；通过停服/防火墙触发故障，curl多次触发失败计数，确认节点被标记down且流量切至其他节点；等待fail_timeout后发请求探测，若恢复则自动重入轮询，回流为渐进式，轮询下立即参与分发，加权下严格按weight分配。
直接模拟故障再观察恢复行为，是最可靠的方式。Nginx 的故障转移自动恢复依赖于 fail_timeout 时间窗口和后续请求探测，不是秒级“心跳式”恢复，所以测试必须包含时间等待和真实请求验证两个关键环节。
准备可验证的后端服务
确保每个 upstream 节点返回明确标识（如主机名或 IP），便于区分流量走向：
- 用简单 HTTP 服务快速搭建，例如 Python 的
http.server或nginx -c启动多个静态响应实例 - 每个节点响应体中嵌入唯一标识，比如
curl http://192.168.1.10:8080返回node-1，curl http://192.168.1.11:8080返回node-2 - 避免使用无状态或缓存代理层干扰判断，直连后端验证最准
触发故障并确认节点被标记为 down
手动让某个后端不可用（如停掉进程、防火墙拦截、或返回固定 503），然后发请求触发失败计数：
- 执行
curl -I http://your-nginx-ip/多次（至少达到max_fails次），观察 error.log 是否出现no live upstreams或connect() failed日志 - 检查
nginx -T输出中对应 server 行是否被标记为down（需开启upstream_conf模块或配合 OpenResty 才能实时查状态；开源版建议靠日志+请求结果反推） - 确认流量已全部切到其他节点（连续 curl 十几次，结果应稳定为非故障节点的标识）
等待 fail_timeout 并验证自动恢复
fail_timeout 不仅是隔离时长，也是“重试窗口”。超时后，Nginx 在下一次请求中会主动探测该节点：
- 等待满
fail_timeout秒（如配置为30s，就等足 30 秒） - 发送一次请求（哪怕只一个
curl），Nginx 会尝试连接原故障节点 - 若此时该节点已恢复（服务重启、防火墙放行），则连接成功，节点重新进入轮询；后续请求将按权重逐步分回
- 若仍失败，则重置失败计数，继续跳过——这个过程无需人工干预
观察流量是否回切（回流）
回切不是瞬间完成，而是渐进式回归，取决于负载均衡算法和当前活跃连接：
- 使用轮询（默认）时，恢复后的节点会立即参与下一轮分发，但因之前积压少，初期流量比例可能偏低
- 使用权重时，只要节点状态为
up，就会严格按 weight 比例分发，无需额外操作 - 建议用脚本持续请求（如
for i in {1..100}; do curl -s http://nginx/; done | sort | uniq -c），统计各节点响应次数，确认比例趋近配置值
