dns负责全局灾备切换（分钟级），nginx负责集群内快速容错（毫秒至秒级）；二者分层协同，dns指向各机房nginx入口vip，nginx通过upstream+proxy_next_upstream实现后端节点级故障转移。
Nginx 本身不处理 DNS 故障转移，它只做反向代理和负载均衡；DNS 层的故障转移需由 DNS 服务商或自建 DNS 服务实现，而 Nginx 后端的容错是另一层保障。两者结合才能构成“DNS + Nginx”双保险架构：DNS 负责大范围流量调度与灾备切换，Nginx 负责单集群内节点级快速恢复。
DNS 层故障转移配置要点
DNS 故障转移不是在 Nginx 配置里写的，而是通过 DNS 解析策略实现：
- 使用支持健康检查的 DNS 服务（如阿里云云解析、腾讯云 DNSPod、AWS Route 53），为同一域名配置多个 A/AAAA 记录，并开启“主动探测 + 自动剔除”功能
- 设置低 TTL（如 60 秒），确保故障发生后客户端能较快刷新解析结果
- 按地域或机房划分记录组，例如：
sh.example.com → 10.0.1.10（上海）TTL=60
bj.example.com → 10.0.2.10（北京）TTL=60
fallback.example.com → 10.0.3.10（深圳灾备）TTL=300 - 用 CNAME 或智能解析规则将主域名（example.com）指向 sh.example.com，当上海 DNS 探测失败时，自动降级到 bj.example.com，再失败则切 fallback
Nginx 后端层故障转移配置
这是真正落地的容错核心，靠 upstream + proxy_next_upstream 协同完成：
- 在 http 块中定义带容错能力的 upstream，例如：
upstream sh_cluster {
server 10.0.1.11:8080 weight=3 max_fails=3 fail_timeout=30s;
server 10.0.1.12:8080 weight=2 max_fails=3 fail_timeout=30s;
server 10.0.1.13:8080 backup;
}
- 在 location 中启用请求级重试：
location /api/ {
proxy_pass http://sh_cluster;
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
proxy_next_upstream_tries 3;
proxy_next_upstream_timeout 10s;
}
- 注意：backup 节点也建议加 max_fails/fail_timeout，避免它自己出问题还持续被兜底
双保险如何协同生效
两层机制作用范围不同，但形成互补：
- DNS 层响应慢（分钟级），适合应对整个机房断网、IDC 整体宕机等大范围故障
- Nginx 层响应快（毫秒~秒级），适合应对单台后端崩溃、瞬时超载、进程卡死等局部异常
- 用户首次访问走 DNS 解析，命中上海集群；若上海 Nginx 实例自身健康但其后端全挂，Nginx 会用 backup 或重试兜住；若上海 Nginx 进程崩溃或网络中断，DNS 探测失败后 1–2 分钟内将新用户导流至北京
- 关键：DNS 不应直接指向后端服务器 IP，而应指向各机房的 Nginx 入口 VIP，把入口网关角色留给 Nginx
生产环境增强建议
让双保险更可靠，还需补充几点：
- 每个机房的 Nginx 入口前部署 Keepalived，提供本机房内的虚拟 IP 高可用，防止单 Nginx 实例宕机
- 在 Nginx 上配置 error_page 502 503 504 = @fallback，内部跳转到跨机房 upstream（如 http://bj_cluster），实现“本地兜不住→就近兜底”
- 用 Prometheus + nginx-vts-exporter 监控 upstream 状态，fail_count、down 时间、backup 激活次数都纳入告警项
- 定期模拟 DNS 切换与后端节点下线，验证全流程是否自动、无感、可回溯
