📍 WDQWDWQD987AAAAA:216.73.217.23
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /266eba5cfeb4.html
📄

主域名选择：源站正常而边缘节点异常时应保留哪些证据

先给结论：源站正常只能证明回源链路和源站本身没坏，不能证明用户拿到的是同一份内容。此时最该保留的是边缘节点返回的完整响应证据，而不是源站日志。因为你要判断的是边缘这一层是否改写了状态码、正文、缓存头或跳转目标。保留证据的目的不是归档，而是让你能决定是继续用当前主域名、改写边缘配置，还是把主域名切走。

先分清三种异常，证据保留的重点不同

边缘节点异常不是一种病。它至少分三类，每类要留的证据不一样。

• 状态码异常：源站返回200，边缘返回403、404或5xx。要留的是带完整响应头的边缘响应，重点是状态行、server、via、age、x-cache这类字段。
• 内容异常：状态码正常，但正文被替换、截断或插入跳转脚本。要留的是响应体原文，以及源站同一URL的响应体，两者做逐字节或关键片段对比。
• 跳转异常：边缘把主域名跳到另一个域名，或把301改成302。要留的是location头、跳转链的每一跳，以及最终落地URL。

把这三类混在一起，你会得到一堆无法归因的数据。先分类，再决定留什么。

必须同时保留源站与边缘两侧的同一URL证据

只留一侧等于没有对照。假设你怀疑边缘节点把某个栏目页改成了404，正确做法是：

1. 用同一路径、同一请求头，分别向源站和边缘各请求一次。
2. 保存两次的完整响应：状态行、全部响应头、响应体。
3. 记录请求时间，精确到秒，因为边缘缓存会随时间变化。

这一步的实际动作是构造可复现的对照请求。它的结果会直接决定下一步：如果只有边缘侧异常，问题在边缘配置或缓存；如果两侧都异常，问题在源站或回源链路，主域名选择就不是当前矛盾。很多团队跳过对照，直接去改DNS，结果把可复现的证据弄丢了。

缓存与回源证据：决定改写还是退出

边缘节点异常最常见的原因是缓存了错误内容。要区分“缓存坏了”和“配置错了”，需要保留：

• 响应头里的缓存标识，如cache-control、age、expires、etag。
• 带唯一查询串的请求结果，用来判断是否命中缓存。
• 强制回源请求（例如加一个每次不同的参数）的结果，与正常请求对比。

如果强制回源正常、正常请求异常，说明是缓存层问题，此时改写边缘缓存规则成立，不必动主域名。如果强制回源也异常，说明边缘到源站的链路或边缘配置本身有问题，此时保留的证据要能支撑“是否把主域名临时切到另一个可用边缘”的决策。注意，切换主域名是重动作，会牵动已有外链和已收录URL，只有在边缘侧无法快速修复时才考虑。

时间与范围证据：判断是孤立事件还是系统性问题

单个请求异常不能支撑任何决策。你需要保留能说明范围的证据：

• 同一时刻、不同地理位置的边缘响应，用来判断是否只影响部分节点。
• 同一节点、不同时间点的响应，用来判断是持续还是抖动。
• 异常URL清单，而不是只记一个URL。

这里有个常见误判：某个统计归零常被当成“边缘全挂”的证据，但归零也可能来自采集脚本失败、日志延迟、或该时段本来就没流量。归零本身不是结论，它只是提示你去核对原始响应。保留原始响应，才能排除这些替代解释。

给决策留出可交接的最小证据包

如果你要把问题交给运维或边缘服务商，证据要能独立复现。一个够用的最小包通常包括：异常URL、请求时间、请求头、源站响应、边缘响应、以及跳转链。假设（仅为说明方法）你在三个时间点各取一次边缘响应，发现只有带某类请求头的请求异常，那么结论应指向请求头相关的边缘规则，而不是主域名本身。这个结果会让下一步从“切换主域名”变成“改边缘规则”，代价小得多。

另外要记住两条边界：站点地图不保证收录，robots.txt的抓取限制也不等于可靠的索引移除，所以不要用“已提交站点地图”或“已加robots”当作边缘异常已解决的证据。HTTPS同样不保证边缘内容不被改写。不同搜索引擎对边缘返回内容的处理须分别核查，别把一家的表现当成通用结论。

最后，保留证据的取舍标准很简单：能让你或别人在另一台机器上复现同一异常，就值得留；只能证明“当时看到过”，就不值得占用决策时间。