明明已经在CDN控制台切换了节点、刷新了缓存、替换了文件，但访问站点时却仍然看到旧内容，似乎CDN并没有生效。在这个情况下，很多人第一反应是DNS缓存没有刷新导致的，于是执行各种清理命令、刷新浏览器缓存、修改DNS服务器，却仍然无法马上看到更新后的内容。要理解这种困惑的根源，需要同时明白CDN的工作原理、DNS的解析机制、浏览器缓存策略以及不同区域的节点同步速度。

　　CDN切换节点后继续看到旧内容，确实可能与 DNS 缓存有关，但更多情况下并不是 DNS 问题，而是 CDN 各层缓存未同步、回源策略未更新、浏览器本地缓存残留、节点切换延迟等原因。要彻底解决这个问题，需要逐层排查 CDN 的缓存链路，并理解哪些环节可能导致旧内容被保留。要判断是否属于 DNS 缓存引起，可以先了解 DNS 在 CDN 中承担的角色。绝大多数 CDN 平台使用 CNAME 将你的域名指向 CDN 的接入点，例如：

www.example.com   CNAME   xxx.cdnprovider.net

　　当用户访问网站时，DNS 会解析到 CDN 的调度地址，也就是最近的节点 IP。然而 CDN 内部的节点指向通常是由 CDN 平台通过智能调度自动完成的，而不是通过 DNS 更改节点指向。因此，即便你在 CDN 平台切换了节点，DNS 返回的依然只是 CDN 的入口，而不是具体节点本身。换句话说，DNS 负责的是“把用户带进 CDN 网络”，而 CDN 内部到底将用户分配到哪个节点，是由 CDN 的负载系统决定的，而不是 DNS 的记录。因此，当你切换 CDN 节点后看到旧内容时，多数情况下并不是 DNS 缓存未刷新导致的，因为 DNS 并不控制节点切换的细节。

　　要理解 CDN 显示旧内容的真正原因，应先认识 CDN 的缓存层级。CDN 一般存在四层缓存来源：浏览器缓存、本地节点缓存、区域中心节点缓存、以及 CDN 的源站缓存策略。在浏览器端，缓存策略受 Cache-Control、ETag、Last-Modified 等头部的影响，即便 CDN 节点缓存已更新，如果浏览器仍在使用强缓存或协商缓存，也可能继续呈现旧内容。很多站点由于未设置正确的响应头，会让浏览器长期保留旧版本，导致访问体验不一致。

　　在 CDN 节点层面，即便你“切换节点”，不同地区的节点之间的缓存同步并不是实时的。大多数 CDN 的缓存更新是按区域独立处理的，当一个区域的节点已经清除缓存，另一个区域可能仍保留旧缓存，尤其是在更偏远网络区域。如果用户通过运营商、浏览器、DoH、代理、企业网关等方式访问，可能被调度到不同节点，而这些节点的缓存状态不一定一致。

　　另一个常见原因是 CDN 平台中的缓存刷新并不是立即生效。即便平台提示“刷新成功”，实际上仍需要几分钟至十几分钟才能完全推进到所有节点。特别是当缓存对象较大、节点数量庞大、跨地域缓存策略不同步时，清理速度会明显延迟。对一些低频节点来说，清理时间甚至可能更长。当你切换节点后发现仍看到旧内容，很可能就是 CDN 刷新未在所有节点完成。

　　回源策略也可能造成旧内容持续存在。如果 CDN 的设置中启用了“回源缓存”，或 CDN 回源策略设置为“根据源站内容不过期”，那么即便节点缓存被清理，CDN 仍然可能根据源站设定的缓存头部重新缓存旧内容。许多站点在源站 Nginx 中设置的头部类似：

add_header Cache-Control "public, max-age=86400";

　　这会让 CDN 重新拉取后继续缓存 24 小时，导致你即使更换节点，也无法立即看到新内容。

　　有时候，CDN 的智能调度机制会因为网络偏好、运营商分流、TCP 会话重用、历史访问记录等因素，让你持续留在旧节点上。比如你刚访问过旧节点，该节点仍然有你活跃的 TCP 或 TLS 会话，浏览器可能会继续复用该连接，因此你即便“切换节点”，访问的仍然是旧节点的内容。要避免会话复用，可以尝试在浏览器无痕模式、不同设备、不同网络条件下访问，看是否仍出现旧内容。

　　还有一个容易被忽视的原因是 CDN 会根据用户请求携带的头部或查询参数判定缓存是否命中。例如你的某次访问可能携带了 Cookie、登录状态或参数，这些内容可能会导致 CDN 判定请求为“不可缓存”，从而绕过节点缓存直接回源，获得旧版本数据。或者部分节点由于缓存 Key 设置不一致，导致同一资源的不同变体被缓存，最终呈现旧内容。

　　综上所述，CDN 切换节点后仍访问旧内容并不一定是 DNS 缓存的问题。因为 DNS 只负责引导用户进入 CDN 网络，而不会控制 CDN 使用哪个节点、也不会决定该节点缓存了什么内容。真正导致旧内容的因素主要集中在 CDN 自身的缓存体系、浏览器缓存、回源策略、节点同步时间以及连接复用机制。要判断是否是 DNS 问题，可以执行以下命令，它们能帮助你查看 DNS 是否仍然返回旧入口地址：

　　Windows 系统：

ipconfig /flushdns
nslookup www.example.com

　　macOS 系统：

sudo killall -HUP mDNSResponder
dig www.example.com

　　如果解析结果与 CDN 提供的 CNAME 相符，并没有指向旧服务器 IP，那么问题就不是 DNS 缓存。例如：

www.example.com.  CNAME  xxx.cdnprovider.net

　　此结果证明 DNS 是正常的，访问旧内容必然来自 CDN 或浏览器缓存层，而不是 DNS 本身。

　　要让 CDN 切换节点后马上显示新内容，可以采取以下方法：在 CDN 后台执行“强制刷新缓存”而不是普通刷新；关闭浏览器缓存或使用无痕模式访问；针对关键资源设置不缓存或短缓存；确保源站响应头不会让 CDN 缓存旧内容；使用 curl 强制跳过缓存访问源站验证内容是否已更新；更换网络环境测试不同区域节点是否同步；通过 curl 指定 HOST 强制直连源站确认源站是否提供了新版本。例如：

curl -H "Host: www.example.com" http://源站IP

　　如果源站内容仍然是旧版本，那么 CDN 显示旧内容就是正常的，因为 CDN 只是缓存了源站提供的内容。

　　许多时候开发者误以为 CDN 内容没刷新，但其实源站中的内容也没有更新成功。只有源站返回正确内容、缓存策略合理、节点同步正常时，CDN 才能稳定地呈现最新内容。

　　在整个排查过程中，一个重要的原则是不要依赖单一设备进行测试。不同网络、不同区域、不同浏览器、使用命令行工具(curl/wget)、切换 DNS 服务器测试，都能帮助判断问题到底发生在哪一层。只要逐一排查 CDN 缓存链路，就能准确定位是否是 DNS 问题，还是 CDN 节点本身的缓存未更新。