DNS解析TTL值设太低和设太高各自会踩什么坑

DNS TTL看起来只是一个数字，很多人改解析时顺手填个60、300、600、3600，甚至直接用DNS服务商默认值。实际线上跑一段时间就会发现，TTL不是越低越灵活，也不是越高越稳定。它影响的是递归DNS缓存多久，也就是用户、运营商Local DNS、公共DNS在多长时间内继续相信旧记录。

这里先把概念放准：TTL是权威DNS返回给递归DNS的缓存时间，单位是秒。比如A记录TTL=600，理论上递归DNS在10分钟内不会再问权威DNS，而是直接把缓存结果返回给用户。理论归理论，实际还会遇到运营商Local DNS不严格遵守、浏览器和系统本地缓存、应用层长连接等因素，所以TTL只能影响“解析层面的切换速度”，不能保证业务流量立刻切干净。

TTL设太低，最先踩到的是查询量和稳定性

很多业务喜欢把TTL设成30秒、60秒，理由也直接：方便故障切换，IP换了能快点生效。这个思路在灰度、迁移、DDoS清洗切换时确实有用，但长期全量用低TTL，会带来一些不太直观的问题。

权威DNS查询量会明显上升

TTL越低，递归DNS缓存越短，权威DNS被请求的频率越高。一个日活不大的站点可能感觉不明显，但如果是游戏登录服、API域名、下载域名，访问峰值一上来，DNS查询量会很快放大。

举个实际使用中常见的量级。假设某业务有20万活跃用户，用户分布在多个运营商和地区，访问入口域名是api.example.com。TTL=600时，很多递归DNS会在10分钟内复用缓存；TTL=60时，同样的递归节点一分钟就可能重新请求一次。权威DNS侧的QPS不一定按10倍精确增长，但增长到3倍到8倍很常见，尤其是用户分布比较散、公共DNS占比高的时候。

如果权威DNS本身质量一般，或者用的是免费套餐，低TTL反而会把DNS链路变成薄弱点。业务服务器没问题，BGP线路也没问题，用户却偶发解析慢、解析失败，这类问题排查起来很烦，因为从服务端日志看不到用户请求。

解析抖动会更频繁暴露给用户

TTL低意味着递归DNS更频繁地重新询问权威DNS。权威DNS的任播节点、运营商链路、跨境访问质量，只要某一段抖一下，用户就更容易感知到解析延迟。

比如海外业务面向中国大陆用户，域名托管在海外DNS平台，TTL设60秒。平时看dig结果正常，但在晚高峰，部分地区Local DNS到权威DNS的链路抖动，解析耗时从几十毫秒变成几百毫秒甚至超时。页面首包慢，用户以为服务器卡，其实服务器根本还没收到请求。

多说一句，DNS解析失败和TCP连接失败在用户侧表现都可能是“打不开”。很多监控只盯HTTP 200和端口连通，不盯DNS解析耗时，低TTL把DNS查询频率拉高后，这个盲区就容易被放大。

对高并发短连接业务不友好

低TTL对长连接业务影响相对小一些，因为连接建立后，后续请求不一定反复解析。短连接、SDK频繁初始化、客户端不做DNS缓存的业务，影响会更明显。

有些移动端SDK每次启动都重新解析域名，TTL设得很低时，用户在弱网下更容易卡在DNS阶段。不是所有客户端都会按系统DNS缓存来走，也不是所有网络环境都对DNS友好。公共Wi-Fi、校园网、企业出口、防火墙代理环境里，DNS行为经常比较复杂。

低TTL不等于秒级切换

这是最容易误判的地方。把TTL设成30秒，并不代表改记录后30秒全球生效。原因有几个：

一是递归DNS可能不完全遵守TTL。有些运营商Local DNS会做最小TTL保护，比如你给30秒，它内部按120秒、300秒缓存。二是客户端本地也可能缓存，Windows、Linux、Android、iOS、浏览器、JVM都有自己的处理方式。三是应用如果已经建立了TCP长连接，DNS切换不会踢掉老连接。

实际故障切换时，经常看到这样的情况：TTL已经提前降到60秒，A记录从旧IP切到新IP，5分钟后大部分流量过来了，但仍有5%到15%的流量打到旧IP，持续十几分钟甚至更久。这个比例和用户网络、运营商、客户端实现有关，不能只看DNS控制台上的TTL数字。

TTL设太高，问题一般出在变更和故障恢复

TTL设高的好处也明显：解析查询少，递归DNS命中率高，权威DNS压力低，用户解析速度通常更稳定。像官网、图片静态域名、长期不变的CDN CNAME，TTL设到1800、3600甚至更高都很常见。

坑也很直接：一旦要变更，旧记录会活很久。

迁移服务器时，流量切不干净

假设业务从旧机房迁到新机房，域名A记录TTL原来是86400，也就是24小时。上午10点把A记录改成新IP，不代表用户马上访问新服务器。已经缓存旧解析的递归DNS，可能到第二天才重新请求。

线上迁移最怕这种“半新半旧”。数据库写入、文件上传、登录态、支付回调，只要还有用户打到旧节点，就可能出现数据不一致。特别是没有做双写、共享存储、统一Session的老系统，高TTL会把迁移窗口拉得很长。

实际做迁移前，通常会提前一到两天把TTL从3600或86400降到300，等旧缓存自然过期后再切A记录。切完观察一段时间，再把TTL调回600或1800。这里的关键不是切换当天才降TTL，那样对已经缓存高TTL的递归DNS没用。

故障切换会被旧缓存拖住

服务器宕机、机房网络故障、上游BGP异常、被DDoS打穿，这时如果TTL很高，就算DNS控制台马上把记录切到备用IP，用户侧仍然可能继续拿到故障IP。

比如TTL=3600，某地区递归DNS在故障前1分钟刚缓存了旧IP，那它理论上会继续缓存59分钟。业务侧看起来已经完成切换，用户侧还在访问坏节点，这种体验很割裂。

高防场景也一样。平时源站IP直连，攻击来了临时切到高防IP，如果TTL原来设得很高，攻击流量和正常用户都会继续打源站一段时间。更稳的做法是高风险业务平时就把入口架构设计好，比如域名长期指向高防或负载入口，源站不直接暴露，DNS不要承担临时救火的全部压力。

多地域调度不够灵活

做海外访问优化时，经常会用不同线路承载不同用户，比如中国大陆用户走香港CN2、美国用户走洛杉矶或圣何塞，欧洲用户走德国GTT直连。DNS智能解析可以按线路返回不同IP，但TTL过高会降低调度弹性。

比如某段时间香港链路拥塞，需要临时把部分流量切到美国精品网，TTL=1800还能接受，TTL=86400就很难受。用户Local DNS缓存了香港IP，调度策略改了也不一定马上生效。

如果你也在找这种需要结合线路、带宽和防护一起考虑的云服务器，可以看看129云。比如香港CN2大宽带-A型适合对大陆访问延迟敏感的小型业务入口，美国精品网-C型适合北美访问和跨境业务，德国双ISP-G型带1Gbps带宽、GTT直连，更适合欧洲方向带宽型服务。需要按业务场景选型时，也可以直接打客服热线400-9177118确认线路和带宽细节。

常见TTL取值放到业务场景里看

下面这些不是固定模板，更像线上常用区间。真正设置时还要看业务是否频繁变更、是否有备用节点、DNS服务商质量、客户端类型、是否依赖CDN或高防。

静态官网、企业站、很少变更的A记录：TTL可以设1800到3600。解析稳定，权威DNS压力低，日常维护简单。如果服务器IP一年都不换，设高一点没什么问题。

普通API入口、后台管理、业务主域名：TTL常见是300到600。这个区间比较平衡，既不会让权威DNS查询量太夸张，也能在迁移或故障时较快切换。

灰度发布、服务器迁移、临时切流：TTL可以提前降到60到300。注意是提前降，不是切换时才降。比如原TTL=3600，计划明天上午10点迁移，今天就该把TTL降下来，让旧缓存先过期。

DDoS高风险入口、需要快速切高防的域名：TTL可以长期设300左右，必要时降到60。但不要幻想靠DNS单独抗DDoS。攻击流量如果已经知道源站IP，改DNS也挡不住，源站隐藏、高防回源、ACL、WAF、BGP清洗都要一起看。

CDN CNAME：通常跟着CDN厂商建议走，常见是300到600。有些CDN会在自己的调度系统里做更细粒度的节点选择，业务侧把CNAME TTL设得过高，可能影响厂商调度策略生效速度。

TTL太低和太高的差异，放一张对照表更直观

TTL=60秒：优点是变更感知快，适合迁移前、故障演练、临时切流。问题是DNS查询量高，解析链路抖动更容易暴露，权威DNS质量要求更高。实际生效通常不是60秒全量完成，可能要几分钟到十几分钟。

TTL=300秒：线上很常见。切换速度和稳定性相对均衡，适合API、业务入口、CDN CNAME。大多数场景下，5分钟级别的解析缓存比较好控制。

TTL=600秒：适合变更不频繁但又希望保留一定切换能力的业务。对于访问量较大的站点，可以减少不少权威DNS请求，同时变更窗口还能接受。

TTL=3600秒：适合稳定域名、官网、静态服务、长期不换IP的解析。坑是故障切换会慢，临时迁移容易拖出长尾流量。

TTL=86400秒：只有在非常稳定、几乎不变更的记录上才建议考虑。比如某些内部固定解析、验证类记录、长期不动的辅助域名。业务入口域名不太建议这么高，除非已经确认变更不依赖DNS。

实际变更时，TTL要提前处理

很多解析事故不是TTL设置错，而是改TTL的时机错。比如原来A记录TTL=3600，准备10分钟后切IP，于是先把TTL改成60，再马上改A记录。这样做只能影响之后来权威DNS查询的新递归DNS，对已经缓存旧IP且剩余TTL还有很久的递归DNS没有帮助。

正确节奏是：如果原TTL=3600，至少提前1小时以上降到300或60；如果原TTL=86400，最好提前一天降。等旧缓存过期后，再执行正式切换。切换完成并观察稳定后，再把TTL调回正常值。

这里补充一点，NS记录和域名注册商侧的DNS服务器变更，传播周期通常比普通A记录更不可控。换DNS服务商时，不要只看A记录TTL，还要看NS记录在父区的TTL。很多人从免费DNS迁到企业DNS，结果旧NS被缓存，部分地区还在问旧权威DNS，出现新旧解析并存。

低TTL配合监控才有意义

TTL设低是为了快速切换，但如果没有监控和自动化，低TTL只是给手工操作留了余地。线上更关键的是知道什么时候该切、切到哪里、切完效果如何。

至少要监控三个层面：DNS解析结果、解析耗时、业务可用性。只监控HTTP可用性不够，因为HTTP失败时已经晚了一步；只监控DNS也不够，因为解析正常不代表后端服务正常。

比较常见的做法是多地区探测。比如北京、上海、广州、成都、香港、新加坡、洛杉矶、法兰克福都做dig和HTTP探测。DNS层面看A记录是否符合预期、TTL返回是否异常、解析耗时是否飙高；业务层面看TCP连接、TLS握手、HTTP状态码、接口耗时。

如果业务跑在多地域云服务器上，DNS只是流量入口的一部分。线路质量也会影响用户体验。像中国大陆访问香港，CN2链路通常比普通国际线路稳定；访问美国，如果面向大陆用户，精品网、GIA这类线路差异会很明显；欧洲方向则要看GTT、Cogent、Telia等上游组合。DNS把用户调到某个IP后，后面的网络路径才是真正承载流量的部分。

有些缓存不是TTL能控制的

排查DNS切换不生效时，经常会遇到“控制台已经改了，但用户还访问旧IP”。这时不要只盯权威DNS。

浏览器可能缓存DNS，Chrome、Firefox都有自己的DNS缓存机制；操作系统也可能缓存，Linux上的nscd、systemd-resolved，Windows DNS Client服务都会影响结果；JVM应用默认DNS缓存策略还可能很长，老版本或特定配置下甚至会缓存到进程退出。

还有一些客户端会把解析结果写入本地配置或数据库，下一次启动才更新。游戏客户端、IoT设备、嵌入式终端里这种情况并不少。TTL对这些“应用层自定义缓存”基本没约束力。

所以在设计切换方案时，旧IP最好不要立刻下线。即使TTL=60，也建议旧节点保留一段时间，至少能返回重定向、维护页，或者继续代理到新节点。对登录、支付、订单这类状态敏感业务，更不能只靠DNS切换来完成迁移。

DNS TTL和高防切换的关系要单独看

DDoS场景下，TTL容易被误用。很多人以为平时源站直连，攻击时把A记录切到高防IP就行。这个动作在小流量攻击或攻击者只打域名时可能有效，但在真实攻防里风险很高。

如果攻击者已经拿到源站IP，DNS怎么改都没用，攻击会继续打源站。TTL低只能让正常用户更快访问高防IP，不能让攻击流量停止。源站隐藏才是关键，比如源站只允许高防回源IP访问，安全组或防火墙封掉其他来源，业务入口长期挂在高防或负载均衡前面。

TTL在高防方案里的角色更像调度速度控制。平时TTL=300，攻击期间切换到高防清洗入口，观察正常用户回流；攻击结束后不要急着切回源站，先确认攻击是否停止、源站IP是否暴露、运营商黑洞是否解除。TTL设太低会增加解析压力，设太高会拖慢用户回流，这里通常不会用86400这种长缓存。

线上比较稳的TTL习惯

业务入口域名长期用300或600比较多。这个区间对大部分Web、API、游戏登录服都比较友好。既能应对一般切换，也不会让DNS查询量失控。

大规模迁移前提前降TTL。原来是3600就提前几个小时，原来是86400就提前一天。切换完成后不要马上把旧节点关掉，保留观察窗口，看访问日志里旧IP流量是否下降到可接受范围。

高风险域名不要把TTL设得太高。尤其是需要做BGP切换、高防切换、跨地域容灾的业务，TTL=3600以上会让应急动作变钝。更推荐用300作为常态，需要变更时再临时降到60。

低TTL要配可靠DNS服务。权威DNS本身要有Anycast、多线路节点、抗DDoS能力和稳定SLA。否则TTL越低，越是在放大DNS服务商的抖动。

切换后用多地递归DNS验证，不要只在本机dig。可以分别查114.114.114.114、223.5.5.5、119.29.29.29、8.8.8.8、1.1.1.1，再加上不同地区探测点。看到某个公共DNS已经返回新IP，不代表所有用户都切过来了；看到某个地区还在旧IP，也不一定是解析没改，可能是递归缓存还没过期。

如果服务器本身也要换，别只看CPU和内存，线路要一起评估。比如游戏登录服和API入口对延迟敏感，香港CN2大宽带-A型这类双向CN2会更合适；下载、分发、欧洲用户访问可以看德国双ISP-G型的1Gbps带宽；北美业务或跨境企业站可以看美国精品网-C型。选机器时顺便把DNS TTL、备用IP、高防入口、监控探测一起规划，后面少很多临时救火。