域名注册，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3b3067a23ad7.html
📄
域名注册，源站正常而边缘节点异常时应保留哪些证据
先给结论：当源站响应正常、用户却从边缘节点拿到错误内容或超时，你要保留的不是“源站能打开”的截图，而是能证明差异发生在哪一跳的证据。核心是三组：边缘节点返回的完整响应头、同一时刻源站的对照响应、以及请求标识与时间戳。缺少任何一组，后续都只能靠猜。
为什么源站正常不能作为结案依据
源站正常只说明回源链路的一端没问题。边缘节点异常可能来自缓存副本陈旧、节点回源失败、TLS 握手在边缘终止、或者某个地域的调度把请求导向了问题节点。这些情况下，你在办公室直接访问源站 IP 往往一切正常，因为你的请求根本没经过那个出问题的边缘节点。
所以判断的前提是：必须先确认异常请求确实经过了边缘节点，而不是直连源站或被本地网络干扰。如果无法确认这一点，后面收集的所有证据都可能指向错误方向。
必须保留的三类证据
边缘节点的完整响应头
不要只截状态码。要保留完整响应头，重点关注这些字段：
Age：数值很大说明命中的是较旧的缓存副本，异常可能来自缓存未及时更新。Cache-Control与Vary：用于判断该响应是否本应被缓存，以及是否因请求头差异命中了不同副本。X-Cache或类似的命中标识：区分命中、回源、绕过缓存三种情况。Server与Via：辅助判断请求经过了哪一层。Date与响应体哈希：用于和源站对照是否同一份内容。
实际操作：用 curl -sI 抓取响应头并保存到文件，同时对响应体计算哈希。这一步的结果直接决定下一步——如果 Age 很大而源站内容已更新，方向就是缓存刷新；如果 Age 很小但内容仍错，方向就转向回源或节点配置。
同一时刻源站的对照响应
边缘证据必须配一份源站证据，且时间要尽量接近。对照项包括：状态码、响应体哈希、关键响应头。只有两边都留下，才能证明“差异存在”，而不是“某一边单独异常”。
注意一个容易误判的点：源站响应正常、边缘响应异常，并不能单独证明边缘节点处理有错。还有几种合理解释——边缘拿到了不同的源站副本（多源站未同步）、请求在边缘被改写、或者你抓取的源站路径与边缘回源路径并不相同。保留对照证据的价值，正是为了之后逐一排除这些解释。
请求标识与时间戳
记录请求的完整 URL、请求头中的追踪标识、发起时间（带时区）、以及发起位置。如果边缘返回了请求 ID，务必一并保存。这些字段是把“用户报告的问题”和“你抓到的响应”对应起来的唯一线索。
保留、改写还是退出：三种取舍的适用前提
证据到手后，决策取决于异常的性质，而不是取决于你手上有多少材料。
- 保留现有配置：适用于异常仅出现在个别节点、且
Age显示为陈旧缓存。此时先刷新缓存并复测，配置本身不需要动。 - 改写规则：适用于多个节点、多地域同时出现同类异常，且对照证据显示回源请求被系统性地改写。此时要调整的是缓存键或回源规则，而不是逐个节点处理。
- 退出该边缘方案：只在异常持续、无法定位、且业务对可用性要求高于成本时成立。退出前仍需保留完整证据，否则迁移后同样的问题可能重现，你却失去了对比基线。
一个假设例子：如何用证据区分两种原因
假设某页面源站已更新为版本 B，边缘仍返回版本 A。你抓到边缘响应 Age: 86400，源站响应哈希对应版本 B。此时证据指向缓存未过期，动作是刷新该 URL 的缓存并复测。
反过来，如果边缘 Age 很小、却仍返回版本 A，同时源站返回版本 B，那么缓存不是主因，更可能是回源请求被导向了另一份旧副本或另一个源站。此时刷新缓存不会解决问题，下一步应核查回源配置与源站副本一致性。同一个现象，两种证据组合指向完全不同的动作，这就是为什么要同时保留边缘与源站两侧的数据。
留证时的常见误区
只保留状态码截图，等于放弃了判断缓存与回源差异的依据。只保留源站日志，等于没有异常现场。把用户口述的“打不开”当作事实，而不去复现并记录实际响应，会让后续所有分析建立在转述之上。
另外要分清：抓取限制类配置不等于索引移除手段，站点地图也不保证被收录，这些和边缘异常是不同层面的问题，不要混在同一份证据里。若异常同时涉及搜索引擎抓取表现，应分别核查各搜索引擎的支持情况，而不是用一份日志下统一结论。
最后，请求量或抓取量短期归零，不能单独证明你的处理正确，它也可能来自统计口径变化、抓取周期波动或上游调度调整。把它和响应头、对照响应放在一起看，才构成可复查的证据链。
