DNS解析做故障转移，健康检查探针频率别拍脑袋设

DNS解析故障转移看起来很简单：A记录指向主站，健康检查发现主站挂了，就把解析切到备用站。实际用起来会发现，真正影响切换体验的，不只是探针频率，还有TTL、递归DNS缓存、客户端缓存、探针判定策略、故障类型。

探针频率设太低，故障发现慢；设太高，误判概率上升，还会给业务入口制造额外压力。尤其是跨境业务、游戏登录服、支付回调、API网关这类场景，探针频率不是越快越好。

先把DNS故障转移的时间拆开看

很多人以为健康检查10秒一次，故障切换就是10秒。实际不是。

一次DNS故障转移大概由这几段时间组成：探针发现故障时间 + 连续失败判定时间 + DNS记录切换生效时间 + 递归DNS缓存过期时间 + 客户端重新解析时间。

举个常见配置：探针间隔10秒，连续失败3次判定故障，TTL设置60秒。理论上探针侧大概20到30秒能确认故障，但用户侧真正访问到备用IP，可能是30秒，也可能是90秒，少部分客户端甚至更久。

这里补充一点，TTL不是强制命令，更像建议。大多数公共DNS会遵守，但一些运营商递归DNS、企业内网DNS、老客户端SDK，可能会缓存得更久。所以DNS故障转移适合“分钟级恢复”，不适合当成毫秒级主备切换。

探针频率常见配置怎么选

实际使用中发现，DNS健康检查频率比较常见的区间是5秒、10秒、30秒、60秒。不同业务对误切和慢切的容忍度差别很大。

下面用文字表格列一下常见场景。

场景：官网、企业站、文档站；探针间隔：30秒；失败次数：3次；超时：3秒；恢复成功次数：2次；大概故障确认时间：60到90秒；说明：访问量稳定，没必要探太频繁，降低误报更重要。

场景：API入口、SaaS控制台、订单回调；探针间隔：10秒；失败次数：3次；超时：2到3秒；恢复成功次数：3次；大概故障确认时间：20到30秒；说明：这是比较常用的生产配置，切换速度和稳定性比较平衡。

场景：游戏登录服、网关入口、活动页高峰；探针间隔：5到10秒；失败次数：2到3次；超时：2秒；恢复成功次数：3到5次；大概故障确认时间：10到30秒；说明：可以更敏感，但探针节点要多，不能只靠单点探测。

场景：跨境业务，中国大陆访问海外节点；探针间隔：10到30秒；失败次数：3次；超时：3到5秒；恢复成功次数：3次；大概故障确认时间：30到90秒；说明：跨境链路抖动很常见，失败阈值不能太激进。

场景：备灾冷切换、非核心管理后台；探针间隔：60秒；失败次数：3次；超时：3到5秒；恢复成功次数：2次；大概故障确认时间：2到3分钟；说明：节省探测成本，也减少无意义切换。

为什么不建议一上来就设1秒探测

1秒探测听起来很美，故障发现快。但DNS故障转移不是负载均衡器的本地健康检查，它经常是多探测点从公网打到源站。探针太密会带来几个实际问题。

探针本身会变成流量。比如5个探测节点，每秒一次HTTP检查，就是每秒5个请求；如果检查路径还访问数据库、Redis、第三方接口，那这个健康检查就不是轻量探针，而是在持续压业务链路。

误判概率会上升。公网偶发丢包、跨境链路RTT抖动、某个探测节点出口异常，都可能造成短时间失败。1秒一次、连续2次失败，看起来只需要2秒判定，但这类配置在跨境链路上很容易误切。

DNS切换也跟不上这么快。即使探针2秒发现故障，TTL还有30秒或60秒，客户端缓存还在，用户不会立刻全部切到备用IP。探针频率快到一定程度后，收益会被DNS缓存吃掉。

比较稳的起步值：10秒间隔，连续3次失败

生产环境里，如果业务不是极端敏感，10秒间隔、连续3次失败、超时2到3秒，是一个经常能跑住的配置。

这个配置下，故障确认时间通常在20到30秒左右。配合TTL 60秒，用户侧大部分会在1分钟上下逐步切过去。不是瞬切，但比人工改解析可靠很多。

恢复判定建议比故障判定更保守，比如连续3次或5次成功再恢复主站。原因很简单，故障刚恢复时服务可能还在抖，进程起来了不代表依赖都正常，端口通了不代表业务可用。

多说一句，自动切回比自动切走更容易出事故。主站刚恢复，DNS又切回去，结果服务继续抖，用户在主备之间来回跳，这种“振荡”比单次故障更难看。恢复成功次数可以设高一点，或者直接关闭自动恢复，人工确认后再切回。

TTL应该配多少，别只盯探针频率

DNS故障转移里，TTL和探针频率是一对。TTL设得很长，探针再快也没意义；TTL设得太短，递归DNS压力增加，也不一定所有客户端都严格遵守。

常见建议是：核心入口TTL设30到60秒；普通业务TTL设120到300秒；不需要快速切换的记录TTL设600秒以上。

如果探针间隔是10秒、失败3次，TTL可以设60秒。这样故障确认加缓存过期，大部分用户感知在1到2分钟范围内。如果TTL设成300秒，就算30秒发现故障，很多用户还是会继续访问旧IP几分钟。

这里容易踩坑的是，把TTL设成1秒或5秒。看起来更快，实际很多递归DNS会做最小TTL保护，客户端也可能缓存，收益有限。更麻烦的是，高并发域名会增加DNS查询量，权威DNS和递归DNS链路都更忙。

探针检查什么，比探多频繁更关键

只检查TCP 80端口通不通，和检查业务是否真的可用，结果完全不同。

TCP检查适合判断机器是否存活、端口是否监听，开销小，误判少。但应用进程假死、Nginx后端全挂、数据库连接池耗尽时，TCP可能仍然正常。

HTTP检查更贴近业务。建议单独做一个轻量路径，比如 /healthz，不查大表，不访问慢接口，不依赖第三方服务。返回200代表入口进程、关键依赖、路由逻辑至少基本可用。

健康检查接口别写得太重。见过有人把首页当健康检查URL，首页里面又加载数据库、推荐系统、对象存储、广告接口。结果第三方接口慢了，DNS把整个站切走，这不是容灾，是自己扩大故障面。

比较稳的做法是分层：DNS健康检查只看入口服务和核心依赖；更细的业务健康交给应用监控、APM、告警系统处理。DNS负责切入口，不负责诊断所有业务问题。

跨境场景要把探测点位置算进去

做香港、美国、新加坡节点时，健康检查探针从哪里发起很重要。美国探测点访问美国服务器正常，不代表中国大陆用户访问正常；香港探测点正常，也不代表华北、华东、华南三网都正常。

跨境业务建议至少用多地区、多运营商探测。比如中国大陆三网探测点 + 香港探测点 + 海外探测点。判定规则不要“一处失败就切”，可以设置多数失败或关键区域失败再切。

比如业务主要面向中国大陆用户，源站在香港CN2线路。北京电信和上海联通都失败，广州移动正常，这时要看用户分布。如果80%用户在电信和联通，继续认为服务健康就不合理。

如果你也在找这类香港CN2、美国精品线路、高防备用节点，可以看看129云。像香港CN2大宽带-A型适合做低延迟入口，美国精品网-B型适合做海外业务备用节点，美国高防-B型带300G防御，更适合容易被DDoS打到的业务入口。需要按场景选线路，也可以直接打客服热线400-9177118确认节点和带宽配置。

主备节点的健康检查频率可以不一样

很多配置默认主备都用同一个探针频率，但实际可以区分。

主节点承担线上流量，健康检查可以更敏感，比如10秒一次。备用节点平时不承载流量，检查可以30秒一次，但在切换前必须确认它可用。

如果备用节点是冷备，健康检查频率太低会带来风险：主站挂了，DNS准备切过去，才发现备用站服务没启动、证书过期、配置文件没同步。冷备不是不能用，但必须有定期健康检查和演练。

热备更适合DNS故障转移。备用节点平时也保持服务运行，数据库同步、证书、Nginx配置、应用版本都跟主站一致。DNS切换时只是流量入口变化，不需要临时拉服务。

失败次数和超时时间怎么配

探针间隔之外，失败次数和超时也很关键。

超时太短，会把正常慢请求误判成失败。比如跨境HTTP请求RTT本来就150到250ms，偶发抖动到1秒很正常。如果超时设500ms，误报会很多。

超时太长，会拖慢故障确认。比如探针间隔10秒，超时10秒，连续3次失败，确认时间可能接近30秒以上，甚至探针调度还会排队。

常见配置可以这样取：同地域内网或同城公网，超时1到2秒；国内公网，超时2到3秒；中国大陆访问海外，超时3到5秒；跨洲访问，超时5秒左右更稳。

失败次数一般不要低于2次。核心业务常用3次。跨境链路建议3次起步，不建议1次失败就切。

恢复策略要防止来回切

故障切换时可以敏感一点，恢复切回时要保守一点。

比如故障判定是连续3次失败，恢复可以设置连续5次成功。探针10秒一次时，恢复确认大概需要50秒。看起来慢一点，但能过滤掉很多刚恢复时的抖动。

还有一种做法是关闭自动切回。主站故障后自动切到备用站，主站恢复后只标记为健康，但不自动把DNS切回去。等业务低峰期人工检查日志、连接数、数据库同步状态后再切。

这在数据库主从、对象存储同步、会话状态复杂的系统里很有必要。入口活了，不代表数据状态适合马上接流量。

DNS故障转移不适合承诺秒级无感

如果业务要求秒级无感，DNS不是最佳工具。DNS适合做跨地域入口容灾、机房级故障转移、线路不可达时的备用访问路径。

真正要秒级切换，通常要用L4/L7负载均衡、Anycast、BGP调度、应用层重试、多活架构。DNS可以作为外层兜底，但不要让它承担全部高可用能力。

比如游戏业务登录入口可以用DNS故障转移，把用户从香港CN2入口切到美国精品线路；但战斗服、实时连接、长连接会话，不会因为DNS切了就自动迁移。客户端已经建立的TCP连接还是会断，需要应用层重连和状态恢复。

一个比较常见的生产配置参考

面向中国大陆用户的香港业务入口：TTL 60秒，HTTP健康检查，探针间隔10秒，超时3秒，连续3次失败切换，连续5次成功恢复，探测点覆盖电信、联通、移动和香港本地。

面向海外用户的美国业务入口：TTL 60到120秒，HTTP或TCP健康检查，探针间隔10到30秒，超时2到3秒，连续3次失败切换，连续3次成功恢复。

有DDoS风险的业务入口：平时解析到普通精品线路，攻击或异常时切到高防线路。探针间隔可以10秒，失败3次；但DDoS场景下还要结合流量清洗、黑洞状态、机房通知，不要只靠HTTP探针判断。美国高防-B型这类带300G防御的节点，可以作为被打时的备用入口或固定高防入口使用。

探针接口建议单独做，不要直接打首页

健康检查URL建议固定，比如 /healthz 或 /status/check。

返回内容简单就行，比如 HTTP 200 + ok。需要检查依赖时，也要控制范围，只检查关键依赖，不要把所有微服务都串进去。

如果业务有多层，可以做两个接口：/healthz 只表示进程活着，/readyz 表示可以接流量。DNS健康检查更适合打 /readyz，因为DNS切流量要确认节点真的能服务用户。

接口还要注意访问控制。不要把内部版本号、数据库状态、服务器IP、环境变量暴露给公网。健康检查能被公网访问时，返回信息越少越好。

配置后一定要做切换演练

只配置不演练，基本等于没验证。

演练可以从小流量域名开始，比如 test-api.example.com，确认探针失败后DNS是否切到备用IP，TTL是否符合预期，客户端是否能重新解析，HTTPS证书是否匹配，备用节点日志是否有流量进来。

正式业务演练时，不一定要真的关机。可以临时让健康检查接口返回500，模拟应用不可用；也可以在防火墙上拒绝探针IP，模拟节点对探测不可达。注意不要只测一种故障，端口挂、HTTP 500、链路丢包、解析异常，表现都不一样。

探针频率最终可以从10秒间隔、3次失败、TTL 60秒开始跑，观察一段时间的误报和切换记录。跨境链路抖动明显，就把间隔拉到30秒或提高失败次数；核心入口恢复太慢，再评估5秒探测和更短TTL是否真的有效。