Nginx通过upstream模块的backup节点与健康探测机制实现服务级容灾：backup节点仅在非backup节点全部失效时启用，配合max_fails、fail_timeout和proxy_next_upstream等参数实现自动故障转移与重试。
启用 backup 服务器节点
在 upstream 块中，给备用服务器添加 backup 参数，它仅在所有非 backup 服务器都失效时才参与负载分发：
- 非 backup 服务器全部宕机或标记为不可用后，Nginx 才会把请求转给 backup 节点
- backup 节点默认不参与轮询、权重或 least_conn 等常规调度
- 示例配置：
upstream app_servers {
server 192.168.1.10:8000;
server 192.168.1.11:8000;
server 192.168.1.12:8000 backup;
}
配置健康探测与自动摘除
Nginx 不主动 ping 或 HTTP 探活，而是通过请求失败行为动态判断节点状态。需配合以下参数使用：
- max_fails=3：连续失败 3 次后标记该节点为不可用
- fail_timeout=30s：30 秒内不向该节点转发新请求（超时后自动重试）
- proxy_next_upstream error timeout http_502 http_503 http_504：在 location 中启用，允许将这些错误响应视为失败并尝试下一节点
- 注意：仅
connect refused和timeout默认计入失败；HTTP 错误需显式声明才能触发重试
设置合理的超时与重试策略
避免用户长时间等待失败节点，应在 proxy 相关指令中收紧时间窗口：
- proxy_connect_timeout 3s：建立连接超时，防止卡在 TCP 握手
- proxy_send_timeout 5s：发送请求体超时
- proxy_read_timeout 10s：等待后端响应头超时（不是整个响应）
- 搭配
proxy_next_upstream_tries 3可限制最多尝试 3 个节点（含重试）
验证与观察机制
上线前必须验证容错是否生效：
- 手动停掉一台主 server，观察 access log 是否开始打到 backup 节点
- 检查 Nginx error log，确认有类似
upstream server temporarily disabled的记录 - 用
curl -I http://your-domain/测试响应状态码是否始终为 200（而非 502） - 注意：backup 节点也需能独立承载全量流量，否则切换后仍可能雪崩
