backup 标记的服务器是冷备节点，仅在所有非 backup 服务器不可用时启用，不参与健康检查；语法为 server ip:port backup；不可与 max_fails 等参数混用；生效条件为全部主节点失效，恢复后自动切回。

在 Nginx 的 upstream 块中，用 backup 标记的服务器不会参与常规请求分发，只在其他所有非 backup 服务器全部不可用时才被启用。它不是“热备”，而是“冷备”——平时完全不接收流量，也不计入健康检查范围。

backup 参数的基本写法

语法很简单，直接在 server 指令后加上 backup 关键字即可：

upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080 backup;
}

这里前两台是主服务节点，最后一台是备用节点。只要前面任意一台正常，Nginx 就绝不会把请求发给 192.168.1.12。

backup 与其他状态参数共存的注意事项

backup 和 down、max_fails、fail_timeout 等不能混用在同一行——因为 backup 服务器本身不参与健康检查，设置失败重试逻辑没有意义。

• ✅ 正确写法：server 192.168.1.12:8080 backup;
• ❌ 错误写法：server 192.168.1.12:8080 backup max_fails=3;（Nginx 启动会报错）
• ⚠️ 不推荐：server 192.168.1.12:8080 backup weight=1;（weight 在 backup 下无效，会被忽略）

backup 何时真正生效

备用服务器只在以下条件同时满足时才开始接收请求：

• 所有非 backup 的 server 都被判定为不可用（比如连续失败达到 max_fails，且处于 fail_timeout 冷却期）
• 或者显式配置了 down，或网络完全不通导致探测失败
• Nginx 会持续尝试探测主服务器，一旦其中任一恢复正常，流量立刻切回，backup 自动停用

注意：backup 节点自身不接受健康检查，所以它的可用性完全依赖人工确认或外部监控介入。

实际部署建议

备份服务器更适合用于灾备场景，而非负载分担：

• 确保 backup 服务器资源充足，能临时承载全部流量
• 避免把 backup 和主服务器部署在同一物理机或同一机架，防止单点故障
• 可在 backup 服务器上加轻量级探活接口（如返回 200），配合外部脚本定期校验其就绪状态
• 如果希望多台 backup 按优先级启用，可按顺序排列，并搭配 weight（虽然 weight 对 backup 无效，但 Nginx 会按配置顺序依次启用）