backup节点仅在默认轮询模式下生效，需配合max_fails和fail_timeout将主节点标记为down后才启用，且upstream必须定义在http块内、proxy_pass名称须严格一致。
直接在 upstream 块里给某台后端加 backup 关键字，就能让它变成纯备用节点——平时完全不收流量，只在所有主节点都不可用时才顶上。这不是热备，也不做数据同步，但能快速兜底，避免服务中断。
backup 节点怎么写才生效
语法很简单，但有硬性前提：
- 必须放在
http块内，不能塞进server或location里 - 必须用默认轮询（round-robin）模式——如果 upstream 开了
ip_hash、least_conn等策略，backup会被直接忽略 - 至少得有一个没标
backup的 server，否则 Nginx 找不到可用主节点，直接返回 502 - IP 和端口要写全，比如
192.168.1.12:8080 backup，漏掉端口容易发到 80 上失败
为什么加了 backup 还不切换？关键在健康检查
backup 不是“一挂就切”，它依赖主节点被 Nginx 主动标记为 down。而默认情况下，Nginx 不会主动探测，得靠请求失败来触发判断。所以必须给每个主节点配：
-
max_fails=3：连续 3 次失败（连接超时、502/503/504、拒绝连接等）就标为不可用 -
fail_timeout=30s：标记后 30 秒内不再转发请求，之后自动重试恢复 - 这两个参数必须成对出现，单独写一个无效
backup 节点自己不用加这些——它本就不参与常规调度，也没必要做健康检查。
配置示例与常见陷阱
一个稳妥的写法：
upstream app_backend {
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.12:8080 backup;
}
注意避开这些坑：
-
server 192.168.1.12:8080 backup max_fails=3—— 报错，backup 不能和健康检查参数混用 -
upstream块写在server里 —— 启动失败，提示"upstream" directive is not allowed here -
proxy_pass http://App_Backend但 upstream 名叫app_backend—— 大小写不一致导致 502 - 所有 backup 节点部署在同一机房或同一物理机 —— 单点故障仍会导致整体失效
上线前怎么验证容灾是否真起作用
别只看配置，动手测才是关键：
- 停掉一台主服务（比如
systemctl stop myapp），反复 curl 接口，观察 access log 是否开始打到 backup 节点 IP - 查 error log，确认有没有类似
no live upstreams或upstream timed out的记录 - 用
$upstream_addr变量记录日志，方便区分请求到底落在哪台机器上 - 主节点恢复后，流量应自动切回，不需要 reload Nginx
