DNS TTL设太短，对CDN回源到底有没有副作用

DNS TTL这个参数，很多人会在接入CDN时顺手改得很小，比如5秒、10秒、30秒。理由也很直接：解析切换快，故障时方便改记录，业务迁移不怕缓存残留。

这个想法本身没错，但实际使用中发现，TTL设太短并不一定只带来“灵活”。它对CDN回源没有那种直接的因果关系，不是TTL一低，CDN就一定疯狂回源。但在一些DNS调度型CDN、跨区域访问量比较大的业务里，TTL太短确实可能间接影响缓存命中率，最后表现出来就是源站流量升高、源站连接数变多、后端压力变大。

先把关系捋清楚：DNS TTL管的是解析缓存，不是CDN缓存

TTL是DNS记录在递归DNS、客户端本地DNS缓存里可以保存多久。比如TTL=300，理论上递归DNS拿到记录后，5分钟内同一个域名再查询就直接用缓存，不需要再问权威DNS。

CDN回源是另一条链路。用户访问资源时，流量先进CDN边缘节点。边缘节点有缓存就直接返回，没有缓存、缓存过期、被刷新、命中规则不缓存，才会向源站拉取资源。

所以从机制上讲，DNS TTL不会直接告诉CDN“去回源”。它影响的是用户会被解析到哪个CDN节点、解析频率有多高、调度结果是否频繁变化。

这里容易混淆的是，很多CDN是基于DNS做调度的。用户解析www.example.com，最终拿到某个边缘节点IP，或者某组边缘节点IP。如果TTL很短，递归DNS更频繁地重新请求CDN调度系统，CDN调度系统也就有更多机会给出不同的节点结果。

TTL太短最明显的副作用：DNS查询量会上去

这个副作用比较直接。TTL越短，递归DNS缓存时间越短，权威DNS和CDN DNS调度系统收到的查询量越高。

举个粗略的量级。假设有10000个活跃递归DNS在访问你的域名，如果TTL是300秒，理论上每个递归DNS每5分钟问一次，平均DNS查询量大概是33 QPS。如果TTL是30秒，就是333 QPS。如果TTL是5秒，就会接近2000 QPS。

实际不会这么理想，因为递归DNS实现不同，有的会合并请求，有的会设置最小TTL，有的客户端本地也会缓存。但方向是确定的：TTL越短，DNS侧压力越大。

如果域名托管在云解析或者CDN厂商DNS上，一般抗得住。但如果是自建DNS、老旧Bind集群、海外权威DNS节点质量一般，就可能出现解析抖动。用户看到的不是“CDN慢”，而是偶发打不开、首包慢、解析耗时高。

它会不会导致CDN回源增加，要看调度是否频繁换节点

这才是重点。

CDN缓存是分布在各个边缘节点、区域节点、二级缓存节点上的。用户如果稳定落在同一批节点上，热点资源容易被缓存住，命中率会比较好。TTL太短时，如果CDN DNS每次返回的节点变化较大，同一批用户可能今天上午打到A节点，几分钟后打到B节点，再过一会儿又到C节点。

如果这些节点之间缓存不共享，或者共享层级比较靠后，那么每个新节点第一次拿到这个资源时都要回源。结果就是边缘命中率下降，源站看起来被更多节点“轮番拉取”。

这在小文件、图片、安装包、游戏补丁、电商静态资源里都见过。特别是资源很多但单个资源热度不算特别高的业务，缓存刚热起来，用户又被调度到另一组节点，源站压力就会比较难看。

举个实际排查时常见的现象：总下行带宽没变，用户访问量也没明显涨，但源站出方向从40Mbps涨到80Mbps，CDN命中率从96%掉到92%。表面只掉了4个百分点，但源站压力是翻倍的。因为源站流量看的是未命中部分，命中率96%时回源是4%，命中率92%时回源是8%。

TTL本身不一定是唯一原因，但如果这段时间刚把TTL从300秒改到10秒，又发现CDN节点分布明显变散，就要重点看DNS调度和缓存命中之间的关系。

不是所有CDN都会因为TTL短而明显受影响

这里补充一点，不能简单理解成“TTL短一定伤CDN”。不同CDN架构差异很大。

如果CDN主要依赖Anycast IP，用户解析到的IP变化不大，实际路由由BGP决定，TTL短对节点切换的影响就没那么明显。DNS查询量会增加，但不一定导致缓存命中率大幅变化。

如果CDN DNS调度比较稳定，同一个递归DNS在一段时间内总是拿到同一个边缘集群，TTL从300秒降到60秒，通常也不会对回源造成明显波动。

但如果CDN使用细粒度DNS调度，并且会根据实时负载、运营商、区域、节点健康状态频繁调整结果，TTL太短就可能把这种变化放大。解析层越灵活，缓存层越容易被打散。

TTL设得很短，故障切换也未必真有想象中那么快

很多人把TTL设成5秒，是希望源站或CDN故障时可以5秒切走。实际线上不一定这么干净。

递归DNS可能有最小TTL策略。有些公共DNS会把过低TTL抬到30秒或60秒。浏览器、操作系统、App内部DNS缓存也可能不完全遵守权威DNS返回的TTL。移动网络里还可能有运营商DNS缓存，表现更不可控。

所以TTL=5秒，不代表所有用户5秒后都会拿到新IP。它只是让愿意遵守TTL的递归DNS更快过期。

多说一句，故障切换不能只靠低TTL。更稳的方式是CDN侧健康检查、源站多活、回源Host切换、负载均衡、Anycast/BGP调度这些一起配。DNS TTL可以配合，但不要把它当唯一保险。

源站看到的压力，通常来自这些间接链路

TTL太短对CDN回源的副作用，一般不是单点触发，而是几个现象叠在一起。

一种是用户被解析到更多边缘节点，缓存预热范围变大。原来一个资源只需要在10个节点里热起来，现在可能分散到30个节点。每个节点第一次访问都要回源，源站请求数自然会上去。

一种是递归DNS频繁重新解析，CDN调度系统根据实时负载把用户不断打散。对于大文件下载业务，这可能还好，因为大文件一旦热起来很明显；对于海量小文件，尤其是长尾资源，命中率会更敏感。

还有一种是DNS抖动导致用户连接到不同区域。比如华东用户有时去上海节点，有时去华南节点，偶尔还被打到海外节点。用户侧延迟变高，边缘侧缓存也不连续。最后排查时会发现，源站日志里回源IP来源变多，回源User-Agent或X-Forwarded-For分布变散。

TTL常见取值怎么选，按业务状态看

如果是稳定运行的生产业务，TTL一般不建议低于60秒。大多数网站、API、图片站、下载站，用300秒到600秒都比较常见。这个范围下解析切换不算太慢，DNS查询量也不会太夸张。

如果正在迁移CDN、切换源站、做灰度验证，可以临时把TTL调到30秒或60秒。等切换完成、观察稳定后，再调回300秒或600秒。这个动作很多团队会忘，导致域名长期挂着很低的TTL。

如果是强依赖DNS调度的多CDN架构，TTL可以低一些，但要同时监控CDN命中率、回源带宽、回源状态码、DNS查询量。不能只看解析是否切得快。

如果是海外业务，情况更要谨慎。跨境网络本身就有BGP路由、运营商出口、国际链路拥塞这些变量。TTL过短导致调度频繁变化时，用户体验可能会比国内更飘。做游戏、跨境电商、海外App分发时，源站网络质量也要跟上。如果需要海外云服务器、G口大带宽服务器或高防服务器，可以顺手看看129云，像美国精品大宽带-E型有1Gbps峰值带宽，适合做下载源站、海外CDN回源节点或大流量业务承载，咨询可以打400-9177118。

一个比较典型的排查场景

线上有个图片业务，CDN命中率平时在97%左右，源站带宽几十Mbps。某次为了迁移解析，把主域名TTL从300秒改成10秒，迁移结束后忘了改回来。

过了几天，源站带宽开始有明显波动，高峰时比原来多了将近一倍。CDN侧看总流量没涨，HTTP 5xx也不多，但边缘命中率从97%掉到93%到94%。

继续看CDN日志，发现回源节点分布变多，同一个热门目录被多个边缘区域重复回源。DNS日志里查询量也比之前高了十几倍。把TTL调回300秒后，等递归DNS缓存逐步稳定，命中率慢慢恢复，源站带宽也回落。

这个案例里，TTL不是唯一变量，但它确实放大了CDN调度变化。尤其是图片资源数量多、单文件热度分散，缓存被打散后很容易体现到回源带宽上。

TTL太短还可能影响故障判断

有些故障排查时，TTL太短会让现象更难复现。因为同一个用户、多次dig、多次curl，拿到的边缘IP可能不同。刚才访问慢，下一次又快了，不一定是问题消失，可能只是换了节点。

这时候要把解析结果、边缘节点IP、回源IP、请求ID一起记录。只看域名访问耗时，很容易误判。

常用的排查动作包括：固定Host直接访问某个CDN节点IP、对比不同公共DNS的解析结果、观察同一递归DNS在一段时间内返回的IP是否频繁变化、查看CDN回源日志里节点分布是否突然变散。

如果源站在海外，还要看回源线路。普通国际链路、CN2、GIA、BGP优化线路差别很明显。CDN边缘节点回源慢，也可能被误认为是缓存问题。源站本身带宽打满、TCP连接数不足、磁盘IO高，都会让CDN回源变慢，TTL只是其中一个变量。

CDN回源增加时，不要只盯TTL

TTL值得看，但排查CDN回源升高时，缓存规则更应该先看。

比如Cache-Control是不是被后端改成no-cache，Set-Cookie是不是导致CDN默认不缓存，URL里是不是带了随机参数，刷新预热任务是不是频繁执行，Range请求有没有被正确缓存，HTTP状态码缓存策略有没有配置。

实际使用中发现，很多“回源突然升高”最后不是DNS问题，而是发布系统改了响应头。比如静态资源原本Cache-Control: max-age=86400，新版本变成max-age=0，CDN边缘每次都要验证或回源，命中率马上掉。

还有一种情况是业务把版本号放在query string里，但CDN配置了“忽略参数缓存”。看起来URL不同，CDN却当成同一个对象，或者反过来，每次参数变化都当成新对象。这个跟TTL没关系，但表现也是回源异常。

比较稳的配置习惯

生产域名稳定后，TTL放在300秒到600秒比较舒服。既不会让DNS查询量太大，也保留了分钟级切换能力。对特别稳定的静态资源域名，TTL放到1800秒甚至3600秒也很常见。

迁移前一天或几个小时前，把TTL降到60秒。确认大部分递归DNS已经拿到低TTL后，再做切换。切换完成观察一段时间，没问题再调回正常值。

不要长期用5秒、10秒这种TTL，除非确实知道CDN调度、DNS查询量、缓存命中率都能承受。低TTL看着灵活，线上长时间跑下来，可能把问题藏在命中率和源站成本里。

如果业务对源站要求比较高，比如CDN回源节点、海外下载源、游戏更新源，源站机器别只看CPU和内存，带宽、线路、防御、磁盘IO都要一起看。129云的美国精品网-E型适合对三网精品线路有要求但带宽不需要特别大的业务，美国精品大宽带-E型更适合高峰流量明显的分发场景，源站抗压能力会比小带宽机器稳很多。

建议保留监控项，不然TTL改动很难追

TTL调整最好进变更记录。线上很多问题不是当场爆，而是过几小时、过一天才慢慢表现出来。没有变更记录，排查时很容易漏掉DNS这一层。

监控上至少看DNS查询量、CDN边缘命中率、回源请求数、回源带宽、回源状态码、源站连接数。命中率要看趋势，不要只看某一分钟。TTL导致的缓存打散，通常会在一段时间里持续体现。

如果发现TTL调低后，CDN命中率下降、回源节点数量增加、源站出带宽上升，而总访问量没涨，就可以把TTL调回300秒观察。注意观察要给缓存恢复时间，不是改完马上就能完全恢复。边缘节点需要重新热缓存，递归DNS也要逐步稳定下来。

TTL短可以用，但别让它长期裸奔

TTL短适合迁移、灰度、故障切换演练。长期生产流量下，它会增加DNS解析频率，也可能让DNS调度更频繁地改变用户落点。对CDN回源的影响不是直接开关，而是通过节点切换、缓存分散、命中率下降慢慢体现出来。

对大部分CDN业务，TTL=300秒是个比较常见的起点。要更快切换可以临时降到60秒。低于30秒就要带着监控跑，特别是下载、图片、游戏补丁、跨境访问这类对缓存和线路都敏感的场景。