backup参数使Nginx upstream中指定服务器仅在非backup节点全部失败时启用，实现故障自动切换；需配合max_fails和fail_timeout被动健康检查才生效，且Windows下不支持主动健康检查。
在 Windows 下配置 Nginx 的 upstream 时启用 backup 参数，可以让某台服务器仅在其他非 backup 节点全部不可用时才参与请求转发，实现故障自动切换的简单高可用。
backup 参数的作用和基本写法
backup 是 Nginx upstream 模块中一个服务器标记，它本身不改变负载均衡算法（如 round-robin、ip_hash），但会让该 server 默认不接收任何请求——除非所有非 backup 的 server 都处于失败状态（比如超时、连接拒绝、返回 502/503/504 等）。
示例配置：
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080 backup;
}
其中 192.168.1.12 就是备用服务器，正常情况下不会被选中。
必须配合健康检查机制才真正有效
仅加 backup 不够。Nginx 默认不会主动探测后端是否宕机，而是依赖「请求失败」来标记 server 为不可用（即 fail_timeout 和 max_fails 控制的被动健康检查）。所以要让 backup 生效，需显式配置容错参数：
- max_fails=1：连续失败 1 次就标记为不可用
- fail_timeout=10s：10 秒内不向该 server 发起新请求
- 注意：这些参数要加在每个非 backup 的 server 行末尾，backup server 可不加（或设为较大值）
完整示例：
upstream backend {
server 192.168.1.10:8080 max_fails=1 fail_timeout=10s;
server 192.168.1.11:8080 max_fails=1 fail_timeout=10s;
server 192.168.1.12:8080 backup;
}
Windows 下验证与调试要点
在 Windows 环境下使用时，注意以下几点：
- Nginx for Windows 本身不支持
health_check指令（仅限商业版 NGINX Plus），所以只能依赖被动检查 - 可通过
curl -v http://localhost/或浏览器反复刷新，再手动停掉主服务（如关闭 Python Flask/Java Spring Boot 进程），观察是否自动切到 backup - 查看
logs/error.log，搜索no live upstreams或upstream timed out，确认切换逻辑是否触发 - backup server 也建议加上
max_fails，避免它自己出问题却持续被轮询
常见误区提醒
容易误以为 backup 是“热备”或“实时同步”，其实它只是“冷备路由”。需注意：
- backup 不承担日常流量，无连接预热、会话同步等能力，首次请求可能有延迟
- 如果所有 server（含 backup）都不可达，Nginx 会返回 502 或 503，不会无限重试
- backup 不能嵌套（即 backup server 上不能再设 backup）
- weight 和 backup 可共存，但 weight 对 backup 无效
