主域名选择：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e9efbeee01f0.html
📄
主域名选择：源站正常而边缘节点异常时应保留哪些证据
先给结论：源站正常只能证明回源链路和源站本身没坏，不能证明用户拿到的是同一份内容。此时最该保留的是边缘节点返回的完整响应证据，而不是源站日志。因为你要判断的是边缘这一层是否改写了状态码、正文、缓存头或跳转目标。保留证据的目的不是归档，而是让你能决定是继续用当前主域名、改写边缘配置，还是把主域名切走。
先分清三种异常，证据保留的重点不同
边缘节点异常不是一种病。它至少分三类，每类要留的证据不一样。
- 状态码异常：源站返回200，边缘返回403、404或5xx。要留的是带完整响应头的边缘响应，重点是状态行、
server、via、age、x-cache这类字段。 - 内容异常：状态码正常，但正文被替换、截断或插入跳转脚本。要留的是响应体原文，以及源站同一URL的响应体，两者做逐字节或关键片段对比。
- 跳转异常：边缘把主域名跳到另一个域名，或把301改成302。要留的是
location头、跳转链的每一跳，以及最终落地URL。
把这三类混在一起，你会得到一堆无法归因的数据。先分类，再决定留什么。
必须同时保留源站与边缘两侧的同一URL证据
只留一侧等于没有对照。假设你怀疑边缘节点把某个栏目页改成了404，正确做法是：
- 用同一路径、同一请求头，分别向源站和边缘各请求一次。
- 保存两次的完整响应：状态行、全部响应头、响应体。
- 记录请求时间，精确到秒，因为边缘缓存会随时间变化。
这一步的实际动作是构造可复现的对照请求。它的结果会直接决定下一步：如果只有边缘侧异常，问题在边缘配置或缓存；如果两侧都异常，问题在源站或回源链路，主域名选择就不是当前矛盾。很多团队跳过对照，直接去改DNS，结果把可复现的证据弄丢了。
缓存与回源证据：决定改写还是退出
边缘节点异常最常见的原因是缓存了错误内容。要区分“缓存坏了”和“配置错了”，需要保留：
- 响应头里的缓存标识，如
cache-control、age、expires、etag。 - 带唯一查询串的请求结果，用来判断是否命中缓存。
- 强制回源请求（例如加一个每次不同的参数）的结果，与正常请求对比。
如果强制回源正常、正常请求异常，说明是缓存层问题，此时改写边缘缓存规则成立，不必动主域名。如果强制回源也异常，说明边缘到源站的链路或边缘配置本身有问题，此时保留的证据要能支撑“是否把主域名临时切到另一个可用边缘”的决策。注意，切换主域名是重动作，会牵动已有外链和已收录URL，只有在边缘侧无法快速修复时才考虑。
时间与范围证据：判断是孤立事件还是系统性问题
单个请求异常不能支撑任何决策。你需要保留能说明范围的证据：
- 同一时刻、不同地理位置的边缘响应，用来判断是否只影响部分节点。
- 同一节点、不同时间点的响应，用来判断是持续还是抖动。
- 异常URL清单，而不是只记一个URL。
这里有个常见误判：某个统计归零常被当成“边缘全挂”的证据，但归零也可能来自采集脚本失败、日志延迟、或该时段本来就没流量。归零本身不是结论，它只是提示你去核对原始响应。保留原始响应，才能排除这些替代解释。
给决策留出可交接的最小证据包
如果你要把问题交给运维或边缘服务商，证据要能独立复现。一个够用的最小包通常包括：异常URL、请求时间、请求头、源站响应、边缘响应、以及跳转链。假设（仅为说明方法）你在三个时间点各取一次边缘响应，发现只有带某类请求头的请求异常，那么结论应指向请求头相关的边缘规则，而不是主域名本身。这个结果会让下一步从“切换主域名”变成“改边缘规则”，代价小得多。
另外要记住两条边界：站点地图不保证收录，robots.txt的抓取限制也不等于可靠的索引移除，所以不要用“已提交站点地图”或“已加robots”当作边缘异常已解决的证据。HTTPS同样不保证边缘内容不被改写。不同搜索引擎对边缘返回内容的处理须分别核查，别把一家的表现当成通用结论。
最后，保留证据的取舍标准很简单：能让你或别人在另一台机器上复现同一异常，就值得留；只能证明“当时看到过”，就不值得占用决策时间。
