backup 是故障兜底路由开关，仅在所有非 backup 节点被被动健康检查标记为 down 后才启用；其切换与恢复全自动，依赖 max_fails 和 fail_timeout 配置，无容错参数则形同虚设。
backup 参数不是“自动热备”，而是“故障兜底路由开关”——它本身不触发切换，只在 Nginx 判定所有非 backup 节点不可用后，才让该节点参与转发。真正决定“何时切”“切得准不准”的，是被动健康检查机制。
backup 本身不感知状态，靠失败标记驱动切换
加了 backup 的 server 默认被跳过，Nginx 完全不会向它发请求。它不会主动 ping、不会定时探活，也不会因为其他节点负载高而“帮忙分担”。只有当所有非 backup 节点都被 Nginx 标记为 down（即进入失效状态）时，backup 才会被纳入可用池。
- Nginx 标记 down 的唯一依据：某次请求失败（连接超时、拒绝、返回 502/503/504 等）且达到 max_fails 次数
- 标记为 down 后，在 fail_timeout 时间内不再尝试该节点
- backup 节点自己也建议配 max_fails（如
max_fails=2 fail_timeout=30s），避免它出问题后持续被轮询导致雪崩
必须显式配置容错参数，否则 backup 形同虚设
只写 server 192.168.1.12:8080 backup; 是无效的。若没给主节点设 max_fails 和 fail_timeout，Nginx 就永远不会把它们标为 down，backup 永远沉睡。
- 每个非 backup 的 server 行末尾都要加上容错参数，例如：
server 192.168.1.10:8080 max_fails=1 fail_timeout=10s; - 参数值要贴合实际：短超时（如 3–5s）+ 少次数（1–3 次）适合敏感服务；长超时（20–30s）+ 多次数（3–5）适合网络抖动多的环境
- Windows 下无主动健康检查（
health_check不可用），只能依赖这套被动机制，所以配置更需严谨
切换是自动的，恢复也是自动的，无需 reload
一旦主节点因故障被标记为 down，Nginx 在下一次请求调度时立即启用第一个可用的 backup 节点；当主节点在 fail_timeout 结束后重试成功，它会自动重新加入 upstream，流量随即切回——整个过程零人工干预。
- backup 节点可有多个，它们之间按默认轮询或权重调度（若设了
weight） - 主节点恢复后，backup 不会“抢占”流量，而是退回到待命状态
- 若所有节点（含 backup）都不可达，Nginx 直接返回 502 或 503，不会循环重试
灾备不是万能的，要配合降级兜底才完整
backup 解决的是“服务级不可用”的接管，但无法应对接口级异常（比如 /order 接口报 500，但服务进程还在）。这时需要 proxy_next_upstream + error_page 做细粒度兜底：
-
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;让 Nginx 在这些错误时尝试下一个 upstream 节点（包括 backup） -
proxy_next_upstream_tries 2;控制最多重试 2 次（含首次请求） - 用
error_page 502 503 504 = @fallback;定义本地降级响应，比如返回预设 JSON 或静态页面
