backup是故障兜底路由开关，仅在所有非backup节点被标记为down后才参与转发，需配合round-robin、健康检查及proxy_next_upstream等机制使用。

backup 参数不是热备开关，而是故障兜底路由开关——它只在所有非 backup 节点被 Nginx 主动或被动标记为 down 后才参与转发，本身不抢流、不分担压力、也不主动探活。

明确 backup 的生效前提

backup 仅在 upstream 使用默认的 round-robin 轮询模式 下有效；若配置了 ip_hash、least_conn 等策略，backup 将被忽略。同时，upstream 中至少需有一个非 backup 节点，否则全部节点失效，请求直接返回 502。

• 所有主节点必须配置健康检查参数（max_fails 和 fail_timeout），否则 Nginx 无法识别“不可用”，backup 永远不会启用
• backup 节点自身也必须带 max_fails 和 fail_timeout，防止它出问题后持续被选中，变成新故障点
• 不要把多个节点都标为 backup：那样等于没有主节点，整个 upstream 失效

配置示例与关键细节

以下是一个生产可用的 upstream 配置片段：

upstream api_backend {
    server 192.168.10.10:8080 max_fails=1 fail_timeout=8s;
    server 192.168.10.11:8080 max_fails=1 fail_timeout=8s;
    server 192.168.20.5:8080 backup max_fails=1 fail_timeout=8s;
}

• max_fails=1 表示一次超时或 5xx 就立即标记为 down，适合高压或抖动场景
• fail_timeout=8s 指该节点被标记为 down 后，8 秒内不再尝试，避免反复试探加重负担
• backup 节点地址建议跨机房、跨云厂商，甚至采用不同技术栈（如 Go 编写的极简服务），避免共性故障

增强 fallback 可靠性的必要补充

仅靠 backup 不足以应对真实故障场景，必须叠加三层机制：

• proxy_next_upstream：必须包含 timeout 和 http_504，否则网关超时不会触发重试和切换
• proxy_next_upstream_tries：设为 2（含首次请求），防止重试风暴拖垮 backup
• error_page 降级：当 backup 也失败时，用 error_page 拦截 502/503/504，返回静态 JSON 或跳转至降级页，毫秒级响应

backup 节点自身的抗压设计

它长期空闲，首次承接流量易冷加载超时或被打满：

• 启用 proxy_cache_lock on，避免缓存穿透打穿 backup
• 若 backup 提供只读能力（如查单号+返回状态），应剥离写逻辑、禁用数据库连接池、用 SQLite 或内存 DB 支撑
• 建议对 backup 接口做独立压测，并预热关键路径（如提前访问健康检查接口）