建站的人几乎都遇到过这种局面：源站文件改了，后台也清了缓存，甚至刷新了CDN，但打开页面一看，还是旧的那张图、旧的那段文案。这时候去查DNS，解析明明是对的，IP指向也没问题。于是开始怀疑CDN没生效，或者怀疑自己改错了地方。实际上，问题大概率出在一个被两个不同系统共用、但含义完全不同的参数上：TTL。

　　DNS里有一个TTL，CDN配置里也有一个TTL。它们在管理面板上长得差不多，单位都是秒，填错了似乎也能保存成功。但这两个数字管的是完全不同层面的事。把它们当成同一个东西来调，就会出现“改了DNS TTL，CDN缓存没动”或者“调了CDN TTL，域名解析却迟迟不切”的困惑。

　　一个管“去哪儿找”，一个管“要不要去拿”

　　DNS TTL控制的是域名解析结果的缓存时间。当用户访问一个域名时，递归DNS服务器需要把域名翻译成IP地址。这个翻译结果会被缓存一段时间，缓存时长就是DNS TTL。在这段时间内，所有用户查询同一个域名，递归DNS都直接返回缓存里的IP，不会再去问权威服务器。

　　CDN TTL控制的则是边缘节点上缓存的内容文件的有效期。用户访问一个静态资源(图片、CSS、JS、视频分片)，CDN边缘节点如果缓存过这个文件，就直接返回;如果没缓存或者缓存过期了，才回源站去拉取。这个“缓存多久算过期”的时间，就是CDN TTL。

　　用一个具体的场景来区分。假设你的域名解析TTL是3600秒，CDN上某个图片的缓存TTL也是3600秒。你在源站替换了那张图片。第一个小时里，用户访问你的域名，DNS返回的是CDN节点的IP(因为解析缓存还没过期)，请求确实到了CDN。但CDN节点上那张图片的缓存也没过期，它直接返回了旧图。用户看到的是旧内容。DNS TTL决定了用户能不能找到CDN，CDN TTL决定了CDN愿不愿意去拿新东西。 两件事在同一个小时窗口里同时发生，但故障点只有一个：CDN TTL没到，旧图没被淘汰。

　　反过来，如果你换了源站服务器的IP，但CDN配置没动。DNS TTL到期后，用户被引导到新的IP，访问恢复正常。这个过程中CDN TTL完全不参与，因为它管的是“缓存的文件”，不是“服务器的地址”。

　　为什么这两个TTL不能互相替代

　　一个常见的误解是：把DNS TTL调短，CDN缓存就会跟着快速更新。这是错的。DNS TTL缩短只让解析结果更快刷新，让用户的请求更快到达(可能已经变更的)CDN节点IP。但请求到达CDN之后，节点上缓存的旧文件依然按照CDN TTL的节奏存活。你改DNS，改不到CDN节点上的缓存文件。

　　反过来也一样。你把CDN TTL设成60秒，强迫边缘节点频繁回源检查文件是否更新。但用户的DNS解析如果还缓存着旧IP(指向一个已经下线的旧CDN节点或者旧源站)，这些请求根本到不了那个频繁检查的节点。解析层没放行，内容层再怎么勤快也没用。

　　两者的生效范围也完全不同。DNS TTL的影响范围是全球的递归DNS服务器，你改一个值，各地递归缓存的过期时间各不相同，传播速度取决于它们各自什么时候缓存过你的记录。CDN TTL的影响范围是CDN服务商的边缘节点集群，你改一个值，该集群内所有节点对这个资源的缓存策略同时变更。前者是分布式的、去中心化的，后者是集中式管理的。用管理CDN的直觉去管DNS，或者反过来，都会出问题。

　　实操中怎么调，才不会互相打架

　　理解了分工之后，配置策略就清楚了。关键是让两个TTL服务于不同的目标，而不是试图用一个去覆盖另一个。

　　DNS TTL服务于“变地址”的需求。 当你计划迁移服务器、切换CDN服务商、或者调整回源IP时，提前把DNS TTL降下来(比如300秒)，等旧缓存过期后再执行变更，这样新IP能在几分钟内扩散。变更稳定后，把TTL调回一个较高的值(比如3600或86400)，减少解析查询压力。这是DNS TTL的标准用法，跟CDN缓存没有直接关系。

　　CDN TTL服务于“变内容”的需求。 静态资源(图片、字体、版本化的JS/CSS)可以设长，比如几天甚至几个月，因为它们文件名里通常带版本号或哈希，内容变了文件名也变，不存在“旧缓存返回旧内容”的问题。频繁变动的资源(API响应、HTML页面、未版本化的脚本)设短，比如几分钟到一小时，让节点有机会回源拿到新版本。

　　真正需要协调的场景只有一个：你既换了源站地址，又更新了源站上的文件内容。 这时候两套缓存同时存在旧数据，你得分别处理。先确认DNS TTL已经过期、解析指向了新地址，再确认CDN TTL已到期或者手动刷新了缓存。手动刷新CDN缓存是绕过CDN TTL的最直接手段，它不需要等TTL自然过期，强制节点丢弃旧文件回源拉新。但手动刷新解决不了DNS层面的问题，如果解析还指着旧IP，刷得再勤也是白费。

　　还有一个容易被忽略的细节：CDN TTL的实际值可能由源站的HTTP响应头决定，而不是你在CDN控制台填的那个数字。 源站返回的Cache-Control里的max-age，或者Expires头，会被CDN读取并作为缓存时长的依据。CDN控制台里的TTL设置通常是一个“默认值”或“覆盖值”，具体哪个优先取决于CDN服务商的规则。也就是说，你改CDN控制台的TTL，源站如果发了一个不同的Cache-Control，实际生效的可能不是你以为的那个数。排查CDN缓存不更新时，先看一眼源站响应头，比盯着CDN面板有用。

　　常见问答

　　问：我改了CDN的TTL，为什么DNS解析还是旧IP?

　　答：因为CDN TTL和DNS TTL是两套独立参数。改CDN TTL不会影响递归DNS服务器上缓存的解析记录。DNS解析的刷新只取决于DNS TTL和递归服务器的缓存策略。要改解析生效速度，需要去DNS管理面板调整对应记录的TTL，并等待旧缓存过期。

　　问：源站文件更新了，DNS也生效了，CDN还是返回旧内容，只调DNS TTL有用吗?

　　答：没用。DNS生效只说明用户的请求到达了CDN节点，但节点上缓存的旧文件如果CDN TTL没到期，它不会回源去取新文件。这时候需要做的是刷新CDN缓存，或者等CDN TTL过期。调DNS TTL改变不了CDN节点上已经缓存的内容。

　　问：CDN控制台里设了TTL，为什么实际缓存时间不一样?

　　答：检查源站返回的HTTP响应头。CDN通常会读取源站的Cache-Control或Expires头来决定缓存时长。如果源站返回了max-age，它可能覆盖或影响你在CDN控制台设置的TTL值。具体哪个优先取决于CDN服务商的实现规则，排查时以实际响应头为准。

　　问：静态资源和动态页面的CDN TTL应该设成一样吗?

　　答：不应该。静态资源(带版本号或哈希的图片、JS、CSS)可以设得很长，因为它们的内容变更通常伴随文件名变更，不存在旧缓存问题。动态页面或频繁更新的内容设短一些，让节点有机会及时回源获取新版本。把两者混为一谈，要么导致静态资源频繁回源浪费带宽，要么导致动态内容更新滞后。

　　问：有没有办法让CDN缓存立刻失效，不用等TTL?

　　答：有，手动刷新CDN缓存。大多数CDN服务商提供缓存刷新功能，提交URL或目录后，边缘节点会丢弃对应的旧缓存，下次请求时回源拉取最新内容。这是绕过CDN TTL等待期的标准操作。但刷新操作有频率限制，而且刷新后第一次访问会回源，响应速度可能比平时慢一些，因为缓存需要重新建立。