Nginx中backup节点真正生效的关键是：必须使用round-robin调度，主节点需配置max_fails+fail_timeout，location中配proxy_next_upstream error timeout http_502-504，且backup自身须具备独立承载全量流量的能力。
在 Nginx 中让备用节点（backup）真正生效，关键不是“写上 backup 就能用”，而是确保健康检查机制完整、调度策略匹配、且主节点确实被正确标记为不可用。否则 backup 节点永远处于闲置状态。
必须用轮询模式，且不能全标 backup
backup 只在默认的 round-robin 调度下起作用。如果你用了 ip_hash、least_conn 或其他第三方模块的负载策略，backup 会被直接忽略。
- upstream 块中至少要有一个没加
backup的 server，否则 Nginx 启动时会报错 “no live upstreams” - backup 节点不继承主节点的
weight、max_fails等参数，如需控制其行为，得单独显式配置
健康检查必须配全，否则 backup 永远不触发
Nginx 默认只靠 TCP 连接失败判断节点状态。如果后端进程没死但 HTTP 返回 503、超时或返回异常内容，Nginx 不会自动摘除——backup 就不会启用。
- 在 upstream 中给每个主节点加上
max_fails=3 fail_timeout=30s - 在对应 location 块中加上
proxy_next_upstream error timeout http_502 http_503 http_504 - 这两个参数必须同时存在才有效，单配一个不起作用
backup 节点自身要能独立扛住全部流量
切换过去不是“试试看”，而是立刻承接所有请求。如果 backup 节点配置不一致、证书过期、数据不同步或资源不足，切过去照样 502。
- 确保 backup 和主节点使用相同的 SSL 证书、反向代理头（如
X-Real-IP）、超时设置 - 避免把 backup 和主节点部署在同一台物理机或同一可用区，防止共因故障
- 建议 upstream 中加
keepalive 32，location 中配proxy_http_version 1.1和proxy_set_header Connection ''，减少连接干扰健康判断
验证是否真生效，别只停服务
测试时不能只执行 systemctl stop nginx 或杀进程，那只是最简单的场景。还要模拟真实故障：
- 防火墙拦截某台主节点的端口：iptables -A INPUT -p tcp --dport 8080 -j DROP
- 后端返回稳定 503：用 mock 服务或临时改应用配置
- 观察 Nginx error.log：出现
no live upstreams while connecting to upstream表示主节点全挂；出现using backup才说明 backup 已启用
