backup参数用于nginx轮询上游中定义备用节点，仅当所有非backup节点不可用时启用；必须配合max_fails和fail_timeout等健康检查参数才真正生效，且仅在round-robin模式下有效。
在 Nginx 负载均衡中，backup 参数用于定义仅在主节点全部失效时才启用的备用服务器，是实现轻量级高可用的关键配置。它不参与常规流量分发，只作为兜底保障，无需额外组件即可快速降级。
backup 的基本用法
只需在 upstream 块内的 server 指令后添加 backup 关键字：
- 所有非 backup 节点必须至少有一个正常运行，backup 节点才不会被调度
- backup 节点不能单独存在——如果 upstream 中所有 server 都标了 backup，Nginx 将无法选择有效后端，返回 502 错误
- 该参数仅在默认的轮询（round-robin）模式下生效，与
ip_hash、least_conn等策略互斥
搭配健康检查提升可靠性
仅加 backup 不足以应对真实故障场景，Nginx 默认只靠 TCP 连接失败判断节点状态，对 HTTP 层错误（如 500、503）或业务超时无感知。建议配合被动健康检查参数：
-
max_fails=3：连续 3 次请求失败（含超时、5xx、连接拒绝等）即标记为不可用 -
fail_timeout=30s：被标记后暂停 30 秒，期间不再转发请求；超时后自动重试恢复 - 示例写法：
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
典型配置示例
一个兼顾可用性与可维护性的 upstream 配置如下：
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;
}
- 前两台为主服务节点，带基础探活机制
- 第三台为专用备份节点，IP 和端口可指向灾备环境或低配临时实例
- 注意：backup 节点本身也可加
max_fails和fail_timeout，但通常不必要——它本就不常被调用
注意事项与常见误区
实际部署中容易忽略几个关键点：
- backup 不等于“热备”——它不接收日常流量，也不做会话同步或数据复制，仅提供服务降级能力
- 若使用 HTTPS 后端，需确保 backup 节点证书有效，否则 TLS 握手失败也会触发 502
- 日志中可通过
$upstream_addr变量确认当前请求是否落到 backup 节点，便于监控和告警 - 不推荐将 backup 节点与主节点部署在同一物理机或同一可用区，否则单点故障仍会导致整体不可用
