Nginx健康检查需主动探测、分层响应、协同决策：配置独立健康端点与秒级探针，映射状态为动态变量驱动路由，实施节点→集群→全局三级降级，并与GSLB联动实现分钟级故障收敛。
在多数据中心容灾架构中，Nginx 的健康检查不能只做“连得上/连不上”的简单判断，而要成为智能流量调度的感知触角——它需主动探测、分层响应、协同决策，把健康状态实时转化为路由策略。
主动探针 + 独立路径：让检查不被业务干扰
被动检查（靠请求失败触发）延迟高、误判多，无法支撑跨机房容灾。必须启用主动健康检查，并确保探测路径与业务隔离：
- 为每个数据中心配置专属健康端点，例如 /health?dc=bj、/health?dc=sh，避免因 /api/status 响应慢或超时导致整组节点被误摘
- 使用 nginx_upstream_check_module（开源版）或 Nginx Plus 的 health_check 指令，设置 interval=5s rise=2 fall=3，实现秒级故障识别
- 对异地集群适当放宽容忍度：如深圳集群 RT 波动大，可设 fail_timeout=60s，既防误判，又不掩盖真实故障
健康状态 → 动态变量 → 路由决策：打通感知与执行链路
Nginx 本身不存储全局状态，需将探测结果映射为可参与路由逻辑的变量：
- 用外部脚本（如 Python + Redis）定期调用各 DC 健康接口，将结果写入共享键，如 dc:bj:status = "up"
- 在 Nginx 配置中用 map 指令读取该状态：map $redis_dc_bj_status $use_bj { "up" 1; default 0; }
- 结合 if 或 try_files 实现条件转发，例如仅当 $use_bj = 1 时才尝试 proxy_pass http://bj_backend；否则跳转至备用 upstream
多级 fallback：从单节点到整机房的渐进式降级
健康检查结果要驱动有层次的流量转移，而非“全有或全无”：
- 第一层：本地集群内，用 weight + max_fails=3 fail_timeout=20s 快速剔除异常节点，保留健康实例
- 第二层：同地域内跨集群，通过 error_page 502 503 504 = @sh_fallback 将北京集群失败请求自动切至上海集群
- 第三层：全局兜底，定义 upstream global_backup 指向所有存活数据中心的 VIP，作为最后防线
与 DNS/GSLB 协同：弥补 Nginx 的视野盲区
Nginx 看不到跨城网络中断、BGP 异常或整机房电力故障。健康检查必须向上对齐全局调度系统：
- 各数据中心 Nginx 入口暴露相同域名，由 GSLB（如阿里云云解析）定时探测其 VIP 可达性及 HTTP 健康端点
- 当 Nginx 自身健康检查连续多次发现某 DC 全组不可用，可触发脚本通知 GSLB 将该机房 DNS 解析权重降为 0
- DNS TTL 设为 30–60 秒，确保机房级故障能在分钟内完成用户侧收敛
