二级域名作用：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b25a116f0b33.html
📄
二级域名作用：源站正常而边缘节点异常时应保留哪些证据
当源站响应正常、边缘节点却返回错误或旧内容时，先别急着改DNS或回源配置；保留能区分“源站问题”与“边缘问题”的证据，再决定是继续观察、改写缓存策略还是临时退出边缘。证据链的核心是同一时间窗内的对照记录，而不是单一截图。
先固定时间窗，再谈证据取舍
边缘异常常是间歇性的，单独一次抓取无法证明问题归属。你需要一个可复查的时间窗，例如连续十分钟内每隔一分钟从同一网络位置请求同一URL，同时记录响应状态、响应体摘要、响应头和请求时间。假设某次请求返回旧版本页面，而源站直连返回新版本，这只能说明边缘缓存可能未更新，不能直接断定缓存规则错误——也可能是边缘节点回源失败后使用了过期副本。
保留证据时，优先留下能交叉验证的原始材料：带时间戳的响应头、响应体哈希或首屏文本片段、DNS解析结果。如果只保留一张错误页面截图，后续无法判断是缓存命中旧副本、节点回源超时，还是请求被中间层改写。
区分“保留、改写、退出”各自适用的前提
证据足够时，处理方向通常落在三种取舍上，但前提不同。
- 保留并继续观察：异常只出现在少数节点，且源站日志显示回源请求正常，响应头中的缓存状态在异常与正常请求间有差异。此时保留证据比立即变更更安全，因为变更可能掩盖间歇性故障。
- 改写缓存或回源策略：同一URL在多个节点持续返回旧内容，而源站已更新且响应头允许缓存。此时需要保留旧副本的缓存标识、源站最新响应头，以及两次请求的时间差，用来判断是缓存过期时间设置过长，还是边缘未按预期回源。
- 临时退出边缘：边缘返回5xx且源站直连稳定，同时业务对可用性敏感。退出前应保留边缘错误响应、源站正常响应和切换前后的解析记录，否则退出后无法复盘是节点故障还是配置冲突。
三种选择不是并列清单。若证据只能证明“某次请求异常”，保留观察更合理；若能证明“同一资源在边缘与源站持续不一致”，改写或退出才有依据。
哪些证据最容易遗漏，遗漏后会影响哪一步
常见遗漏不是没抓包，而是抓了却缺少对照。例如只记录边缘返回404，却没记录源站对同一路径的响应；只看到响应头里有缓存命中标记，却没记录请求时是否带了会绕过缓存的查询参数。遗漏对照会导致下一步误判：把边缘缓存问题当成源站路由问题，进而去改源站重写规则，反而扩大影响面。
另一类遗漏是请求身份与网络位置。同一URL从不同地区、不同运营商请求，边缘节点可能不同。若不记录请求来源的大致网络位置，后续无法判断异常是否集中在特定节点。这里不需要精确到个人身份，但应保留可复现的网络环境描述，例如“同一办公网络下多次请求”。
还要注意，robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录；这些与边缘异常的证据保留无关，不要用它们替代响应记录。HTTPS同样不保证边缘节点不会返回错误内容，证书正常只说明传输层握手成功。
一个假设例子：如何用证据决定是否改写
假设某二级域名用于静态资源，源站直连返回新版本文件，边缘节点在十分钟内三次返回旧版本。你保留了三组材料：每次请求的响应头（含缓存状态与时间）、响应体首行文本、以及源站同路径的响应头。对比后发现，边缘返回旧版本时缓存状态显示命中，而源站响应头中的缓存有效期尚未到期。此时可以推断：边缘缓存仍在有效期内，源站更新未触发边缘刷新。下一步动作是改写缓存策略或主动刷新边缘缓存，而不是改DNS。若刷新后同一节点仍返回旧版本，则证据指向边缘节点未按预期回源，此时退出边缘或切换节点才有意义。
这个例子中的数字只用于说明比较方法，不代表任何真实平台的表现。关键是：先有对照，再决定动作；动作之后继续保留前后记录，才能判断下一步是回滚还是扩大变更。
证据保留的格式与期限
保留期限取决于变更节奏。若你准备改写缓存策略，至少保留变更前一个完整缓存周期内的记录，否则无法判断改写是否生效。若准备退出边缘，保留切换前后的解析记录和源站响应，便于回切时对比。格式上，纯文本日志比截图更利于检索；若只能截图，确保包含时间、URL、状态码和响应头关键字段。
最后，不要用“请求量归零”或“抓取量下降”单独证明边缘异常已解决。这些现象还可能来自监控中断、请求来源变化或统计延迟。只有把源站与边缘的对照记录放在同一时间轴上，才能支撑保留、改写或退出的决定。
