nginx中backup备用服务器实现热备切换，本质是主节点全部失效后自动接管流量的服务级故障接管机制；它默认不参与轮询，仅当所有非backup节点被标记不可用时启用，自身支持max_fails和fail_timeout防雪崩，并需配合proxy_next_upstream及严格超时控制才能生效。
在 Nginx 中配置 backup 备用服务器实现热备切换，本质是利用 upstream 模块的被动容灾机制：主节点全部失效后，流量才自动导向 backup 节点，无需人工干预，也不依赖外部工具。它不是“实时同步热备”，而是“服务级故障接管”，关键在于正确声明、合理探测、严格超时。
明确 backup 节点的行为逻辑
backup 服务器默认不参与任何常规负载（轮询、加权、least_conn 等），只有当所有非 backup 的 upstream 成员都被标记为“不可用”时，Nginx 才启用它。这种设计确保了主集群优先承载流量，backup 仅作为兜底通道。
- backup 节点本身也支持 max_fails 和 fail_timeout，防止它自己也出问题导致雪崩
- 它不参与健康探测的“主动投票”，但会受 proxy_next_upstream 影响——如果 backup 自身返回 502/504 且该状态码被启用重试，请求可能失败而非继续转发（因无其他节点可用）
- 多个 backup 节点可共存，它们之间仍按常规策略（如轮询）分发，但前提是所有非 backup 节点均已下线
基础 backup 配置写法
在 http 块中定义 upstream，直接在 server 行末尾添加 backup 关键字：
upstream app_backend {
server 192.168.1.10:8000 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8000 max_fails=3 fail_timeout=30s;
server 192.168.1.12:8000 backup max_fails=2 fail_timeout=20s;
}
- 前两台是主服务，连续失败 3 次、30 秒内不再尝试；第三台是 backup，自身也设防（失败 2 次即剔除，20 秒恢复窗口）
- backup 后不能跟 weight 或 backup 再叠加，语法错误
- IP 和端口必须真实可达，backup 节点需能独立处理全量请求（容量、配置、数据状态均需就绪）
必须配套的 proxy_next_upstream 与超时控制
仅加 backup 不够——Nginx 默认只在连接拒绝或超时时判定失败，后端返回 502/503 等 HTTP 错误不会触发切换。必须显式开启错误码重试，并收紧超时，避免用户卡住：
location / {
proxy_pass http://app_backend;
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 3;
proxy_connect_timeout 3s;
proxy_send_timeout 5s;
proxy_read_timeout 10s;
}
- proxy_next_upstream 定义哪些响应被视为“失败”，从而触发换节点；http_502 必须包含，因为上游宕机常返回此码
- proxy_next_upstream_tries 限制总尝试次数（含首次+最多 2 次重试），防止循环或长等待
- 三个 timeout 值要阶梯递增，且远小于业务容忍阈值（如用户感知卡顿通常在 3–5 秒）
上线前验证是否真能热备切换
配置完别急着上生产，手动模拟故障观察行为：
- 停掉一台主 server（如 systemctl stop app-service），用 curl -I 测试，确认响应仍为 200，access log 显示请求打到其余主节点
- 再停掉第二台主节点，使所有非 backup 全部不可用，观察 access log 是否开始出现 backup 节点 IP 的访问记录
- 检查 Nginx error log，应有类似 upstream server temporarily disabled 的日志，说明故障摘除生效
- 故意让 backup 节点也返回 503，看是否返回 502 给客户端（因无其他节点可试），验证兜底边界
