backup是服务级故障兜底机制，仅在所有非backup主节点被健康检查标记为不可用时启用，需配合max_fails、fail_timeout和proxy_next_upstream等参数才生效，且仅适用于round-robin模式。
Linux 下用 Nginx 配置 backup 备用节点，本质是做**服务级故障兜底**，不是热备也不是负载分担。它只在所有主节点都不可用时才启用，切换过程对客户端透明，但前提是健康检查机制必须配到位——否则 backup 永远不会被触发。
backup 节点怎么写才生效
在 upstream 块中添加 backup 关键字即可，但要注意几个硬性前提：
- 必须使用默认的轮询（round-robin）调度方式，
ip_hash、least_conn等策略下backup无效 - 不能所有 server 都标了
backup，否则 upstream 无可用节点，直接返回 502 -
backup节点不参与任何常规调度，也不继承主节点的weight、max_fails等参数（除非显式写出）
示例配置：
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;
}
没健康检查，backup 就是摆设
Nginx 默认只靠 TCP 连接失败判断节点状态。如果后端进程还在但 HTTP 返回 503 或响应超时，Nginx 不会自动摘除——backup 也就永远不会启用。
必须配合以下参数才能让故障识别真正可靠：
-
max_fails=3：连续 3 次请求失败（含超时、5xx、连接拒绝）即标记为 down -
fail_timeout=30s：被标记后暂停 30 秒，之后自动重试恢复 -
proxy_next_upstream error timeout http_502 http_503 http_504：在location块里启用，让这些错误成为重试依据
注意：proxy_next_upstream 必须和 max_fails 配合，单加一个没用。
让切换更稳的实操细节
光有 backup 和健康检查还不够，实际部署中容易卡在这些环节：
- backup 节点自身要能独立承载全量流量——数据同步、证书有效、配置一致，否则切过去照样 502
- 建议在
upstream中加keepalive 32，并在location里配proxy_http_version 1.1和proxy_set_header Connection ''，避免短连接频繁建连干扰健康判断 - 测试时别只停服务，还要模拟网络不通、防火墙拦截等场景，确认 error.log 是否出现
no live upstreams或using backup日志 - 不要把 backup 和主节点部署在同一台物理机或同一可用区，否则单点故障仍会导致整体失效
backup 不是高可用的全部
它只解决“后端服务挂了怎么兜底”，不解决“Nginx 自己挂了怎么办”。如果需要整条链路高可用，得叠加 Keepalived 做 Nginx 主备，用 VIP 实现负载均衡器层的故障转移。backup 是后端容灾，Keepalived 是前端容灾，两者互补，不是替代关系。
