backup 参数仅在轮询模式下生效，需配合max_fails、fail_timeout及proxy_next_upstream等健康检查配置才能触发冷备切换，否则无效。
backup 参数用于在 Nginx 轮询模式下定义冷备节点——它完全不参与日常流量分发，只在所有主节点被判定为不可用时才启用，实现服务级自动降级。关键不是加个 backup 就能容灾，而是必须配合健康检查逻辑才能触发切换。
backup 节点的基本写法与生效前提
它只在默认的 round-robin（轮询）调度中起作用，其他策略如 ip_hash、least_conn 下无效。配置时直接在 upstream 的 server 行末尾加上 backup 即可：
- 非 backup 节点全部标记为 down 后，Nginx 才会把请求转给 backup 节点
- backup 节点本身默认不建立连接、不接收探测、不参与任何负载计算
- 如果 upstream 中所有 server 都带 backup 标记，Nginx 将无可用节点，返回 502 错误
必须搭配 max_fails 和 fail_timeout 才能真正“感知故障”
Nginx 不主动探活，而是靠请求失败行为被动判断节点状态。仅写 server 192.168.1.12:8000 backup; 是无效的，必须为每个主节点显式配置失败阈值：
- max_fails=3：连续 3 次请求失败（如超时、拒绝、或指定 HTTP 状态码）后标记该节点为 down
- fail_timeout=30s：节点被标记为 down 后，30 秒内不再转发新请求，之后自动重试
- backup 节点自己也建议配 max_fails（如
max_fails=2 fail_timeout=30s），防止它出问题后成为新的单点
让 HTTP 层错误也能触发切换
默认情况下，只有连接失败（connect refused、timeout）会被计入失败次数。若后端返回 502/503/504，需在 location 块中显式启用：
- proxy_next_upstream error timeout http_502 http_503 http_504：遇到这些响应就尝试下一个节点
- 注意：
http_500不在默认重试范围内，如需支持，要手动加上 - 搭配 proxy_connect_timeout 3s; proxy_read_timeout 10s; 缩短等待时间，避免卡住
验证是否真正生效的实操要点
上线前务必做真实故障模拟：
- 手动停掉一台主服务器，观察 access log 是否开始出现 backup 节点的 IP 地址
- 检查 error log，确认有类似
upstream timed out (110: Connection timed out)或no live upstreams while connecting to upstream的记录 - 恢复主节点后，流量应自动切回，backup 节点退回到静默状态，无需 reload nginx
