DNS低TTL配合负载均衡做故障切换，能不能秒级恢复

这个问题在生产环境里经常被问到，尤其是业务做多地域、多线路、海外回国链路、高防切换的时候。把域名TTL设置成10秒、30秒，然后后面接两组负载均衡，主站挂了就把DNS解析切到备站，看起来很自然：DNS很快刷新，流量很快过去，业务很快恢复。

实际使用中发现，DNS低TTL确实能缩短一部分切换时间，但它不是“秒级恢复”的保证。真正影响恢复时间的，不只是权威DNS里写的TTL，还有递归DNS缓存、客户端DNS缓存、应用连接池、浏览器连接复用、运营商解析策略、健康检查周期、负载均衡本身的探测和摘除机制。

简单说，低TTL更像是让“新发起解析的用户”更快拿到新地址，不等于让“所有正在访问的用户”马上切过去。

先把DNS切换链路拆开看

一次域名访问大概会经过这些环节：客户端发起解析，本地系统查缓存，浏览器或应用查缓存，本地DNS递归服务器查缓存，递归服务器再去权威DNS拿记录，拿到IP后客户端建立TCP或TLS连接，然后请求进入负载均衡。

TTL主要约束的是DNS记录在缓存里的存活时间。比如权威DNS返回A记录，TTL是30秒，理论上递归DNS最多缓存30秒。但这里的“理论上”很关键。

有些公共DNS会尊重TTL，30秒就30秒。有些运营商递归DNS可能会设置最小缓存时间，比如你写10秒，它实际按60秒甚至更长处理。还有些客户端应用自己做DNS缓存，Java、Go、Node.js、移动App SDK、浏览器都可能有自己的行为。这里一旦缓存没过期，权威DNS已经切了，客户端也未必马上知道。

所以DNS低TTL解决的是“解析结果多久有机会更新”，不是“故障流量多久一定切走”。

负载均衡的故障切换和DNS切换不是一回事

很多人把DNS切换和负载均衡切换混在一起看。其实它们处在不同层级。

负载均衡内部做故障切换，通常发生在同一个入口IP后面。比如一个公网VIP后面挂了3台后端Web服务器，健康检查发现其中1台502或者端口不通，就把这台摘掉。用户访问的域名和IP没变，请求只是被调度到健康后端。这种切换可以做到很快，5秒、3秒甚至更短都有可能。

DNS切换是把域名从一个IP切到另一个IP。比如主站在A机房，备站在B机房，A机房公网入口不可用，就把www.example.com从1.1.1.1切到2.2.2.2。这个动作要穿过DNS缓存链路，恢复时间更不稳定。

实际架构里，建议把两类切换分清楚：同机房后端故障，交给SLB、Nginx、HAProxy、LVS、云负载均衡处理；跨机房、跨地域、跨线路入口故障，才考虑DNS、GSLB、Anycast BGP或者业务层多活。

TTL设置成10秒，用户真的10秒后都切过去吗

不一定。

看一个生产里比较常见的时间线：

00:00 主机房入口异常，公网IP还通，但后端大量超时。

00:05 监控探测连续失败，触发DNS故障切换。

00:06 权威DNS记录从A入口切到B入口，TTL为30秒。

00:10 部分使用公共DNS的客户端重新解析，拿到B入口。

00:30 到00:90 大部分尊重TTL的递归DNS缓存过期，新解析逐步进入B入口。

02:00 仍有少量运营商递归DNS、企业内网DNS、移动端App缓存继续使用旧IP。

这个过程里，权威DNS切换只用了1秒，但用户侧流量迁移不是1秒。DNS系统天然是分布式缓存系统，不能按单点配置来估算全网行为。

多说一句，很多压测只在本机dig一下权威DNS，看到TTL变化很快，就认为线上也会这么快。这个判断不太稳。更接近真实的做法，是从不同网络、不同递归DNS、不同地区去测解析结果，比如电信、联通、移动、教育网、海外节点、公网DNS 8.8.8.8、1.1.1.1、114DNS、运营商默认DNS都测一遍。

常见TTL与实际恢复感受

下面这组数据不是协议标准，是生产环境里常见的体感区间，适合拿来做预估。

TTL 5秒到10秒：权威DNS变化很快，但部分递归DNS会忽略这么低的TTL；适合灰度、临时迁移、精细调度，但查询量会明显增加。

TTL 30秒：比较常用。公共DNS通常表现不错，切换后几十秒内会看到明显流量迁移。用于故障切换比较合适。

TTL 60秒：稳定性和查询压力比较均衡。多数业务可以接受1到3分钟内流量逐步收敛。

TTL 300秒：常规生产默认值。适合稳定入口，不适合对跨地域故障恢复要求很高的场景。

TTL 600秒以上：适合不频繁变更的记录，比如后台、管理域名、低频业务。拿它做故障切换，恢复时间通常不会好看。

实际使用中发现，TTL设置到30秒以下，收益会开始变窄。原因不是权威DNS做不到，而是递归DNS、客户端缓存和长连接开始成为主要限制。

长连接会让DNS切换看起来“没生效”

DNS只发生在建立连接之前。连接已经建立后，客户端不会因为DNS记录变了就自动断开旧连接。

比如HTTP/2、WebSocket、gRPC、数据库连接池、MQ连接、游戏长连接，这些场景里DNS低TTL的效果会被削弱。客户端只要还连着旧IP，就会继续走旧入口。旧入口如果半死不活，比如TCP能连上但业务响应很慢，客户端还可能卡很久。

这也是为什么有些故障里，DNS已经切到备用机房了，但监控里旧机房还有流量。不是DNS没切，而是连接没断、缓存没过、客户端没重新解析。

这里补充一点，故障切换要想快，旧入口的失败状态反而要明确。端口彻底不通、TCP快速失败，客户端更容易重连和重新解析。最麻烦的是“能连上但请求超时”，这种半故障会拖慢恢复。

健康检查周期比TTL更容易被低估

很多人只盯TTL，忽略健康检查。DNS故障切换通常依赖探测系统判断主入口不可用，然后才修改解析。探测策略如果太保守，前面已经浪费几十秒。

比如健康检查间隔10秒，失败3次判定故障，那最少就要接近30秒才触发。再加DNS缓存，用户侧恢复可能就是1到3分钟。

如果业务目标是更快恢复，健康检查可以设成间隔2秒到5秒，失败2到3次切换。但这也会带来误切风险。网络抖动、单个探测点异常、源站限流，都可能导致错误切换。

生产里更稳的做法是多探测点投票，不要只靠一个监控节点。比如北京电信、上海联通、广州移动、香港、美国西海岸同时探测，达到一定失败比例才切。否则某条线路抖一下，DNS就来回漂，用户体验会更差。

什么时候DNS低TTL能接近秒级效果

有些场景确实能看到接近秒级的切换效果，但条件比较苛刻。

客户端每次请求都重新解析，或者连接生命周期很短。

客户端使用的递归DNS尊重低TTL。

故障探测非常快，且不会误判。

备用入口长期热备，证书、配置、数据、缓存都已经准备好。

旧入口故障表现为快速失败，而不是长时间超时。

业务入口没有被企业内网DNS、代理、SDK缓存强行固定。

满足这些条件时，部分用户能在10秒到30秒内恢复。但要说全网所有用户稳定秒级恢复，DNS低TTL单独扛不住。

真正要秒级，通常要把故障控制在DNS下面

如果业务对恢复时间要求很高，应该尽量让入口IP不变，把故障切换放在负载均衡、Anycast BGP、GSLB调度、服务发现、客户端容灾这些层面。

同地域内，公网负载均衡后面挂多台后端，健康检查摘除异常节点，这类切换最直接。用户不需要重新解析DNS，不受递归缓存影响。

跨可用区，可以用云厂商的多AZ负载均衡。入口VIP不变，后端跨AZ。单AZ故障时，SLB调度到其他AZ。这个恢复速度通常比DNS切换稳定。

跨地域就复杂一些。可以用GSLB加低TTL，也可以用Anycast BGP把同一个IP在多个地域宣告出去。Anycast适合边缘接入、DDoS清洗、静态加速、DNS服务这类场景，但业务有状态、回源路径、会话保持都要额外设计。

对于游戏、金融交易、实时音视频这类长连接业务，DNS切换只能算入口容灾的一部分。客户端需要有重连策略、备用域名、备用IP列表，甚至要支持线路探测和主动切线。

海外回国和高防场景更要注意TTL预期

海外业务经常会遇到这种设计：正常流量走韩国、日本、香港精品线路，攻击来了切到美国高防或国内高防清洗，或者主线路拥塞时切备用线路。

这里DNS低TTL有用，但要看业务类型。网站类、API类、短连接业务，30秒TTL配合健康检查，切换效果通常可以接受。游戏长连接、WebSocket、TCP隧道类业务，DNS切换后老连接不会自动迁移，客户端重连策略才是关键。

如果你也在找这种高防、海外回国优化、企业建站用的云服务器，可以看看129云。比如美国高防-C型适合需要300G防御、三网精品线路的业务；韩国-E型带傲盾防火墙和回国优化，适合对亚洲访问延迟敏感的场景；内蒙电信-B型更偏建站和电信优化线路。需要按业务线路和防御量确认的话，可以直接打客服热线400-9177118。

DNS低TTL不是越低越好

TTL太低会增加权威DNS查询量。对普通业务来说，这个成本可能不明显，但对大流量站点、全球业务、频繁解析的移动端业务，查询量会很可观。

还有一个问题是稳定性。TTL低意味着解析变化更快，如果调度系统判断不准，用户会频繁拿到不同入口。对于有会话保持、地域缓存、源站数据一致性要求的业务，这种漂移不一定是好事。

生产里常见设置是：核心业务入口TTL设30秒到60秒；稳定后台域名设300秒；验证、迁移、灰度期间临时降到30秒；切换完成并稳定后再按业务情况调回去。

不建议长期把所有记录都设成1秒、5秒。很多递归DNS不会完全尊重，权威DNS压力上去了，用户侧收益却不明显。

故障切换前要提前把备用入口热起来

DNS切过去只是让流量到备用入口。备用入口能不能扛住，是另一件事。

实际事故里见过不少情况：DNS切换成功了，备用机房CPU打满；证书链不完整；Nginx配置少了一段；对象存储跨区权限没开；数据库只读副本不能写；缓存没预热，请求全打到数据库；高防IP回源白名单没加。

这些问题和TTL没关系，但会让人误以为“DNS故障切换不可靠”。更准确地说，是备用链路没有长期处于可接管状态。

比较稳的做法是让备用入口长期承接一小部分真实流量，比如1%到5%。这样证书、配置、日志、监控、链路质量都会持续暴露问题。完全冷备只在演练时跑一下，真故障时风险很高。

监控指标别只看域名解析

DNS切换类监控至少要看三层。

解析层：不同地区、不同运营商、不同递归DNS拿到的A记录或CNAME是否符合预期。

连接层：TCP握手、TLS握手、首包时间、丢包率、重传率。

业务层：HTTP状态码、接口耗时、登录成功率、支付成功率、房间连接成功率、消息发送成功率。

只看解析会漏掉很多问题。DNS已经返回备用IP，但备用IP的TLS握手慢、回源失败、数据库写入异常，用户还是不可用。

多说一句，健康检查也不要只探测/health返回200。很多业务的/health是本机进程活着就返回200，数据库挂了、Redis挂了、上游API挂了，它仍然健康。切换系统应该探测更接近真实业务的路径，至少要覆盖依赖项的关键状态。

DNS切换时还要考虑CNAME链路

很多域名不是直接A记录，而是CNAME到CDN、WAF、高防、GSLB平台。CNAME链路里每一层都有TTL。

比如www.example.com CNAME到a.gslb.example.net，a.gslb.example.net再返回A记录。你只把www的TTL设成30秒，但下一级A记录TTL是300秒，实际切换仍然可能被300秒拖住。

排查时不要只dig最终域名，要把CNAME链逐层展开，看每一层TTL。尤其是接入CDN、高防IP、海外加速节点时，这个问题很常见。

业务侧重连策略比想象中重要

客户端如果拿到旧IP访问失败，下一步怎么做，决定了用户恢复速度。

浏览器访问普通网页，刷新一次可能就重新解析了。移动App不一定，有些HTTP客户端连接池会复用连接，有些SDK会缓存DNS结果，有些失败重试还是打同一个IP。

长连接业务更明显。客户端应该在连续失败后断开连接，清理DNS缓存或重新走系统解析；可以内置备用域名；可以做多个接入点测速；也可以在服务端下发备用入口列表。

这里不要把所有压力都交给DNS。DNS负责告诉客户端入口在哪里，客户端也要知道入口不可用时怎么重新选择。

一个比较接近真实的恢复时间估算

假设TTL为30秒，健康检查间隔5秒，失败3次切换，公共DNS和运营商DNS混合，业务以HTTPS短连接为主。

故障发现时间：10到15秒。

DNS记录切换时间：1到3秒。

递归DNS缓存过期：30到90秒内大部分完成。

客户端重新建连：几秒到几十秒。

这种情况下，大盘流量可能在1分钟左右明显恢复，2到3分钟趋于稳定。部分用户可以在30秒内恢复，少量用户会更慢。

如果是WebSocket或游戏TCP长连接，恢复时间更多取决于客户端超时和重连。客户端如果设置60秒读超时，再加DNS缓存，用户侧感知可能就是1到3分钟甚至更长。

哪些场景适合用DNS低TTL做故障切换

网站、API、管理后台、下载入口、短连接服务，适合用DNS低TTL配合GSLB或健康检查做主备切换。

多线路访问，比如电信、联通、移动、海外用户分线路解析，也适合。TTL设30秒到60秒，既能应对线路波动，也不会让DNS查询量过于夸张。

高防切换也适合，但要提前验证清洗线路、回源白名单、证书、源站隐藏、防护策略。DDoS场景下，攻击流量不会因为DNS切换马上消失，旧IP还会继续被打，源站暴露过的话也可能被绕过高防直打。

不太适合只靠DNS低TTL的场景，是强实时长连接、交易链路、状态强绑定业务、企业内网客户端大量固定DNS缓存的系统。这些业务需要入口层、客户端、服务端一起设计。

实际配置时可以这样取值

生产主入口TTL：30秒或60秒。

健康检查间隔：3秒到5秒。

失败判定：连续2到3次失败。

恢复判定：连续3到5次成功后再切回，避免抖动。

自动切回：谨慎开启。主站刚恢复时，缓存、连接、数据库复制、队列堆积都可能还没完全稳定，自动切回容易造成二次故障。

探测点：至少覆盖主要用户所在运营商和地区，海外业务要加海外探测点。

备用入口：长期小流量承载，不要只做冷备。

验证DNS故障切换不要只在办公室测

办公室网络经常走固定递归DNS，测出来的结果代表性很弱。更靠谱的验证方式是多点拨测。

可以从云服务器上测，比如国内电信、联通、移动各一台，香港一台，美国一台，韩国一台。用dig指定不同递归DNS，也用系统默认DNS测一遍。

命令层面可以看这些信息：dig 域名、dig @8.8.8.8 域名、dig @1.1.1.1 域名、dig +trace 域名。再配合curl看实际访问IP、握手耗时、HTTP状态码。

注意不要只看DNS返回值，还要看请求是否真的打到备用入口。可以在负载均衡日志里加入口标识，或者让备用入口返回特定Header，排查会快很多。

DNS低TTL能做什么，不能做什么

它能让新解析更快拿到新入口。

它能降低跨地域、跨线路故障时的流量迁移等待时间。

它能配合GSLB、健康检查、高防切换完成自动调度。

它不能强制所有递归DNS立即刷新。

它不能让已有TCP连接自动迁移。

它不能替代负载均衡后端摘除。

它不能修复备用机房配置、容量、数据一致性问题。

把TTL设低是必要动作，但秒级恢复更多依赖入口架构、探测策略、客户端重连、备用资源热备和线路质量。DNS这层能加速切换，但别把它当成唯一的故障恢复开关。