缓存命中率下降、部分用户看到旧内容，未必意味着整个 CDN 都出了问题。要做好CDN日志分析定位缓存异常，关键是把日志按时间、资源和边缘节点拆开看，再与缓存规则及源站变化核对。下面六个误区，往往会把排查带偏。
误区一：只看总体缓存命中率
全站命中率是汇总指标，可能掩盖单个资源或地区的故障。图片命中很多，可能抵消某个关键接口或新版本文件持续回源的情况。先按资源路径、时间段和边缘节点分组，比较异常前后变化；如果只有某个节点异常，排查方向就不同于全站同时下降。
误区二：把响应状态码当成缓存结论
状态码表示请求处理结果，并不单独说明内容来自边缘缓存还是源站。以 Amazon CloudFront 标准日志为例，可结合 x-edge-result-type、x-edge-response-result-type 和 x-edge-location 查看请求结果及边缘位置；字段含义和可用性应以所用服务商文档为准。不要仅凭一次成功响应判断缓存正常。
误区三：忽略缓存键差异
同一路径也可能因查询参数、主机名或缓存策略设置而对应不同缓存对象。先检查异常请求与正常请求的这些条件是否一致，再确认服务商的缓存键配置。若参数本来就改变内容，把它们排除在缓存键之外可能造成内容混用；若参数不影响内容却被纳入，缓存对象则可能被过度拆分。
误区四：时间范围和时区没有对齐
日志的记录时间、交付时间与控制台图表时间可能不是一回事。对照日志前，确认时区、筛选窗口和日志是否已完整交付；把发布或清理缓存的时间点标在同一时间线上。短时间内数据不齐时，先延长观察窗口，避免把迟到的日志误判为流量突然消失。
误区五：一发现旧内容就立即清理全部缓存
清理缓存能促使后续请求重新获取内容，但也可能让大量请求同时回到源站，增加源站压力；如果根因是缓存键或规则错误，清理后问题还会重现。先确认受影响资源、缓存有效期和发布方式，再优先对明确的路径做定向清理，并观察回源请求是否增加。
误区六：认为边缘日志能解释所有原因
日志通常能显示请求结果、资源路径和节点等信息，却未必包含每项缓存规则的决策细节。排查时应把日志与配置变更记录、源站访问日志及发布记录互相印证。以 CloudFront 为例，标准日志中的请求时间、资源路径、状态和节点字段适合建立筛选条件，但不能替代对缓存策略的检查。
按顺序排查，避免凭感觉下结论
- 明确异常资源、发生时间、影响范围，以及用户看到的是旧内容、响应变慢还是请求失败。
- 选取异常时段和正常时段，按资源路径与边缘位置对照相关日志字段，找出差异集中在哪里。
- 核对缓存键、有效期、清理记录和近期发布；确认变化是否与异常时间吻合。
- 结合源站日志检查回源情况。修正规则或内容后，先用少量目标资源验证，再观察其他节点是否恢复。
稳妥的CDN日志分析定位缓存异常，不是寻找一个“异常字段”，而是用多个证据缩小范围。先分组、再核配置、最后验证改动，比一上来全量清理更容易找到真正原因。
常见问题
日志里没有缓存状态字段怎么办？
先查看服务商日志字段说明及当前日志配置，再用响应结果、节点、资源路径和源站记录交叉判断；不要把缺少字段直接当作缓存失败。
缓存命中率下降就一定是配置错误吗？
不一定。新资源、流量构成变化、清理缓存或资源访问分散，都可能影响命中率，应先定位下降集中在哪类请求。
排查时要观察多久？
观察窗口取决于日志交付延迟、流量规模和缓存有效期。至少覆盖异常前后及一次相关发布或规则变更，并确认日志已完整到达。
是否应该先清理缓存验证？
通常不建议。先确认受影响对象和规则；确需验证时，优先定向清理，并留意回源负载变化。
