核心是验证主节点失效时Nginx能否自动切至backup节点：停主服务或拦截端口，用curl观察响应是否切换，查error.log确认“upstream temporarily disabled”等日志，并验证proxy_next_upstream重试、backup兜底及全主宕机时backup接管能力。
测试 Nginx 故障转移机制的连通性，核心是验证：当主后端不可用时，Nginx 是否能在不中断服务的前提下，自动将请求转发到备用节点，并确保响应正常、延迟可控、无错误返回。这不是一次“ping 通就行”的简单检查，而是分层验证行为逻辑与真实流量路径。
模拟后端故障并观察 upstream 行为
最直接有效的方式是主动让主节点失联，看 Nginx 是否按预期跳过它：
- 临时停掉主后端服务（如 systemctl stop nginx 或 kill -9 对应进程），或用防火墙拦截其端口（iptables -A INPUT -p tcp --dport 8080 -j DROP）
- 用 curl -v http://your-nginx-domain/api/test 连续发起请求，观察响应来源 IP 或响应头中标识（如 X-Upstream）是否已切换到 backup 节点
- 同时查 Nginx 错误日志：tail -f /var/log/nginx/error.log，确认是否有类似 "upstream timed out" 或 "no live upstreams" 的提示——前者说明正在重试，后者说明所有节点都失效，配置有漏洞
检查被动健康检查是否生效
Nginx 不会实时探测，而是靠真实请求失败来标记节点。要确认标记逻辑正确：
- 在 upstream 中为每个 server 显式配置 max_fails=3 fail_timeout=30s
- 手动向主节点发 3 次失败请求（例如用 curl 访问一个必定返回 502 的调试接口，或直接断开其网络），等待 30 秒
- 执行 nginx -T 2>/dev/null | grep -A 5 "upstream backend" 并结合 curl -I http://127.0.0.1/healthz（若你配了状态页）或第三方工具如 nginx-upstream-check-status（需 Tengine 或 nginx-plus）查看节点当前状态是否为 down
验证 proxy_next_upstream 重试路径是否走通
仅靠轮询跳过 down 节点不够，单次请求失败后能否秒级换节点才是关键：
- 确保 location 块中配置了完整触发条件：proxy_next_upstream error timeout http_502 http_503 http_504
- 加上限制：proxy_next_upstream_tries 3 和 proxy_next_upstream_timeout 10s
- 用 ab -n 100 -c 10 http://your-nginx-domain/api/test 或 wrk -t4 -c100 -d10s http://... 发起压测，同时人为制造主节点不稳定（如间歇性返回 502）
- 检查返回统计：成功率是否接近 100%，平均延迟是否未明显飙升（说明重试及时且未超时）
确认 backup 节点真正兜底可用
backup 不是摆设，必须验证它在全部主节点失效时能接管：
- 停掉所有带 weight 的主节点（不止一个），只留 server ... backup; 在线
- 发起请求，确认能正常返回内容，且响应头或 body 中明确体现来自 backup 实例（如加了 add_header X-Node "backup";）
- 再恢复一个主节点，观察流量是否自动回流（取决于是否启用 preempt 逻辑；开源 Nginx 默认不抢回，需靠 max_fails 自动恢复）
