当网站接入 CDN 后，如果缓存命中率持续偏低，回源请求会占据大量带宽，源站压力陡增，用户访问速度也会受到影响。本文从实际场景出发，梳理 CDN 缓存命中率低的常见原因，并给出可落地的优化策略。
场景一：静态资源未被缓存
很多站点接入 CDN 后，发现图片、CSS、JS 等静态资源仍然频繁回源。最直接的原因是缓存配置未生效。Cloudflare 等 CDN 默认只缓存特定文件扩展名（如 .jpg、.css、.js 等），并且对响应头有要求。如果源站返回的响应头包含 Cache-Control: no-store 或 Set-Cookie，CDN 会视为不可缓存。此外，如果请求 URL 带查询参数，CDN 可能默认不缓存带查询字符串的资源。
排查步骤
- 检查源站响应头，确认
Cache-Control和Expires是否允许缓存。 - 确认资源扩展名是否在 CDN 默认缓存类型中，或是否已通过缓存规则覆盖。
- 检查 URL 是否包含查询参数，必要时配置忽略查询字符串。
场景二：动态内容无法缓存
部分页面虽然看起来是静态的，但实际由服务端动态生成，每次响应都带有 Set-Cookie 或 Cache-Control: private，导致 CDN 无法缓存。例如，电商网站的购物车页面、用户登录后的个人中心。对于这类内容，需要区分动态与静态部分，将静态资源剥离出来单独缓存。
Cloudflare 官方文档指出，可以通过 Cache Rules 精细控制哪些资源可以缓存、缓存多久，甚至对动态内容进行边缘端缓存（如使用 Workers 实现个性化缓存）。如果业务允许，可以设置较短的缓存时间（如 60 秒），既能减轻源站压力，又能保证一定的实时性。
场景三：缓存过期时间过短
很多站点为了“实时更新”，将缓存 TTL 设置得很短，甚至只有几秒钟。这导致缓存几乎每次请求都会过期，命中率自然低。实际上，对于不常变动的资源（如版本化的静态文件），可以设置较长的 TTL（如 30 天）。Cloudflare 文档提到，使用持久化存储可以增加缓存时间，并支持主动 purge 来强制更新。
优化建议
- 对静态资源设置 7-30 天的缓存时间，并在文件名中加入版本号。
- 使用 CDN 的 purge 功能，在版本更新时手动或自动清理旧缓存。
- 避免使用过短的 TTL，除非内容实时性要求极高。
场景四：缓存键设计不合理
缓存键（Cache Key）决定了 CDN 如何区分不同的缓存对象。如果缓存键包含过多变量（如 User-Agent、Cookie、语言），会导致同一资源被缓存多份，命中率下降。例如，如果缓存键包含 Cookie，那么不同用户的请求都会产生新的缓存副本，命中率极低。Cloudflare 允许通过 Cache Rules 调整缓存键，去除不必要的变量。
但要注意，如果必须根据用户身份返回不同内容，则不能简单去除 Cookie。此时可以考虑使用 Workers 在边缘端处理个性化逻辑，将公共部分缓存，动态部分单独生成。
场景五：缓存未预热或流量低
对于新上线的内容或冷门资源，CDN 节点上没有缓存，第一次请求必须回源。如果整体流量低，缓存可能刚建立就被淘汰，导致命中率低。解决方法是使用缓存预热功能（部分 CDN 提供），在内容发布时主动预取到边缘节点。Cloudflare 并未直接提供预热功能，但可以通过 Workers 定时请求或第三方工具实现。
场景六：命中率统计口径问题
有时命中率低是统计方式造成的。例如，某些 CDN 控制台显示的命中率只统计了 HTTP 200 响应，而 304 或错误响应不计入。另外，如果大量请求是动态 API，本身就不该被缓存，却计入整体命中率，会拉低数值。建议按资源类型分别统计命中率，并核对 CDN 的日志确认实际回源情况。
综合优化策略
要系统性提升命中率，可以按以下步骤操作：
- 审计源站响应头，确保静态资源允许缓存。
- 根据内容类型分级设置缓存规则：静态资源长缓存，动态内容短缓存或不缓存。
- 优化缓存键，去除不必要的影响因子。
- 利用边缘计算（如 Cloudflare Workers）实现更灵活的缓存策略，例如对个性化内容进行边缘端组装。
- 定期分析 CDN 日志，找出回源率高的 URL，针对性优化。
另外，如果回源频繁导致源站压力过大，可以参考 CDN回源502/504故障排查 中的方法优化源站性能。同时，注意缓存与安全之间的平衡，比如在配置缓存时不要忽略 X-Forwarded-For 头 的正确处理，以免影响缓存策略。
参考资料
延伸阅读