域名解析TTL值怎么调？平衡生效速度与DNS查询压力的技巧

　　TTL这东西，你在域名解析后台每天都能看见——那个默认填着600、写着“秒”的小框。大多数人的做法是：看到默认值，懒得动，就直接保存了。也有一些人，性子急，改成60；或者求稳，改成86400。说实话，没几个拍着胸脯说“我这是深思熟虑过的”。

　　TTL这事儿吧，说大不大，说小不小。调对了没人夸你，调错了遇到故障想切IP的时候，你就知道什么叫“度秒如年”了。

　　TTL，全称Time To Live，在域名解析这个场景下，它指的是DNS记录在本地DNS服务器(也就是你的运营商DNS、公共DNS，比如114.114.114.114或者8.8.8.8)上的缓存时间。

　　打个比方，你把www.example.com的A记录指向了1.2.3.4，TTL设成3600秒。有个用户访问你的网站，他用的本地DNS解析器拿到1.2.3.4这个结果之后，不会马上丢掉，而是在缓存里存一个小时。这一个小时内，再有其他用户(或者同一个用户再次访问)来问www.example.com的IP是多少，本地DNS直接掏出缓存里的结果扔回去，根本不会再来查你权威DNS一次。

　　所以TTL的核心作用就两条：一是控制DNS解析的生效速度(改记录后多久能全局生效)，二是控制权威DNS服务器的查询压力(缓存越久，查的次数越少)。

　　这两条天然是矛盾的。想生效快，TTL就得短；想减轻DNS压力，TTL就得长。所谓调TTL，本质上就是在找这两者之间的那个平衡点。

　　缓存链里的不同角色，你得心里有数

　　TTL这件事可不是你设多少，所有地方就100%严格执行多少。DNS解析的链路是这样的：

　　用户浏览器 → 操作系统DNS缓存 → 本地递归DNS服务器(运营商/公共DNS)→ 根DNS → 顶级域DNS → 你的权威DNS

　　这里面每一层都可能做缓存。你在权威DNS设的TTL，对本地递归DNS来说是“建议值”，大部分会遵守，但也有些运营商DNS不老实，强制用更长的TTL，不管你怎么设都没用。还有浏览器自己的DNS缓存(Chrome大概缓存60秒左右)，这些你控制不了，心里有数就行。

　　所以我们说的调TTL，影响的是绝大多数守规矩的本地递归DNS，而那些不守规矩的，暂且不谈，也没法谈。

　　场景一：业务相对稳定，没什么大变动

　　如果你的网站服务器IP不常换，CDN也不怎么切，域名解析配置稳定，那TTL完全没必要设得很短。这时候你用短TTL，除了平白增加权威DNS的查询次数、多花点解析费用之外，没有任何好处。

　　这样的场景，TTL设成3600秒(1小时)到86400秒(24小时)都合理。我见过不少人设成600秒(10分钟)，觉得“万一要改呢”，但其实你一年到头也改不了一次，设这么短就是浪费资源。倒不是说10分钟能造成多大损失，就是没有那个必要性。

　　如果业务规模比较大，日活用户上百万，权威DNS的查询量直接影响稳定性和成本，那TTL倾向于设长一点，比如12小时甚至24小时。反正不改配置，缓存越长，对权威DNS越友好。

　　场景二：经常做运维变更，IP来回切

　　有些业务比较灵活，服务器经常扩缩容，新上线的机器IP变了需要切解析，或者A/B测试切流量，这种情况下，你肯定不希望改完解析之后还得等几个小时才能看到效果。

　　这种场景下，提前把TTL调低，是标准操作流程。比如你知道今晚要切IP，提前几个小时甚至一天，先把TTL从3600改成60，等旧的缓存差不多过期了，再动手改A记录。这样改完之后，最多一两分钟，大部分地方就能解析到新IP。

　　千万注意顺序：先调低TTL，等旧缓存过期，再改记录。很多人搞反了，先把IP改了，才想起来TTL没动，结果等了一个小时还没生效，干着急。你改TTL这件事本身，也是要等原TTL过期才能生效的，所以需要提前操作。

　　场景三：接入CDN或切换CDN服务商

　　接入CDN的时候，CDN会给你一个CNAME域名，你要把原来的A记录改成CNAME。这个过程中TTL怎么处理?

　　如果你原来的TTL很长，比如24小时，而你希望接入CDN后能快速看到效果，稳妥做法是：在操作前先把TTL改短(比如300秒)，等24小时之后(原TTL完全过期)，再执行A记录到CNAME的切换。这样万一CDN那边配置出了什么问题，回退也快。不急着这一时半会儿，等原TTL周期走完再做切换，这是行规。

　　如果CDN已经跑了一段时间，业务稳定，TTL可以适当调回一个适中的值，比如600秒或1800秒。CDN场景下，大部分流量经过CDN节点，DNS解析的压力相对分散，TTL设到30分钟到1小时比较常见，既不会在切换时太被动，也不会给DNS服务器增加不必要的负担。

　　TTL调多少合适?给个参考范围

　　没有统一答案，但可以根据业务类型给几个参考区间，你按自己的情况对号入座：

　　60～120秒：适合高频运维场景，比如频繁切流、灰度发布、应急演练。好处是生效极快，坏处是DNS查询量会明显上升，权威DNS压力大，不建议作为常态配置长期使用。

　　300～600秒(5～10分钟)：适合一般的Web业务。出问题能较快切走，DNS压力也在可接受范围内。这是大多数CDN场景下的默认值，算是个“万金油”区间。

　　1800～3600秒(30分钟～1小时)：适合企业官网、SaaS后台这类相对稳定、变更频率低的业务。兼顾了生效速度和缓存效率，多数普通站点用这个区间就足够了。

　　86400秒(24小时)：适合纯静态资源、下载站、不怎么变动的域名，或者对成本敏感的出海业务(海外DNS查询费用高)。但建议配合“变更前手动调低TTL”的流程来用，不然真要改的时候就难受了。

　　实操：改TTL的时候注意这几点

　　第一，改TTL不会立刻生效。 你刚才把TTL从3600改成60，这个改动本身要等原来的3600秒过期之后，各地DNS才会去拉取新的TTL值。所以如果你想“现在把TTL改短，马上就切IP”，这是做不到的，得等。提前一天调TTL，这是基本的运维素养。

　　第二，TTL不是所有记录类型都统一设。 有些解析服务商支持按记录类型分别设置TTL。比如你的A记录可以设成600秒，MX记录可以设成86400秒，TXT验证记录可以设成60秒。没必要一刀切，各个记录按自己的重要性和变更频率单独来。

　　第三，不是所有DNS服务商的TTL都支持任意值。 有些便宜或免费的DNS服务，TTL最低只能设到600秒，不支持60秒，买之前看清规格。另外权威DNS服务商自身的架构也可能影响TTL实际生效的最小时间，超出服务商支持范围的值会被强制改成默认值。

　　第四，改完记录之后，建议把TTL恢复正常，别一直留在短TTL上。 很多人应急的时候把TTL改成60，事情办完了就忘了改回来，结果过了一个月发现权威DNS查询量一直居高不下，每个月多花一笔解析费用。顺手的事儿，别忘。

　　说到底，TTL不是一个“越大越好”或“越小越好”的指标，它是一个策略参数。你对业务变更频率的判断准不准，决定了TTL设得合不合理。变更频繁的业务就接受短TTL带来的DNS压力，业务稳定就享受长TTL带来的缓存红利，就这么简单。最忌讳的是一刀切，不管什么场景都用默认值，也不管业务特点——那样的话，遇到故障你就知道什么叫“看着服务器挂了，解析却切不过去”的绝望了。