当网站接入 CDN 后，如果缓存命中率持续偏低，回源请求会大幅增加，导致源站压力上升、响应变慢。典型场景是：明明配置了缓存，但后台统计显示命中率只有 30%，而回源日志中挤满了重复请求。本文从命中率指标入手，逐步拆解排查路径，最终落到回源日志分析，帮你定位根因。
场景一：命中率低但配置看似正常
假设你检查 CDN 控制台，发现缓存规则已设置，但命中率仍不理想。此时需要先确认“命中率”的定义——不同 CDN 厂商可能统计口径不一，有的只统计 HTTP 缓存命中，有的包含边缘节点上的 L1/L2 缓存。先阅读 CDN 服务商的指标说明，明确统计范围，避免误判。
接着，查看 CDN 提供的缓存命中状态码，如 X-Cache: HIT/MISS，或响应头中的 Age 字段。将响应头与命中率数据交叉验证。如果响应头显示 HIT，但整体命中率低，可能是统计周期内未命中请求占比高，需进一步分析请求特征。
场景二：同一 URL 反复回源
一个常见现象是：同一 URL 在短时间内多次回源，而缓存规则并未过期。此时需要检查请求是否携带了不同的查询参数（Query String）。很多 CDN 默认将完整 URL 作为缓存键，包括查询参数。若 URL 带有时间戳或随机数等动态参数，即使内容相同，也会导致缓存未命中。
处理方法是配置缓存键忽略指定参数，或将动态参数排除。但要注意，如果参数确实影响内容（如排序、分页），则不能轻易忽略。此外，检查是否使用了 Cookie 或 User-Agent 等作为缓存键的一部分，这些也会降低命中率。
场景三：缓存过期时间设置不当
缓存过期时间（TTL）过短，会导致频繁回源。例如，静态资源设置了 1 分钟 TTL，相当于每次请求都会回源。而 TTL 过长则可能造成内容更新延迟。合理的做法是根据资源类型设置分层 TTL：图片、CSS、JS 等静态资源可设置较长 TTL（如 7 天），HTML 页面可设置较短 TTL（如几分钟）。
同时，注意 CDN 是否遵循源站返回的 Cache-Control 头部。如果源站未正确设置，CDN 可能采用默认策略。检查源站响应头，确保 Cache-Control: max-age 和 s-maxage 设置正确。
场景四：回源日志中的异常模式
当命中率问题无法通过规则调整解决时，回源日志成为关键证据。回源日志记录了 CDN 向源站发起的所有请求，包括时间、URL、状态码、回源 IP 等。通过分析这些日志，可以发现异常模式。
例如，如果回源日志中大量请求集中在某个时间段，可能是缓存预热或突发流量导致。如果反复出现相同 URL 的回源，可能是缓存被频繁清除（如 CDN 控制台手动刷新）或缓存键不匹配。日志分析工具可使用 ELK、Splunk 等，也可借助 OpenTelemetry 等标准进行关联分析，将日志与指标、链路追踪整合，更易定位根因。
场景五：缓存命中但内容错误
有时命中率很高，但用户看到的是旧内容或错误内容。这可能是缓存了错误响应（如 5xx 状态码），或缓存键未包含必要的区分因素（如语言、设备）。检查 CDN 是否默认缓存 5xx 响应，通常应禁止缓存错误状态码。同时，确认缓存键是否包含 Accept-Language 等请求头，否则不同语言用户可能拿到错误版本。
常见误区与失败条件
- 误区一：只看命中率，不看回源日志。命中率是结果，回源日志是过程，只有结合日志才能定位具体原因。
- 误区二：忽略查询参数的影响。查询参数是缓存未命中的首要原因之一，但调整时需谨慎，避免影响动态内容。
- 误区三：缓存所有内容。动态页面、个性化内容不应缓存，否则会导致内容错乱。应明确区分可缓存与不可缓存资源。
- 失败条件：如果源站本身响应慢，即使命中率正常，用户体验也会差。此时需要优化源站性能，而非单纯依赖 CDN。
系统化排查步骤
- 确认命中率统计口径：阅读 CDN 文档，明确指标定义。
- 检查响应头：通过 HIT/MISS 状态码快速判断单次请求是否命中。
- 分析缓存键：列出可能影响缓存键的因素（查询参数、Cookie、请求头）。
- 调整 TTL 策略：按资源类型设置合理过期时间。
- 查看回源日志：筛选高频回源 URL，对比其请求特征。
- 验证修改效果：变更后持续监控命中率变化，确认是否解决。
日志质量与可观测性
回源日志的完整性直接影响排查效率。OWASP 日志安全速查表强调，日志应包含足够上下文，如时间戳、来源 IP、用户标识、请求详情等，且需防止日志注入。同时，日志本身也可能成为安全风险，需妥善保护。OpenTelemetry 提供了日志与指标、链路追踪统一的标准，若 CDN 日志能接入该体系，可大幅提升可观测性。Python 的 logging 模块也展示了标准日志库如何支持结构化输出，便于程序化分析。
CDN 缓存未命中排查没有捷径，需要结合命中率指标和回源日志进行交叉验证。从配置检查到日志分析，每一步都需谨慎。若问题仍无法解决，可考虑联系 CDN 服务商获取更详细的边缘日志。
参考资料
延伸阅读