404错误页面：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /91fbf2ed0d99.html
📄
404错误页面：源站正常而边缘节点异常时应保留哪些证据
先给结论：当源站返回 404 而边缘节点表现不一致时，你要保留的不是“谁对谁错”的结论，而是一组能同时证明请求路径、响应来源和时间顺序的证据。最小可用证据集包括：带时间戳与节点标识的边缘响应头、同一 URL 从源站直连的响应、边缘与源站的缓存状态字段，以及能对应到具体节点的请求 ID。缺了其中任何一项，多角色讨论就会退化成互相复述现象。
两种条件决定你保留证据的侧重点
第一种条件：边缘节点只是缓存了旧的 404，源站已经恢复 200。此时证据重点在“时间差”，你需要能证明源站在某个时刻之前就已经不是 404，而边缘仍在返回旧结果。第二种条件：源站确实返回 404，但边缘把 404 改写成 200 或软 404 页面。此时证据重点在“响应来源与状态改写”，你需要能证明最终状态码不是源站给的，而是边缘层产生的。
判断属于哪一种，可以先做一个动作：从同一台机器分别请求边缘地址和源站地址，各自保存完整的响应头。如果源站是 200 而边缘是 404，且边缘响应头里带有较老的缓存年龄字段，偏向第一种；如果两边状态码接近但边缘多出改写痕迹，偏向第二种。这个动作的结果直接决定下一步是去推动缓存刷新，还是去核对边缘的响应改写规则。
必须固定下来的字段，而不是截图
截图在跨角色沟通里几乎不可核对，因为它不携带可复现的请求标识。优先保留原始响应文本，并确保以下字段可见：
- 请求的完整 URL，包括查询字符串，因为带参数的 URL 常被单独缓存。
- 响应状态码，以及边缘层额外附加的状态字段（例如缓存命中标识、节点标识）。
- 响应头中的时间信息，包括边缘生成时间与缓存年龄，用于建立先后顺序。
- 请求 ID 或追踪 ID，用于让不同角色定位到同一次请求。
- 源站直连的对应响应，作为对照基线。
这些字段的作用不是“留档好看”，而是让分歧变成可核对项。比如运营说“用户看到的是 404”，开发说“源站是好的”，两份响应放在一起，就能定位到差异发生在哪一层。
一个注明假设的短例子
假设某页面在源站返回 200，但边缘节点返回 404，且边缘响应头显示缓存年龄为 6 小时。此时可以保留三份证据：边缘响应原文、源站直连响应原文、以及边缘节点的缓存年龄字段。基于这个假设，合理的下一步是核对边缘缓存键是否把查询字符串纳入了缓存，而不是直接删除源站页面。如果缓存键确实忽略了查询字符串，那么清理缓存只解决当下，规则不改还会复现。
反过来，如果边缘与源站返回的状态码一致，但边缘多出一段自定义错误页内容，那么证据重点应转向边缘的响应改写配置，而不是缓存。两种情况下要保留的字段相同，但下一步动作完全不同。
例外与容易误判的情况
有些边缘节点会在源站超时后返回 404，而不是 5xx。这时如果你只看状态码，会误判为“页面不存在”，而实际是回源失败。区分方法是看边缘响应头里是否带有回源超时或回源失败的标识。没有这个标识时，不要仅凭 404 就断定源站返回了 404。
另一种例外是软 404：边缘返回 200，但内容其实是错误页。这种情形下状态码证据不足以支撑判断，需要同时保留响应正文的片段，用于说明返回内容与状态码不一致。注意，保留正文片段是为了核对，不是用它替代状态码证据。
还有一点需要单独核查：不同边缘节点可能缓存状态不同，同一时刻有的节点返回 404、有的返回 200。这种情况下，单个节点的响应不能代表整体，需要按节点分别保留证据，并标注每个节点对应的请求时间。否则很容易把“节点间不一致”误读成“时好时坏”。
把证据转成可核对的项目
证据收集完之后，建议整理成一张对照清单，每个条目包含：请求地址、请求时间、响应来源（边缘或源站）、状态码、缓存相关字段、请求 ID。让每个角色在同一张清单上标注自己的判断依据，而不是各自描述现象。这样做的结果是，分歧会收敛到具体字段上，例如“缓存年龄是否超过阈值”或“边缘是否改写了状态码”，而不是停留在“我这边看是好的”。当清单上某一项无法对齐时，那一项就是下一步要验证的对象，而不是继续争论结论。
