Nginx故障转移核心是upstream块定义容错后端组并配合proxy_next_upstream控制重试；需配置max_fails、fail_timeout、backup等参数，启用proxy_next_upstream error timeout http_500-504、tries和timeout，并建议添加主动健康检查及Keepalived实现Nginx自身高可用。
在 Nginx 中配置故障转移策略，核心不是改 proxy_pass 的写法，而是通过 upstream 块定义容错后端组，并配合 proxy_next_upstream 显式控制重试逻辑。企业级场景下，需同时兼顾被动容错的可靠性与主动探测的及时性。
用 upstream 定义带健康状态管理的后端组
所有故障转移能力都源于 upstream 块的配置。每个 server 行可设置以下关键参数：
- max_fails=3 fail_timeout=30s：某节点连续 3 次失败（连接拒绝、超时或指定 HTTP 错误），即被标记为不可用，30 秒内不再分发请求
- backup：该节点默认不参与负载，仅当所有非 backup 节点均不可用时启用，适合灾备或维护分流
- weight=2（可选）：显式设置权重，便于灰度切换或性能差异大的节点流量调控
示例：
upstream api_backend {server 10.0.1.10:8000 max_fails=3 fail_timeout=30s weight=3;
server 10.0.1.11:8000 max_fails=3 fail_timeout=30s weight=3;
server 10.0.1.12:8000 backup max_fails=2 fail_timeout=20s;
}
启用请求级自动重试（proxy_next_upstream）
仅剔除节点不够——当前请求仍可能失败。必须在 location 块中开启重试机制：
- proxy_next_upstream error timeout http_500 http_502 http_503 http_504：明确告诉 Nginx，遇到连接失败、超时或这些网关错误时换节点重试
- proxy_next_upstream_tries 3：最多尝试 3 台不同后端（含首次），防止无限循环
- proxy_next_upstream_timeout 10s：整个重试过程总耗时上限，避免用户长时间等待
该配置必须与 proxy_pass 同级，且仅对当前 location 生效：
proxy_pass http://api_backend;
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
proxy_next_upstream_tries 3;
proxy_next_upstream_timeout 10s;
}
补充主动健康检查（生产环境强烈建议）
被动检查依赖真实失败请求，存在滞后性。企业级系统应引入主动探测：
- 开源版需编译安装
nginx_upstream_check_module，并在 upstream 中添加：
check interval=3 rise=2 fall=5 timeout=1 type=http;
表示每 3 秒发一次 HTTP 探测，连续 2 次成功则上线，连续 5 次失败则下线 - Nginx Plus 用户可直接使用内置
health_check指令，支持更丰富的探测方式和监控指标
高可用不止于后端：Nginx 实例自身也要防单点
后端服务再稳，若 Nginx 自身宕机，一切归零。企业架构中需叠加一层 VIP + Keepalived：
- 部署至少两台 Nginx 服务器，配置完全一致
- 通过 Keepalived 绑定一个虚拟 IP（VIP），主节点持有 VIP 并响应流量；主节点故障时，备节点秒级接管 VIP
- Keepalived 自带心跳检测，可结合脚本检查 Nginx 进程存活、端口连通性甚至 upstream 状态
