backup 是故障兜底路由开关，仅在所有非 backup 节点被被动健康检查标记为 down 后才启用；其切换与恢复全自动，依赖 max_fails 和 fail_timeout 配置，无容错参数则形同虚设。
backup 参数不是“热备开关”，而是“故障兜底路由开关”——它本身不触发切换，只在 Nginx 判定所有非 backup 节点不可用后，才让该节点参与转发。真正决定“何时切、切得准不准”的，是被动健康检查机制。
backup 的本质：仅兜底，不抢流
加了 backup 的 server 默认被跳过，Nginx 完全不会向它发请求。它不会主动探活，也不会因其他节点负载高而分担压力。只有当所有非 backup 节点都被标记为 down 时，backup 才会被纳入可用池。
- 主节点必须显式配置 max_fails 和 fail_timeout，否则永远不会被标记为 down，backup 就永远沉睡
- 多个 backup 节点之间按轮询或权重调度（若设了 weight）
- backup 节点自己也建议配 max_fails（如
max_fails=2 fail_timeout=30s），避免它出问题后持续被轮询导致雪崩
健康检查是 backup 生效的前提
仅写 server 192.168.1.11:8080 backup; 是无效的。Nginx 标记节点为 down 的唯一依据是：某次请求失败（连接超时、拒绝、返回 502/503/504 等）且达到 max_fails 次数。
- max_fails=3 表示连续 3 次失败后标记为不可用
- fail_timeout=30s 指该节点被标记为 down 后，30 秒内不再尝试，之后自动重试
- 主节点恢复后，流量自动切回；backup 节点退回到待命状态，全程无需 reload
多级降级：backup + error_page 实现接口级兜底
backup 解决的是服务级灾备，但无法应对接口级异常（例如 /payment 接口返回 500，但服务进程仍在）。这时需配合 proxy_next_upstream 与 error_page：
- 在 location 中启用重试：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504; - 用
error_page 502 503 504 = @fallback;将失败导向备用逻辑 - @fallback 可指向静态维护页、本地缓存、或另一个 upstream（如备用机房）
生产建议：冷备 vs 热备场景适配
backup 更适合冷备（低频接管、资源闲置）；若需热备分担流量，应改用 weight + max_fails 组合，并去掉 backup 标记。
- 冷备场景：主节点高权重 + backup 节点，零流量干扰
- 热备/多机房容灾：用 weight 控制流量倾斜（如主机房 weight=10，备机房 weight=3），所有节点都参与轮询
- Windows 环境无主动 health_check，只能依赖被动机制，max_fails 和 fail_timeout 配置更需贴合网络实际（抖动多则调大，敏感服务则调小）
