backup 是故障兜底路由开关而非热备，仅在所有非 backup 节点被主动标记为不可用后才参与转发，需满足默认轮询、主节点配健康检查、backup 非唯一可用节点三条件。
backup 参数不是热备开关，而是故障兜底路由开关——它只在所有非 backup 节点被 Nginx 主动标记为不可用后才参与转发，本身不抢流、不分担压力、也不主动探活。要让它真正起作用，必须满足三个硬性条件：使用默认轮询模式、主节点配健康检查、backup 节点不能是唯一可用节点。
主备角色必须清晰区分
在 upstream 块中，只有明确标出 backup 的 server 才算备用节点，其余默认为主节点：
- 非 backup 节点正常接收全部流量，参与轮询调度
- backup 节点完全跳过，Nginx 不会向它发任何请求
- 若 upstream 中所有 server 都加了 backup，Nginx 将找不到可用后端，直接返回 502
- 多个 backup 节点之间按轮询或权重（如果设了 weight）分配流量，但前提是所有主节点都已失效
健康检查是 backup 生效的前提
仅写 server 192.168.1.12:8080 backup; 是无效的。Nginx 判定节点“不可用”的唯一依据是请求失败行为，必须配合被动健康检查参数：
- max_fails=1：一次超时或 5xx 就立即标记为 down，适合高压或抖动场景
- fail_timeout=8s：标记后暂停 8 秒再重试，避免反复试探加重负担
- 这些参数要加在每个非 backup 的 server 行末尾，例如：
server 192.168.1.10:8080 max_fails=1 fail_timeout=8s; - backup 节点自身也建议配置 max_fails 和 fail_timeout，防止它出问题后持续被选中
location 中需启用重试与降级逻辑
backup 解决的是服务级容灾，但单靠它无法应对接口级异常（比如某接口返回 500，进程却还在）。需在 location 块中叠加两层机制：
- proxy_next_upstream 必须包含 timeout 和 http_504，否则网关超时不会触发切换
- proxy_next_upstream_tries 2：限制最多尝试 2 次（首次主节点 + 1 次 fallback），防重试风暴
- error_page 502 503 504 = @fallback：当 backup 也失败时，可返回静态页、缓存响应或跳转降级页
backup 节点自身要能扛住突发流量
它长期空闲，首次承接高并发易冷加载超时或被打满：
- 启用 proxy_cache_lock on，避免缓存穿透打穿 backup
- 若提供只读能力（如查订单状态），应剥离写逻辑、禁用数据库连接池、用内存 DB 或 SQLite 支撑
- 上线前对 backup 接口做压测，并预热关键路径（如提前访问健康检查接口）
- 地址建议跨机房、跨云厂商，甚至采用不同技术栈（如 Go 编写的极简服务），避免共性故障
