backup 参数本质是使节点完全退出常规负载分发队列，仅当所有非backup节点被标记为不可用时才启用；需配合max_fails、fail_timeout和proxy_next_upstream实现自动热备切换。
backup 参数的本质作用
backup 不是“备用服务器”的泛称，而是 Nginx upstream 模块中一个明确的调度标记。它让指定节点**完全退出常规负载分发队列**：无论权重多高、连接数多低、响应多快，只要该节点带 backup 参数，Nginx 就不会把它纳入轮询、ip_hash、least_conn 等任何默认调度逻辑中。它只在一种情况下被启用——所有非 backup 节点都被标记为不可用时。
热备切换依赖健康状态自动判定
Nginx 不主动探测后端是否存活，而是根据真实请求的失败行为动态更新节点状态。要让 backup 切换真正生效，必须配置以下三项：
- max_fails=3：某节点连续返回错误（如连接拒绝、超时）达 3 次，即被标记为 down
- fail_timeout=30s：该节点进入 down 状态后，30 秒内不接受新请求；超时后自动尝试恢复
- proxy_next_upstream error timeout http_502 http_503 http_504：在 location 块中启用，告诉 Nginx 遇到这些响应就视为失败，触发重试下一节点
典型配置示例与行为说明
以下配置中，192.168.1.12 是热备节点：
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;
}
server {
location / {
proxy_pass http://app_backend;
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 3;
proxy_connect_timeout 3s;
proxy_send_timeout 5s;
proxy_read_timeout 10s;
}
}
运行逻辑是：
- 正常时，请求只打向 .10 和 .11，.12 完全静默
- 若 .10 连续失败 3 次，30 秒内被跳过，流量全部转向 .11
- 若 .11 同时也失败（或本身已 down），Nginx 发现无可用非 backup 节点，立即启用 .12 接收全部请求
- 当 .10 或 .11 恢复（30 秒超时后首次请求成功），它们重新加入调度，.12 自动退回到 standby 状态
关键注意事项
热备不是“开了 backup 就万事大吉”：
- backup 节点必须能独立承载全量流量，否则切换后可能因压力过大引发级联失败
- proxy_read_timeout 设置过长会导致用户等待时间拉长，建议控制在 10 秒内
- 需配合 access_log 和 error_log 观察切换过程：停掉一台主节点后，应看到 log 中出现 upstream server temporarily disabled 记录，并确认请求开始命中 backup 地址
- 该机制仅解决后端服务故障转移，不解决 Nginx 自身单点问题；如需整机高可用，需叠加 Keepalived + VIP 方案
