nginx中“状态备份”本质是配置backup节点与健康探测机制实现服务级容灾：backup节点默认不参与流量，仅当所有非backup节点被max_fails/fail_timeout标记为不可用时才启用，且仅在round-robin模式下生效。
明确 backup 节点的作用与限制
backup 参数标记的服务器默认完全不参与流量分发，只作为兜底选项：
- 所有非 backup 的 server 都被 Nginx 判定为不可用（如连续失败、超时、连接拒绝等）后，才会把请求转给 backup 节点
- backup 节点不能单独存在——upstream 中至少要有一个非 backup 节点，否则会返回 502 Bad Gateway
- 该参数只在默认的 轮询（round-robin）模式下生效；若用了
ip_hash、least_conn等策略，backup 将被忽略
配置带健康检查的主备 upstream
单纯加 backup 不够，必须配合 max_fails 和 fail_timeout 才能准确识别故障：
-
max_fails=3：某个节点连续 3 次请求失败（含超时、502/503/504、连接拒绝），就标记为不可用 -
fail_timeout=30s：被标记后，30 秒内不再向它转发新请求；超时后自动重试，恢复可用性判断 - HTTP 层错误（如 500、503）默认不触发重试，需在 location 中显式启用：
proxy_next_upstream error timeout http_502 http_503 http_504
示例配置：
upstream app_backend {
server 192.168.1.10:8000 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8000 max_fails=3 fail_timeout=30s;
server 192.168.1.12:8000 backup;
}
代理层需配套收紧超时与重试逻辑
避免用户卡在失效节点上，应在 location 块中设置合理超时：
-
proxy_connect_timeout 3s：建立 TCP 连接不能超过 3 秒 -
proxy_send_timeout 5s：发送请求体超时 -
proxy_read_timeout 10s：等待后端响应头的时间（不是整个响应体） -
proxy_http_version 1.1和proxy_set_header Connection ''：启用 keepalive 复用连接，减少建连失败误判
验证 backup 是否真正生效
上线前务必实测切换行为：
- 手动停掉一台主服务（如
systemctl stop app-server），持续发起请求，观察是否仍能返回正常响应 - 检查 Nginx 错误日志：
/var/log/nginx/error.log，应出现类似no live upstreams while connecting to upstream的提示，紧接着看到请求打到 backup 地址 - 通过日志变量
$upstream_addr记录实际转发目标，便于监控 backup 流量占比
