ETag与CDN条件请求：为什么返回304不代表没有访问源站

浏览器网络面板出现304，有人据此判断“CDN已经命中，没有消耗源站”。这个结论缺少关键证据：304可能由边缘直接回应，也可能是在源站参与验证后产生。要计算回源压力或定位内容更新问题，需要沿请求链路确认验证发生在哪里。

304回答的是内容是否需要重传

RFC 9110将304用于条件GET或HEAD的响应：客户端已有可继续使用的表示，不必再次传输其正文。它并没有声明中间代理是否联系了源站。

ETag是资源表示的验证信息，不应被当作文件名或永远不变的业务ID。应用修改资源后，验证信息也需要正确反映变化。判断一个响应是否正确，应同时看内容版本、条件头和产生响应的层级。

三段链路分别可能发生什么

这些是排查路径，不是对所有CDN实现的描述。平台日志可能采用不同的命中状态名，必须按文档解释；不要从一个未经确认的自定义响应头推断全部缓存过程。

用可控文件做四步验证

1. 准备一个公开测试资源，记录正文版本、ETag及缓存策略，首次请求时保存响应。
2. 在资源不变时携带条件头再次请求，记录访客响应与同一时间的边缘、源站日志。
3. 等待或按受控配置让缓存进入需要验证的状态，再请求，检查是否出现上游条件请求。
4. 更新测试资源，确认新的客户端能取得新正文，持旧验证信息的客户端也能正确更新。

本文提供的是未执行的验证流程。资源应专门用于测试，不要反复刷新全站缓存来制造对照；生产验证时需约定观察窗口和回退方式。

内容压缩和变体不能漏掉

同一URL可能按编码、语言或其他条件返回不同表示。检查时固定这些请求条件，再比较ETag。否则，两个不同变体的差异可能被误判为缓存失效。共享缓存的验证与更新机制可结合RFC 9111核对。

如果源站内容已经更新，但验证信息未变化，应先修复生成与发布逻辑。强行清理一次缓存只能暂时掩盖问题；下一次内容更新仍可能复现。对于不可变版本资源，也要确认HTML引用已经切换到新地址。

缓存收益应该怎样记录

分别记录访客响应字节、边缘回源次数、源站响应字节和验证耗时。源站返回304通常少传正文，但仍可能承担连接、请求解析或业务判断成本，不能把它当成完全没有源站工作。

若目标是减少重复回源，结合缓存键与命中率检查分析缓存策略；若目标是降低更新延迟，则重点关注验证信息是否可靠以及发布过程是否一致。两类目标需要不同的证据。

资料核对日期：2026年10月30日。本文由AI辅助整理，技术事实依据文内原始资料核对。示例与操作清单供实施参考；产品配置和软件维护状态以实施时的官方资料为准。