Nginx集群不直接实现跨机房高可用，需分层协同：机房内靠Keepalived+VIP主备或双活，跨机房依赖GSLB或Anycast等上层调度，Nginx仅作为本地流量入口与健康转发节点。
Nginx 集群本身不直接实现跨机房高可用，它需要分层协同：机房内靠 Keepalived + VIP 做主备或双活，跨机房则依赖上层全局调度（如 GSLB 或 Anycast），Nginx 仅作为各机房的本地流量入口与健康转发节点。
机房内 Nginx 高可用：Keepalived 管理虚拟 IP
每台 Nginx 服务器都部署 Keepalived，通过 VRRP 协议共享一个对外统一的虚拟 IP（VIP）。主节点正常时持有 VIP；一旦心跳检测失败（如 Nginx 进程退出、端口不可达），备用节点立即接管 VIP，用户无感切换。
- 两台及以上 Nginx 实例需部署在同一局域网（或同 VPC 内网），确保 VRRP 报文可达
- 配置
vrrp_script脚本主动检查 Nginx 进程和端口状态，避免“脑裂” - 优先使用
interface指定物理网卡（如 ens33），禁用vrrp_strict以兼容云环境
跨机房流量调度：Nginx 不决策，只执行
Nginx 集群不感知其他机房的健康状态，也不做跨城路由决策。真正实现“跨机房高可用”的是其上游系统：
- 云厂商 GSLB（如阿里云云解析 DNS、AWS Route 53）基于探测结果动态调整域名解析，将用户导向健康机房
- 若使用 Anycast，需确保各机房 Nginx 后端真实服务 IP 可达，且 BGP 路由收敛稳定，避免黑洞或回环
- DNS TTL 建议设为 30–60 秒，保障故障后分钟级生效
机房内负载与健康转发：upstream + proxy_next_upstream
每个机房的 Nginx 集群负责把请求分发给本机房多个应用实例（如 Next.js、Java 微服务），需保障局部容错：
- 定义
upstream时启用max_fails=2 fail_timeout=30s，自动摘除异常节点 - 搭配
proxy_next_upstream error timeout http_500 http_502 http_503 http_504，支持失败重试 - 静态资源（如
/_next/、/favicon.ico）由 Nginx 直接alias提供，减轻后端压力
关键协同点：Nginx 是执行者，不是决策者
真正的异地多活高可用，依赖三要素齐备：
- 无状态服务：后端应用不依赖本地会话，所有状态外置（如 Redis、DB）
- 数据最终一致性：跨机房数据库/缓存采用异步复制，容忍短时延迟
-
全局可观测性：Nginx 日志中记录
X-Data-Region、X-Upstream等头，用于链路追踪与故障归因
