nginx边缘缓存通过backup节点实现自动故障转移，主节点异常时切至backup，恢复后自动回切；需配合proxy_next_upstream等配置，并区分强/弱一致性场景处理数据。
当主 CDN 回源节点不可用时，Nginx 边缘缓存可通过配置 backup 节点实现自动故障转移，保障用户请求不中断、缓存仍可服务。
Backup 节点的核心作用
Backup 节点不是“备用加载”，而是 Nginx upstream 中明确标记为 仅在其他 server 不可用时才启用 的后端。它不参与常规负载均衡，也不接收健康检查流量（除非主节点全部失效），因此天然适合做容灾兜底。
- 主节点正常时，所有请求由主 origin 处理，backup 完全静默
- 主节点超时、连接拒绝或返回 5xx（需配合
proxy_next_upstream）时，Nginx 自动切到 backup - 主节点恢复后，流量立即切回，无需人工干预
关键配置项与避坑要点
仅加 backup 参数不够，必须协同设置健康探测与重试策略：
-
upstream origin_cluster {
server 192.168.1.10:80;
server 192.168.1.11:80 backup;} -
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;—— 触发切换的条件 -
proxy_next_upstream_tries 2;—— 最多重试 2 次（含首次），避免长尾 -
proxy_next_upstream_timeout 3s;—— 总重试耗时上限，防卡死 - 慎用
max_fails/fail_timeout：若主节点短暂抖动，可能被误判下线；建议优先依赖proxy_next_upstream实时决策
Backup 节点的数据一致性处理
Backup 通常不是实时镜像源，缓存内容可能滞后。需针对性设计降级逻辑：
- 对强一致性接口（如登录态、支付回调），应在应用层返回
503 Service Unavailable，而非走 backup 缓存 - 对静态资源、图文详情等弱一致性内容，允许使用 backup 返回的 stale 缓存（配合
proxy_cache_use_stale） - 可在 backup server 上启用
proxy_cache_lock on，避免缓存穿透风暴
验证与可观测性建议
上线前必须模拟故障并观测行为：
- 用
curl -v查看响应头中的X-Upstream（自定义 header）确认实际转发目标 - 在 access log 中添加
$upstream_addr和$upstream_status字段，定位切换时机 - 定期对 backup 节点执行缓存预热（如定时 fetch 关键 URL），避免首次访问冷加载超时
不复杂但容易忽略：backup 不是万能兜底，它解决的是“回源链路可用性”，而非“数据新鲜度”或“业务逻辑正确性”。合理划分容灾边界，才能让边缘缓存真正稳得住。
