cdn 站点目录加速常见缓存失效问题排查方法

本文概述了在使用CDN 站点目录加速时，经常遇到的缓存失效表现、主要成因与可操作的排查流程，帮助快速定位并修复问题以恢复稳定加速效果。

为什么会发生缓存失效？

缓存失效通常由源站响应头（如Cache-Control、Expires）、CDN缓存规则、请求差异（query、cookie、header）或有意清理（Purge）引起。理解这些触发点是排查的第一步。

什么会导致目录加速比文件加速更易失效？

目录加速常涉及索引文件、重定向与尾斜杠差异，且目录请求可能被视为动态（例如返回302或302到index.html），这会使缓存失效概率增加。

哪里可以查看缓存命中和响应头信息？

使用浏览器开发者工具网络面板或命令行curl查看响应头（curl -I）。关注Age、X-Cache、CF-Cache-Status等字段，以及源站的Cache-Control、Vary、Set-Cookie。

哪个配置最容易被忽视导致缓存不命中？

常见被忽视项包括：默认携带Cookie导致回源、Vary: Cookie/Accept-Encoding被误设、URL查询字符串未入缓存键或被当作不缓存标志、以及错误的重写/重定向规则。

怎么通过步骤化检查快速定位问题？

推荐流程：1）用curl或浏览器检查响应头；2）比对带/不带尾斜杠与index.html的差异；3）测试去掉query或cookie后的命中；4）查看CDN控制台日志和边缘节点缓存状态；5）必要时在低峰期Purge并观察变化。

如何判断是CDN配置问题还是源站响应问题？

如果源站返回明确的Cache-Control:max-age或public，且边缘仍不命中，多半为CDN缓存规则或缓存键问题；反之若源站返回no-cache或每次返回不同的Etag/Set-Cookie，则为源站问题。

哪个命令或工具最能加速排查？

建议使用curl -I -L "URL"查看完整响应链；curl -v可以看到请求头；同时结合CDN提供的实时日志、边缘调试和Trace工具来定位是哪一步失效。

多少TTL或刷新策略比较合适，怎么选择？

静态资产建议较长TTL（数天至数月），目录索引或频繁更新页面可设置短TTL并配合主动Purge或版本化URL（例如带版本号的路径），以避免频繁失效带来的回源。

怎么修复和防止常见的缓存失效场景？

常见修复包括：统一URL重写规则（尾斜杠与index处理）、清理不必要的Set-Cookie、明确Cache-Control并开启public、合理设置Vary、并对目录使用版本化或CDN页面规则。

在哪里可以观察到恢复结果与验证变更是否生效？

变更生效后通过curl查看Age字段、CDN控制台的命中率与边缘响应日志，以及不带cookie或query的测试访问来验证命中恢复；也可用线上流量做AB测试确认稳定性。