backup节点仅在所有非backup主节点被健康检查标记为不可用时启用，需配合max_fails、fail_timeout和proxy_next_upstream等参数生效，且仅适用于round-robin模式。
在 Nginx 中，backup 参数用于标记上游（upstream）服务器为备用节点，仅当所有非 backup 的主节点都不可用时才被启用。要验证 backup 节点是否能在主集群故障时正确接管流量，关键不是“模拟切换命令”，而是通过主动使主节点失效，观察 Nginx 是否自动将请求路由到 backup 节点。
确认 upstream 配置中正确使用 backup
确保你的 upstream 块中，backup 节点明确标注了 backup 关键字，且没有其他干扰配置（如 down、weight 过高影响调度）：
upstream backend {
server 192.168.1.10:8080; # 主节点
server 192.168.1.11:8080; # 主节点
server 192.168.1.12:8080 backup; # 备用节点（仅主全挂时启用）
}注意：backup 节点默认不参与负载均衡，也不会响应健康检查探测（除非你额外配置了 health_check 并允许 probe 到 backup）。
主动触发主节点失效（最直接的测试方式）
Nginx 不会“预测”故障，它依赖被动检测（连接失败、超时、5xx 等）来标记节点为不可用。因此测试需人为制造主节点不可达：
- 临时关闭主节点服务：在 192.168.1.10 和 192.168.1.11 上执行
systemctl stop nginx或kill -9对应进程 - 或屏蔽网络访问：在 Nginx 所在机器上用
iptables拦截主节点端口（例如iptables -A OUTPUT -d 192.168.1.10 -p tcp --dport 8080 -j REJECT） - 等待 1–2 次失败尝试（Nginx 默认重试次数为 1，超时由
proxy_connect_timeout等控制），之后该节点会被标记为 failed
可通过 nginx -T | grep -A 10 "upstream" 查看配置，但实际状态需查日志或用工具验证。
验证 backup 是否生效
主节点全部失效后，发起多次请求，检查是否稳定落到 backup 节点：
- 用
curl -v http://your-nginx-domain/多次访问，配合tcpdump或目标服务器 access log 观察来源 IP 和响应内容 - 查看 Nginx error log（如
/var/log/nginx/error.log），应出现类似no live upstreams while connecting to upstream的报错 —— 这说明主节点全挂且 backup 已启用；若仍报错，说明 backup 也异常或未被激活 - 如果启用了
upstream_hash或ip_hash，需注意 backup 节点可能因哈希不匹配而不被选中（backup 在 hash 场景下仍受算法约束，建议测试时先用默认轮询）
进阶：配合 health_check 实现更可靠探测（可选）
如果你使用的是 Nginx Plus 或开源版带 ngx_http_upstream_module 的较新版本（需编译支持），可添加主动健康检查增强可靠性：
upstream backend {
zone backend 64k;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080 backup;
<pre class="brush:php;toolbar:false;"># 主动健康检查（开源版需 patch 或用第三方模块如 nginx_upstream_check_module）
# check interval=3 rise=2 fall=3 timeout=1 type=http;
# check_http_send "HEAD /health HTTP/1.0\r\n\r\n";
# check_http_expect_alive http_2xx http_3xx;}
注意：标准开源 Nginx **不内置主动健康检查**，如需此能力，需使用第三方模块或升级至 Nginx Plus。
