Nginx的backup是静态冷备标记，仅当所有非backup节点被健康检查（max_fails/fail_timeout）判定为不可用时才启用；必须配合proxy_next_upstream等重试策略及error_page实现完整容灾。
Nginx 的 `backup` 标记本身不触发自动跳转，它只是“静态路由标记”——只有当所有非 backup 节点都被 Nginx 判定为不可用时，才会启用。真正实现“源站集群灾难时自动容灾跳转”，必须把 `backup` 和**故障探测机制 + 重试决策逻辑**绑在一起用。
backup 节点的本质：冷备路由，不是热备服务
标了 backup 的 server 在配置里全程静默，不会收健康检查、不参与负载均衡、不建立长连接预热。它的唯一作用是：当 upstream 中所有非 backup 节点都处于 down 状态 时，成为最后可选的转发目标。
- 主节点哪怕只有一台还活着，backup 就永远不会被选中
- backup 节点自身也应配 max_fails/fail_timeout，防止它自己出问题却持续被轮询
- 多个 backup 节点之间按权重或轮询调度（若都加了 backup），但仍是“全主挂了才启动”的兜底链路
让 backup 生效的关键：配置被动健康探测
Nginx 开源版默认不主动探活，依赖请求失败来标记节点失效。必须显式设置 max_fails 和 fail_timeout，否则 backup 永远不会启用。
- max_fails=2：连续 2 次请求失败（连接拒绝、超时、或 proxy_next_upstream 定义的 5xx）即标记为 down
- fail_timeout=30s：该节点被标记 down 后，30 秒内不再尝试；超时后自动重试一次，判断是否恢复
- 参数需加在每个非 backup 的 server 行末尾，例如：
server 192.168.1.10:8080 max_fails=2 fail_timeout=30s;
决定何时切到 backup：proxy_next_upstream 是开关
仅靠 max_fails 不够——Nginx 默认只对 connect timeout 和 connection refused 计入失败。要让 500/502/503/504 这类 HTTP 错误也触发重试和 fail 累加，必须配置：
- proxy_next_upstream error timeout http_500 http_502 http_503 http_504
- proxy_next_upstream_tries 2：最多尝试 2 次（含首次），避免卡死在慢节点
- proxy_next_upstream_timeout 5s：整个重试过程总耗时上限，防长尾
注意：这些指令需放在 location 块中，与 proxy_pass 同级生效。
跨源/跨协议容灾：用 error_page 实现更灵活 fallback
如果 backup 源站是不同域名、甚至不同协议（比如主源 HTTP，backup 是 HTTPS 或本地文件），就不能只靠 upstream 内部 backup，得用 error_page 跳转到独立 location：
- 在主 location 中设
error_page 502 503 504 = @origin_fallback; - 定义
location @origin_fallback { proxy_pass https://backup.example.com; } - 这种模式支持完全异构回源，也便于插入降级响应（如返回预置 JSON）、本地磁盘缓存等最终兜底手段
验证与可观测性：别只看配置，要看实际行为
上线前务必模拟主源中断，确认流量真实切换：
- 在 response header 中加
add_header X-Upstream $upstream_addr;，用 curl -v 直接看转发到了哪台 - access log 中加入
$upstream_addr $upstream_status字段，定位切换发生的时间点和状态码 - backup 节点建议开启
proxy_cache_lock on，防止缓存穿透风暴 - 定期对 backup 执行缓存预热（如 cron 调用 curl 请求关键 URL），避免首次访问冷加载超时
