摘要

  • Cache-Control: only-if-cached 要求只取得已存响应；遵守该指令的缓存应返回合格响应，否则返回 504。
  • 这个 504 可能在完全没有访问源站的情况下产生，因此它证明的是仅查缓存失败，而不是源站不可用。

设想一项明确属于假设的可用性探测。运营人员想确认一份配置快照是否已驻留边缘，于是发送带 Cache-Control: only-if-cached 的 GET。边缘缓存找不到符合请求约束的已存响应，返回 504。告警规则只看状态码，直接标记为源站超时并通知源站团队。可是缓存恰好执行了探测器的要求：不转发，源站也从未收到请求。

歧义来自 504 的一般含义与缓存场景中的特定用法。RFC 9110 通常把 Gateway Timeout 定义为网关或代理没有及时收到完成请求所需的上游响应。RFC 9111 则为遵守 only-if-cached 的缓存规定两种结果：返回符合其他请求约束的已存响应，或者返回 504。在后一条路径中，客户端主动要求不要进行上游获取。

因此，这项指令改变了实验问题。它问的不是“源站能否响应”，而是“当前缓存能否用获准复用的已存响应满足请求”。把结果当成普通端到端探测，会把两条不同控制路径混为一谈。

缓存中存在某些字节也不够。RFC 9111 仍要求目标与方法匹配，Vary 指定的字段匹配，验证要求得到满足，而且响应必须新鲜、成功验证或获准以过期状态提供。缓存可能保存了该 URI 的数据，却没有任何可用候选。504 因而可能表示“在这些约束下没有合格响应”，甚至不等同于“这里什么都没存”。

状态码也不会说明是哪一级缓存作出决定。一个请求可能经过浏览器缓存、企业代理、CDN 与网关。调查需要回答：谁返回了 504，该节点看到了哪些指令，找到了哪些候选，为何淘汰，以及是否禁止了转发。缺少这些事实，仪表盘只是按惯例分配责任。

这种区分直接影响处置。源站故障与边缘驻留失败对应不同责任人、回滚方式和客户影响。如果一项普通探测同时成功，也不能据此认定源站间歇性异常；更可能是两项探测问了不同问题。

应建立“仅查缓存决策收据”。这是本文提出的运营控制，不是 IETF 定义的协议对象。收据需要绑定请求目标、方法、全部 Cache-Control 请求指令、缓存身份与查找键、候选响应、Vary 比较、新鲜度或过期复用权限、验证要求、最终选择或未命中、转发决定，以及是否存在上游访问。随后才能把事件归为缓存资格、转发策略或上游超时。

“没有上游访问”不证明源站健康；它只证明这次观察无法证明源站故障。要判断源站可达性，需要另一次不带仅查缓存约束的探测。状态码可以完全合规，却对应不同因果故事；请求上下文和执行轨迹决定哪一个故事有证据支持。

来源