DNS解析TTL设太低和设太高分别会踩什么坑

TTL这个参数平时看着不起眼，真出故障时会非常明显。它决定DNS记录在递归DNS、Local DNS、部分客户端缓存里能存多久。TTL设成300秒，理论上就是5分钟后缓存过期，再去权威DNS查一次；设成3600秒，理论上就是1小时。

实际使用中发现，TTL不是越低越灵活，也不是越高越稳定。它更像一个“缓存保质期”。保质期太短，查询压力和抖动会变多；保质期太长，切换线路、迁移IP、故障摘除时会拖很久。

先把TTL的作用说清楚

用户访问 example.com，不是每次都直接问权威DNS。大部分请求会先经过运营商DNS、公共DNS，比如 114DNS、Google DNS、Cloudflare DNS、阿里DNS、腾讯DNS，也可能经过企业内网DNS、路由器DNS、浏览器DNS缓存。

权威DNS返回A记录、AAAA记录、CNAME记录时，会带一个TTL。递归DNS拿到结果后，在TTL没过期之前，通常直接从缓存返回结果，不再请求权威DNS。

举个场景：A记录指向 1.1.1.1，TTL=600。某个递归DNS在10:00:00查到这个结果，那么10:00:00到10:10:00之间，它给用户返回的基本都是 1.1.1.1。哪怕10:02你在DNS控制台把记录改成 2.2.2.2，这批缓存也不会立刻消失。

这里补充一点，TTL控制的是“缓存多久”，不是“全球多久生效”。有些递归DNS会尊重TTL，有些会设置最小缓存时间，有些客户端也有自己的缓存策略。所以把TTL设成1秒，不代表全网1秒切完。

TTL设太低，最先踩到的是查询压力

很多人为了快速切换，把TTL设成1秒、5秒、10秒。控制台上看起来很灵活，但线上流量一上来，权威DNS查询量会明显增加。

假设一个域名每天有100万次访问，不同用户分散在大量递归DNS后面。TTL=600时，同一个递归DNS在10分钟内可能只查一次权威DNS；TTL=10时，同样的递归DNS可能每10秒就要查一次。用户量越分散、访问越连续，这个差距越明显。

简单按单个递归节点算：TTL=600，每小时最多约6次权威查询；TTL=60，每小时约60次；TTL=10，每小时约360次；TTL=1，每小时理论上3600次。真实环境会因为访问间隔、缓存命中、递归DNS行为而变化，但方向不会变。

如果权威DNS服务质量一般，或者DNS套餐本身有QPS限制，TTL过低会把问题放大。平时没事，活动流量一来，DNS响应变慢，用户端表现就是首包慢、偶发解析失败、某些地区打不开。

TTL太低并不会带来真正的“秒级切换”

这点在线上经常被误解。TTL设成5秒，业务故障后把A记录改到新IP，并不代表5秒后全部用户都访问新IP。

常见卡点有这些：递归DNS不完全按TTL执行；运营商Local DNS有自己的缓存策略；浏览器、OS、App SDK可能缓存DNS；移动网络下还有NAT网关、代理、HTTPDNS等链路；如果前面套了CDN，用户实际命中的可能是CDN调度系统，不是你的源站A记录。

实际迁移中见过这样的情况：TTL已经提前一天降到60秒，切换后大多数流量5分钟内过来，但仍有少量地区半小时后还在访问老IP。这个比例可能不高，比如0.5%到2%，但如果老IP直接下线，这部分用户就是失败请求。

所以TTL低只能提高切换速度的概率，不能当成强一致切换工具。涉及支付、登录、游戏网关、API入口，切换时老IP最好保留一段观察期，不要改完DNS就立刻释放机器。

TTL太低会让负载调度变得更“碎”

如果DNS后面做了多IP解析，比如根据地区返回不同线路，或者用多个A记录做简单轮询，TTL太低会让递归DNS更频繁地拿新结果。

这听上去像好事，实际不一定。某些递归DNS请求量很大，它一旦缓存到某个结果，背后可能是一大批用户都打到同一组IP。TTL过低时，缓存不断刷新，调度结果波动更明显，某台机器可能在短时间内流量上上下下。

尤其是游戏、直播、下载、长连接业务，DNS变化太频繁没什么收益。用户建立连接后，后续流量走的是已连接IP，不会因为DNS变了就自动迁到新IP。TTL设很低，只是增加了解析层面的不稳定感，并不能让已建立连接平滑漂移。

TTL太低还会影响排障判断

排障时经常需要判断：用户到底解析到了哪个IP？哪个地区的Local DNS返回了旧记录？权威DNS是否正常？

TTL过低时，结果变化太快。你用 dig 查一次是A机房，过10秒再查可能是B机房；用户截图里是旧IP，你本地已经是新IP；监控点之间结果不一致。排障人员容易把DNS缓存、线路调度、源站故障混在一起看。

多说一句，TTL低不是不能用，而是要知道它会增加系统动态性。动态性越强，监控和日志就要跟上。至少要能看到权威DNS QPS、各地区解析结果、源站访问日志里的Host和来源地区。

TTL设太高，最大的问题是故障切换慢

TTL设成3600、7200、86400，在访问稳定、IP长期不变的业务里很常见。优点是缓存命中高，权威DNS压力小，用户解析延迟低。但遇到故障时就很难受。

比如A记录TTL=86400，也就是24小时。上午10点源站IP被DDoS打黑洞，或者机房网络故障，需要切到备用IP。你在10:05改了DNS，但很多递归DNS手里还有旧缓存，可能要到当天晚些时候甚至第二天才陆续过期。

这类场景下，控制台显示“已修改”不等于用户侧已经修改。客服、运维、业务方看到的现象会很割裂：一部分用户恢复了，一部分用户还在报错；换个网络能打开，原网络打不开；手机流量正常，家宽不正常。

迁移服务器时，TTL太高会把窗口拖长

服务器迁移是最容易被TTL坑到的场景。比如业务从美国普通线路迁到香港优化回国线路，或者从单台云服务器迁到BGP节点。DNS记录如果一直是TTL=3600或更高，迁移当天会出现新老IP并存很久。

这里比较稳的做法是提前降低TTL，而不是切换当天才降。比如原TTL=3600，计划第二天晚上迁移，那么至少提前一天把TTL降到300或120。等旧缓存自然过期后，再执行IP切换。切完后观察日志，确认老IP访问量下降到可接受范围，再考虑把TTL调回600或1800。

实际使用中发现，很多事故不是切换动作错了，而是“提前降TTL”漏了。等到晚上变更时才发现，用户还在拿旧解析，数据库也切了，源站也关了，回滚又不干净。

DDoS和高防切换时，TTL高会让清洗入口生效变慢

高防业务里，DNS TTL尤其敏感。没有接入高防前，域名可能直接指向源站IP；被打后临时把域名切到高防IP。如果TTL=3600，攻击流量和正常用户都会有一段时间继续打源站。

更麻烦的是，攻击者不一定等DNS更新。他们可能已经拿到了源站IP，继续直接打源站。这时DNS切高防只能解决正常用户入口问题，源站暴露问题还要靠安全组、ACL、回源白名单、隐藏源站、BGP高防清洗等手段处理。

如果业务本身容易被DDoS盯上，比如游戏、棋牌、活动站、API服务，前期就应该把架构想清楚。需要香港优化回国、高防服务器、G口大带宽或者海外节点时，可以看看129云这类云服务商的产品线，像中国香港云服务器适合优化回国访问，日本BGP-C型适合亚洲业务接入，美国活动机适合轻量海外部署。购买前可以把业务地区、带宽峰值、防御需求讲清楚，客服热线400-9177118，至少别等被打了才临时找入口。

TTL太高还会影响灰度和回滚

有些业务会用DNS做灰度，比如先把少量地区解析到新机房，观察错误率、延迟、5xx，再逐步扩大。TTL太高时，灰度节奏会被拉长。

比如TTL=1800，半小时一轮缓存。你在10:00把部分解析切到新IP，10:05发现新版本有问题，马上改回旧IP。已经拿到新IP的递归DNS，还可能继续把用户导到新IP，直到缓存过期。业务层面看就是“已经回滚了，但错误还在慢慢掉”。

这也是为什么很多发布系统不喜欢完全依赖DNS做精细灰度。DNS适合做粗粒度入口切换，不适合做请求级、用户级的精确控制。真要精细，通常还是靠LB、Gateway、Service Mesh、应用层路由、CDN规则。

常见TTL取值和适用场景

TTL=1到10秒：适合短时间应急测试，不建议长期用于核心业务。权威DNS压力大，递归DNS不一定完全尊重，排障也容易混乱。

TTL=30到60秒：适合变更窗口、故障演练、迁移前准备、需要快速切换的入口。不要长期无脑保持，除非DNS服务能力和监控都能撑住。

TTL=120到300秒：线上比较常见的折中值。大多数业务变更能在几分钟内逐步生效，查询压力也不会太夸张。API入口、Web站点、普通业务域名经常用这个区间。

TTL=600到1800秒：适合IP相对稳定、变更不频繁的业务。解析缓存命中更高，用户侧DNS查询延迟更少。企业官网、后台系统、稳定CDN CNAME可以考虑。

TTL=3600秒以上：适合长期不变的记录，比如某些验证记录、低频访问域名、内部固定解析。用于公网核心入口时要谨慎，后续迁移和故障切换会比较慢。

A记录、CNAME、NS记录的TTL感受不一样

A记录和AAAA记录最直观，改IP时TTL影响最大。CNAME也会受TTL影响，而且链路上每一层都可能有缓存。比如 www.example.com CNAME 到 cdn.example.net，用户解析时既要看你的CNAME TTL，也要看CDN侧返回记录的TTL。

NS记录更要小心。更换权威DNS服务商时，如果NS TTL很高，全球递归DNS切到新权威的速度会很慢。迁移DNS服务商前，建议提前几天检查NS TTL和父区记录状态，不要只改控制台里的A记录。

TXT记录看起来不影响访问，但做SSL验证、邮件SPF、DKIM、DMARC时也会被TTL影响。比如证书签发验证失败，有时不是TXT没加，而是递归DNS还没拿到新值。

变更前降TTL，切换后别急着升

比较稳的节奏是：变更前把TTL从较高值降到300或120，等待至少一个旧TTL周期；执行DNS切换；观察新老IP流量、错误率、延迟；确认没有明显旧解析流量后，再把TTL调整到日常值。

比如原来TTL=3600，晚上22:00迁移。可以在当天上午或前一天把TTL降到300。到了22:00，大多数递归DNS手里的旧3600缓存已经过期，后面切换就会快很多。切完不要23:00立刻关老机，至少看一段访问日志。对用户分布复杂的业务，老IP保留到第二天更稳。

日志里可以重点看这些字段：源站IP访问量是否下降，旧IP是否还有请求，5xx是否升高，主要地区RTT是否异常，CDN回源是否命中新IP，健康检查是否稳定。

TTL不是高可用方案，健康检查也不是万能

很多DNS服务支持健康检查，检测到某个IP不可用后自动摘除。这个能力有用，但不要把它想成LB级别的实时切换。

原因还是缓存。权威DNS发现IP挂了，可以不再返回这个IP，但已经缓存旧结果的递归DNS不会立刻清空。TTL=300时，影响可能持续几分钟；TTL=1800时，可能持续半小时左右。

另外，健康检查本身也有误判风险。探测点到源站失败，不代表所有用户都失败；源站业务端口正常，也不代表登录、支付、数据库链路正常。DNS健康检查更适合摘除明显不可达的节点，业务级故障还需要应用监控参与。

海外业务里，TTL和线路质量要一起看

海外云服务器场景中，TTL经常和线路调度绑在一起。比如面向中国大陆用户，香港优化回国、CN2、BGP、GIA这些线路差异很明显。TTL设得再漂亮，如果线路本身绕路、丢包、晚高峰抖动，用户体验还是差。

比如同样是300秒TTL，一个域名解析到普通美国线路，另一个解析到香港优化回国线路，国内用户访问延迟可能差出100ms到200ms以上。游戏业务更敏感，TCP重传和抖动会直接体现在卡顿、掉线、登录慢。

所以在购买服务器或规划入口时，不只是问“TTL设多少”。还要看用户在哪里、源站在哪里、是否需要BGP多线、是否要高防、是否要大带宽、是否需要仅计费上行流量。像129云的中国香港产品有30Mbps带宽、200G到4TB流量档位，并且强调优化回国，适合中小型站点、游戏入口、企业业务先做海外接入测试。

比较容易出问题的配置组合

TTL=86400，源站单IP，未接CDN，未接高防。这种配置平时省心，出事时最难切。IP被封、机房故障、DDoS黑洞，DNS修改后还会有大量用户继续访问旧IP。

TTL=5，多A记录轮询，后端机器性能不均。递归DNS频繁刷新，某些时间段流量分布会抖，弱机器更容易被打满。表面看是应用不稳定，根上可能是入口调度太跳。

TTL=60，DNS服务商质量一般，权威DNS跨境访问慢。用户侧递归DNS频繁回源查询权威DNS，解析延迟被放大。尤其是海外权威DNS对国内网络质量差时，解析耗时可能从几十毫秒变成几百毫秒。

TTL=300，切换后立刻释放旧IP。看起来TTL不高，但仍可能有少量旧缓存。旧IP如果被别人拿走，用户可能访问到陌生服务；如果旧IP关闭，用户就是连接失败。云服务器释放IP前，最好确认旧IP访问日志已经基本没流量。

日常建议的TTL设置方式

核心公网入口，日常可以放在300到600秒。这个区间在灵活性和缓存命中之间比较好处理，变更时也不会拖太久。

发布、迁移、演练前，把TTL提前降到60到120秒。注意是提前，不是切换时才改。旧TTL是多少，就至少等一个旧TTL周期，最好再多留一点余量。

稳定不变的验证类记录，可以设1800到3600秒。比如部分TXT验证、低频子域名，不需要频繁变动，TTL没必要压得太低。

高防、容灾、多机房入口，不建议长期使用超高TTL。即使有DNS健康检查，也要给故障切换留空间。一般会配合CDN、Anycast、BGP高防、LB健康检查一起做，而不是只靠改A记录救火。

排查TTL问题时可以这样看

用 dig 看权威DNS返回：dig @权威DNS example.com A。这个结果代表权威侧当前配置。

再看公共递归DNS：dig @8.8.8.8 example.com A、dig @1.1.1.1 example.com A、dig @223.5.5.5 example.com A。不同递归DNS返回不一致时，多半是缓存周期不同。

注意看ANSWER里的TTL剩余值。比如返回TTL=240，说明这个递归DNS缓存还剩240秒。等它归零后，才会重新到权威DNS查询。

如果用户说访问异常，让用户提供本地 nslookup 或 dig 结果，同时带上网络环境，比如电信、联通、移动、教育网、海外运营商。只看自己办公室网络，很容易误判全网状态。

浏览器和系统缓存也要清。Windows可以 ipconfig /flushdns，macOS可以用 dscacheutil -flushcache 配合 killall -HUP mDNSResponder，不同版本命令略有差异。Chrome里也有自己的DNS缓存页面。App内置HTTPDNS的话，还要看App侧缓存策略。

真正要避免的是把TTL当开关用

TTL适合控制DNS缓存时间，不适合承担实时开关职责。需要秒级切流量，应该放到更靠近业务入口的位置，比如SLB、Nginx、Envoy、CDN规则、Global Traffic Manager、Anycast BGP。

DNS可以做大方向调度：哪个地区去哪个机房，哪个域名指向哪个入口，故障时把明显不可用节点摘掉。但要接受它的缓存特性。只要递归DNS和客户端缓存存在，DNS变更就一定会有传播过程。

线上配置时，TTL别只看控制台默认值。域名入口、CNAME链路、CDN、源站、高防、备用机房都要一起看。特别是业务准备迁移到香港、日本、美国这类海外节点时，提前把TTL、线路、回源、安全组、老IP保留时间一起排好，后面变更会少很多临时操作。