同一URL忽快忽慢：分层缓存日志能解释到哪一步

同一篇内容有时很快打开，有时等待明显变长，运营记录若只写“CDN不稳定”，下一位排查者几乎无从接手。对使用 Cloudflare Tiered Cache 的站点，更有用的问题是：较慢的那次请求经过了什么缓存路径，以及日志中的耗时究竟包括哪些环节。

Cloudflare 的分层缓存延迟文档指出，较慢的 MISS 或 EXPIRED 与较快的 HIT 可能和分层缓存有关。这是一个待验证的方向，不是看到缓存未命中就能成立的故障结论。开始整理时，应保留同一URL的请求时间、缓存状态及对应日志，而不是把不同页面的最快和最慢数字拼成一组。

首先看 CacheTieredFill。该值为 true 表示下层节点从上层获取了内容。再把 EdgeColoCode 与 UpperTierColoID 放到相邻两列：前者是下层节点的 IATA 代码，后者是上层节点的内部标识，二者的编码含义不同。若表格把它们统称为“机房编号”，后续比对很容易出现看似相同、实际上无法直接对应的记录。

耗时列也要写清边界。文档中的 OriginResponseDurationMs 从下层发出上游请求计到收完响应，可能包含上层查询、往返传输以及回源处理。它不是某一段网络线路的独立测速结果。即使这个值上升，也不能只凭这一列断言是源站程序变慢或某个节点拥堵。

一个便于交接的阅读顺序是：先按同一URL和明确的时间窗口归组，再看缓存结果，随后区分 CacheTieredFill 的取值，最后比较上下层标识与耗时是否同时变化。原始请求标识应始终保留，避免汇总以后失去回查入口。如果只有少量日志，就直接注明样本范围，不把局部现象写成全天结论。

向技术支持提交材料时，可以附上UTC时间窗口、站点标识、相关日志字段以及观察到的关联，例如“这一组较慢请求都经过同一上层节点”。这句话描述的是证据；“该节点故障”则需要进一步验证。本文整理的是官方日志字段的阅读方法，没有测量任何线上线路，也不涉及更改缓存规则。原文更新标记为2026年9月29日，适用范围仍应以正在使用的产品功能为准。