Nginx 实现 Web 服务器集群故障转移依赖 upstream 被动健康检查（max_fails/fail_timeout）与 proxy_next_upstream 重试机制，可辅以第三方模块实现主动探测，并需配合监控与合理架构设计保障高可用。
在 Nginx 中实现 Web 服务器集群的故障转移，核心是利用 upstream 模块的健康检查机制与负载均衡策略，让流量自动绕过失效节点。Nginx 本身不内置主动健康探测（如 HTTP GET 探针），但可通过配置被动健康检查（基于请求失败状态）结合合理参数，达到实用级故障转移效果；若需更精准探测，可借助开源模块（如 nginx_upstream_check_module）或外部工具协同。
配置 upstream 实现基础故障转移
定义后端服务器组时，为每个节点设置 max_fails 和 fail_timeout，启用被动健康检查：
-
max_fails=3：连续 3 次请求失败（如超时、5xx、连接拒绝）即标记该节点为不可用 -
fail_timeout=30s：在此时间内被标记为不可用，30 秒后 Nginx 自动发起试探性请求恢复服务 - 搭配
weight和backup可进一步控制优先级与容灾节点
示例配置：
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.12:8080 backup; # 仅当其他节点全不可用时启用
}
启用主动健康检查（需编译扩展模块）
官方 Nginx 不支持 HTTP 级主动探活，但可通过第三方模块 nginx_upstream_check_module 实现：
- 编译时添加该模块，或使用已集成该功能的发行版（如 Tengine）
- 在 upstream 块中添加
check interval=3 rise=2 fall=5 timeout=1等指令 -
rise=2表示连续 2 次探测成功即恢复服务；fall=5表示连续 5 次失败才标记下线 - 支持 TCP、HTTP、SSL 多种探测方式，可指定 URI 和 expected status code
配合 proxy_next_upstream 提升容错能力
在 location 块中启用该指令，让 Nginx 在特定错误发生时自动重试其他节点：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;- 注意：默认不包含
http_500等状态码，必须显式声明才触发重试 - 避免对幂等性差的请求（如 POST）盲目重试，必要时配合
proxy_next_upstream_tries限制重试次数
监控与运维建议
故障转移是否生效，依赖可观测性支撑：
- 通过
stub_status或 Prometheus Exporter 暴露 upstream 状态（active/inactive、fails、health check result） - 定期检查 access log 中 upstream_addr 字段，确认请求是否实际落在备用节点
- 模拟节点宕机（如 iptables DROP 或 systemctl stop）验证 failover 延迟是否符合预期（通常 30s 内完成）
- 避免将所有后端部署在同一物理机或可用区，否则单点故障仍会导致整体不可用
