TTL是Time To Live的缩写，中文一般译作生存时间。在域名解析场景下，它指的是一条DNS记录被查询后，可以在各级缓存服务器中保留的秒数。很多人在域名控制台看到默认的600或者600秒上下的数值时，并不会多想，直到某次更换服务器IP，发现网站半天都打不开，才开始认真研究这个参数。这篇文章就从TTL的工作原理讲起，把设置策略、常见问题和踩坑经验一次说透。
一、先弄懂TTL的工作机制
当你访问一个网站时，操作系统并不会每次都向权威DNS服务器发起查询。整个解析链路大致是这样的：浏览器先查本地缓存，操作系统再查hosts文件和系统缓存，如果都没命中，就会向配置的递归DNS服务器（比如运营商的DNS或者公共的114.114.114.114）发起请求。递归服务器如果缓存中有该记录且未过期，直接返回结果，不会再往上游查询；只有缓存过期后，才会重新向权威服务器获取最新记录。
TTL的作用就体现在这里。权威服务器返回解析记录时，会附带TTL值，递归服务器和操作系统会按照这个时间来缓存记录。假设TTL设置为3600秒，那么递归服务器在接下来的1小时内，对同一个域名的查询都直接返回缓存结果，不管权威端记录有没有变化。这就解释了一个现象：明明在控制台改了解析记录，部分地区用户却还是访问到旧IP，因为他们的递归DNS还拿着没过期的旧缓存。
需要注意一点，TTL并不是精确倒计时。各级缓存对过期时间的处理略有差异，有的会在剩余时间过半时主动刷新，有的会严格到期后再查询，所以实际生效时间通常在一个TTL周期上下浮动。这也是为什么做服务器迁移前，都要提前调低TTL的原因。
二、不同场景下的TTL推荐值
TTL没有一个放之四海而皆准的数值，核心原则是权衡解析灵活性和查询效率。数值越小，记录变更越快生效，但递归服务器需要更频繁地向权威服务器查询，解析整体效率下降；数值越大，查询压力越小，可一旦需要变更，等待时间就很煎熬。
对于长期稳定、不打算迁移的业务，TTL设置在3600秒到86400秒之间比较合适。这类场景下解析记录很少变动，用更长的缓存时间可以提升解析速度，减轻权威服务器压力。比如企业官网、博客站点，一年也难得改一次解析记录，设成86400秒（24小时）完全没问题。
对于即将进行服务器迁移或更换IP的情况，正确做法是提前24到48小时把TTL调低到300秒甚至60秒。等全球递归服务器的旧缓存基本过期后，再执行IP切换，新记录就能在几分钟内大面积生效。迁移完成并确认稳定运行一两天后，再把TTL调回较大的值。
对于使用了CDN、负载均衡或者高可用架构的场景，解析记录本身变动频繁，一般建议TTL保持在60秒到600秒之间。很多CDN服务商的CNAME记录默认TTL就是600秒，如果调度逻辑需要更敏捷，可以配合服务商建议调得更低，但没必要低于60秒，因为大部分递归服务器对极短的TTL有保底处理，低于一定阈值反而失去意义。
三、修改TTL的正确步骤与验证方法
很多新手误以为改TTL和改解析记录是同时生效的，其实顺序很重要。假设当前TTL是86400秒，你今天同时把TTL改成60秒并切换了IP，那么部分递归服务器的旧缓存要最长24小时后才过期，TTL的修改并不会加速旧记录的失效。正确的顺序是：第一步只改TTL，把数值降低；第二步等待至少一个原TTL周期，确保旧的长缓存都过期；第三步再修改IP等记录；第四步确认新记录生效稳定后，把TTL调回正常值。
验证是否生效，可以在Windows下打开命令行执行nslookup -debug www.ippipp.com查看返回记录中的TTL剩余时间，也可以用在线的dig工具查询全球各节点的解析结果对比。如果发现部分地区仍返回旧IP，多半是递归缓存还没过期，耐心等一个TTL周期即可，不需要反复删除重加解析记录，那样反而会把等待时间重新计算一遍。
# 查询域名的解析记录及TTL，dig命令会显示权威服务器返回的TTL值 dig www.ipipp.com A +noall +answer # 输出示例： # www.ipipp.com. 600 IN A 192.0.2.10 # 其中600就是当前记录的TTL（秒） # 指定使用某个公共DNS查询，对比不同递归服务器的缓存结果 dig @8.8.8.8 www.ipipp.com A +short
四、常见问题与误区解答
TTL设置成60秒会不会影响网站速度？基本不会。真正的解析耗时主要发生在缓存未命中的首次查询，后续请求走的是各级缓存，速度差异微乎其微。把TTL设低的主要代价是递归服务器查询频率上升，对普通站长来说完全可以忽略，大型服务商才有必要权衡。
为什么改了解析记录，网站还是打不开？最常见的原因就是旧缓存未过期。此外还要检查本地系统缓存和浏览器缓存，Windows下可以执行ipconfig /flushdns清空本机DNS缓存再试。如果确认全球解析都已生效但仍无法访问，那问题多半出在新服务器本身，比如防火墙未放行端口、Web服务未启动等。
TTL设得越低越好吗？不是。有一个常见误区是觉得TTL越小越灵活，就长期保持在60秒。前面说过，递归服务器通常有最小缓存保底，很多公共DNS对过低的TTL会强制按300秒或更长处理，你设置的60秒未必被尊重。长期低TTL只会白白增加查询量，没有实际收益。
删掉记录重新添加，能加快生效吗？不能，反而可能更慢。删除记录的行为本身也会被缓存（负缓存），部分递归服务器会缓存不存在的结果，重新添加后可能仍需等待。正确做法永远是提前调低TTL，然后按步骤操作。
总结一下：日常业务TTL用3600到86400秒，迁移前提前降到300秒以下，CDN场景保持60到600秒，变更记录前先等旧缓存过期。掌握这个节奏，域名解析的生效问题基本就能做到心中有数了。