Nginx 多 backup 节点需构建分层兜底能力：主节点全 down 后按配置顺序启用 backup，须满足 upstream 在 http 块、轮询模式、主节点配 max_fails/fail_timeout 及 proxy_next_upstream 重试等前提，否则静默失效。
在 Nginx 中配置多个 backup 节点，不是简单堆数量，而是构建分层兜底能力：主节点故障时先由高权重备用承接，全失效后再启用冷备；需严格满足 upstream 作用域、轮询模式、健康检查联动等前提，否则 backup 会静默失效。
多个 backup 节点的写法与角色区分
可在同一 upstream 块中定义多个带 backup 标识的 server，Nginx 会按顺序尝试（从上到下），但全部仅在非 backup 节点均被标记为 down 后才参与调度：
- 第一个 backup 节点可设为“热备中心”，如广州集群：
server 192.168.10.20:8080 backup; - 第二个 backup 可设为“灾备中心”或独立资源池：
server 10.0.5.100:8080 backup; - 不支持权重（weight）或 max_fails 等参数作用于 backup 节点本身——它不参与常规负载，也无需主动健康检查
- 所有 backup 节点默认按配置顺序启用，无自动优先级切换逻辑；若需控制启用次序，靠配置位置决定
必须配套的健康检查机制
backup 不是“一挂就切”，依赖主节点被准确标记为 down。关键靠被动健康检查触发：
- 每个非 backup 的 server 必须显式配置
max_fails=1 fail_timeout=8s（高压场景）或max_fails=3 fail_timeout=30s（常规场景） - 这些参数必须成对出现，缺一不可；单独写 max_fails 不生效
- backup 节点自身不加 max_fails —— 它本就不收正常流量，无需摘除逻辑
- 确保 upstream 定义在
http{}块内，不在 server 或 location 中；否则语法合法但 backup 不生效
请求失败后的真实 fallback 行为
仅靠 backup 不足以应对响应异常，需配合 proxy_next_upstream 主动重试：
- 在 location 中启用：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504; - 限制重试次数和总耗时：
proxy_next_upstream_tries 2;（首次 + 一次 fallback）、proxy_next_upstream_timeout 4s; - 注意：POST/PUT 等非幂等方法默认不重试，即使配了 proxy_next_upstream —— 这是 Nginx 内置安全策略
- 当所有非 backup 节点都被标记为 down，且当前请求已触发重试条件，Nginx 才会将请求转给第一个可用的 backup 节点
验证与常见失效原因
配置完务必实测，重点观察日志和行为是否符合预期：
- 停掉全部主节点（systemctl stop app-server），用 curl 持续访问，确认仍能返回响应
- 查看
/var/log/nginx/error.log：应出现类似no live upstreams while connecting to upstream的提示，紧接着恢复正常，表明 backup 已接管 - 常见失效原因：upstream 放在 location 里、用了 ip_hash/least_conn 等非轮询策略、主节点没配 max_fails/fail_timeout、proxy_pass 写成 http://backend/（末尾斜杠引发路径重写）
- backup 节点 IP 和端口必须写全，例如
192.168.1.100:8080 backup，漏端口会默认发往 80，大概率失败
