nginx upstream 的 backup 服务器仅在所有非 backup 节点全部失效时被动启用，用于降级兜底而非主动切换；需配合短超时、健康检查、proxy_next_upstream 优化等配置才能接近秒级故障转移，且不自动回切。
使用 Nginx upstream 的 backup 标记，可以实现主备数据中心的简单、低延迟切换，但需注意：它本身不主动探测后端健康状态，切换依赖于 Nginx 对失败请求的自动摘除机制，因此“秒级”切换需配合合理配置才能达成。
backup 的真实作用不是“备用”，而是“降级兜底”
backup 服务器在 upstream 中默认不参与负载，仅当所有非 backup 服务器全部失效（连接超时、502/503/504 等）时，Nginx 才将请求转发给它。它不是主动切换开关，而是一种被动容灾策略。
- 非 backup 服务器只要有一个可用，backup 就永不启用
- backup 不会因主站“慢”而提前接管，只响应“不可达”或“明确拒绝”
- 若主站返回 200 但业务已异常（如 DB 连接池耗尽），backup 不会触发 —— 这是常见误判点
让 backup 切换真正接近“秒级”的关键配置
默认情况下，Nginx 对后端失败的判定较保守（如需连续多次失败才摘除），需显式优化以下参数：
-
设置短超时：
proxy_connect_timeout 1s;、proxy_read_timeout 2s;、proxy_send_timeout 1s; -
开启主动健康检查（推荐用商业版或 OpenResty），或用免费方案：
health_check interval=3 fails=1 passes=1;（需 Nginx Plus 或 1.19+ 的开源版支持） -
关闭缓存失败连接：
proxy_next_upstream error timeout http_502 http_503 http_504;并设proxy_next_upstream_tries 1;避免重试放大延迟 - 启用 keepalive 并复用连接，减少建连开销，加快故障感知速度
典型主备 upstream 配置示例
以下是一个兼顾快速感知与平滑回切的 upstream 声明：
upstream app_cluster {
# 主中心（北京）
server 10.1.1.10:8080 max_fails=1 fail_timeout=3s;
server 10.1.1.11:8080 max_fails=1 fail_timeout=3s;
<pre class="brush:php;toolbar:false;"># 备中心（上海），仅当主全挂时启用
server 10.2.2.10:8080 backup max_fails=1 fail_timeout=3s;
server 10.2.2.11:8080 backup max_fails=1 fail_timeout=3s;}
说明：
– max_fails=1 表示 1 次失败即标记为不可用
– fail_timeout=3s 表示 3 秒内不向该节点发新请求，3 秒后自动重试恢复
– 两个 backup 节点之间仍会轮询，提升备用中心自身可用性
回切不是自动的，需要小心设计
Nginx 不会“自动回主”——一旦 backup 开始服务，只要它一直健康，即使主中心恢复，流量仍会持续打过去，直到主节点被重新纳入可用列表（即 fail_timeout 过期后下一次请求试探成功）。
- 若希望主中心恢复后尽快接管，可调小
fail_timeout（如 2~5 秒），但过小易引发抖动 - 更稳妥的方式是结合外部监控 + reload 配置（如检测到主中心全量恢复后，移除 backup 标记并
nginx -s reload） - 生产中建议搭配 DNS 或服务网格做全局流量调度，Nginx backup 仅作最后一道本地兜底
