内容已经在源站改好，访问时却仍看到旧页面，问题往往不在“更新速度”，而在 cdn 是否按预期回源和缓存。排查时先确认请求去了哪里、节点依据什么决定缓存，再检查过期时间与刷新范围，比反复清缓存更容易定位原因。
先分清：浏览器旧缓存，还是节点旧缓存
同一地址的旧内容可能来自浏览器，也可能来自 cdn 节点，或是源站本身仍返回旧数据。只凭页面看起来没变，无法判断是哪一层。
- 在浏览器开发者工具的网络面板中查看目标请求，确认请求地址、状态码和响应头。
- 留意 Cache-Control、Age 等响应头；Age 若存在，通常可用于判断响应在共享缓存中已存放多久。X-Cache 等字段是否提供、具体含义如何，要看服务商实现。
- 用不同网络或设备重复访问，并与源站响应对照。若源站也是旧内容，应先查应用发布和源站缓存；若仅经 cdn 访问时异常，再检查节点规则。
头部信息只能提供线索：有些服务会改写响应头，某些缓存状态字段也并非统一标准。因此，应将响应结果与控制台中的命中、回源记录一起核对。
容易拖慢更新的四种配置误区
1. 回源规则没有覆盖实际请求
回源规则决定请求未命中或缓存过期时，cdn 如何联系源站。常见疏漏是只给某类文件设置了规则，却忽略不带扩展名的页面、不同子路径，或把更宽泛的规则放在优先级较高的位置。先核对规则匹配条件、顺序，以及实际请求使用的主机名和路径。
2. 缓存键把请求分成了多份
缓存键用于区分哪些请求可共用一份缓存。若把无关查询参数也纳入缓存键，带有不同跟踪参数的同一页面可能各自缓存，刷新其中一个地址不一定覆盖其他变体。反过来，若响应确实随语言、设备或查询参数变化，却把这些差异从缓存键中排除，用户可能拿到不匹配的内容。调整前要先确认源站是否会根据这些字段返回不同结果。
3. TTL 与源站响应头互相冲突
TTL 是缓存存活时间。源站的 Cache-Control 可能要求不缓存或规定有效期，而 cdn 也可能另设缓存时长；最终采用哪项规则，取决于服务商的优先级设置。不要只看控制台填写的数字：还要检查源站是否返回 no-store、private 等指令，以及 cdn 是否配置了覆盖策略。登录后才变化的账户页、购物车等个性化响应，通常不应与公开静态内容使用相同缓存策略。
4. 刷新只做了部分，或预期过高
缓存刷新可以让节点重新获取内容，但按单个 URL 刷新、按目录刷新和清空全部缓存，影响范围并不相同。即使刷新成功，浏览器本地缓存、应用自身缓存或其他代理仍可能保留旧内容。大范围清除还可能增加回源请求，操作前应确认目标地址、规则范围和源站承载能力。
按这个顺序排查并验证
- 固定一个复现地址：记录完整 URL、请求方法、状态码，以及影响问题的查询参数或请求头。
- 检查回源规则：在 cdn 控制台确认匹配的规则、优先级、源站地址和缓存策略，避免只检查默认配置。
- 核对源站响应：查看该地址的响应内容与 Cache-Control 等头部，确认源站是否已经提供新版本。
- 检查缓存键与 TTL：确认哪些参数、请求头或 Cookie 参与区分，并核对实际生效的过期时间，而非只看配置界面中的预设值。
- 小范围刷新后复测：优先刷新准确的 URL，再从不同网络检查响应；若仍旧，查看回源记录与错误状态，不要连续扩大清除范围。
静态文件如果采用带版本号的文件名或路径，发布新内容时让页面引用新地址，通常比反复刷新旧地址更容易区分版本；但页面本身仍需设置合适的缓存时间。对频繁变化的接口响应，则应谨慎配置缓存，并明确哪些请求可以共享结果。
常见问题
刷新后为什么仍看到旧内容？
可能是浏览器缓存、另一条缓存规则、不同缓存键变体，或源站仍返回旧响应。先确认实际请求和响应头，再查刷新范围。
TTL 越短，更新一定越快吗？
不一定。较短 TTL 会让节点更频繁检查源站，但不能解决规则未匹配、缓存键不一致或源站数据未更新的问题。
可以直接关闭 cdn 缓存吗？
可以作为短时排错手段，但长期关闭可能增加源站请求。是否适合，要看内容变化频率、源站能力和响应是否个性化。
要减少更新延迟，关键不是盲目缩短 TTL，而是让 cdn 的回源规则、缓存键和刷新范围与实际请求一致。排查从一条具体 URL 开始，确认源站响应后再调整，通常更稳妥。
