高排名域名：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f8a3bf9d8502.html
📄
高排名域名：源站正常而边缘节点异常时应保留哪些证据
当源站返回正常、但边缘节点出现异常时，最该保留的不是“故障截图”，而是一组能区分“节点局部问题”和“真实内容变化”的对照证据：同一 URL 在源站与边缘各自的响应头、状态码、响应体摘要、抓取时间，以及能证明两者差异是否稳定的重复样本。缺少这组对照，后续无论找运维、CDN 服务商还是判断是否影响索引，都会陷入各说各话。
先看一个矛盾现象：源站好，边缘坏，未必是同一件事
典型矛盾是：直接回源访问某页返回 200 且内容完整，但经过边缘节点访问时，出现 5xx、旧版本页面、被替换的跳转，或响应体被截断。此时有两种解释，走向完全不同。
- 解释一：边缘缓存或回源链路局部故障。异常只出现在特定节点、特定地区或特定时间窗，源站日志里对应的回源请求可能很少甚至没有。
- 解释二：源站对“边缘来的请求”返回了不同内容。源站本身正常，但它根据请求头、来源 IP 段或 UA 做了差异化响应，导致边缘拿到的就是另一份内容。
这两种解释都会表现为“源站正常、边缘异常”，但处理动作相反：前者要清缓存、切节点、查回源配置；后者要先查源站的分发逻辑，否则清多少次缓存都会再次被污染。
能区分两种解释的证据，必须成对采集
关键是让源站请求和边缘请求在同一时间、同一 URL、同一方法下形成对照。可保留的证据包括：
- 成对的响应头。同一 URL 分别记录回源和经边缘的
HTTP 状态码、Content-Type、Cache-Control、Age、X-Cache一类缓存标识，以及Last-Modified或ETag。若边缘的ETag与源站长期不一致，说明边缘持有的是另一份实体。 - 响应体摘要，而不是全文。保存正文前若干字符、关键区块的文本片段或内容哈希，足以比较版本差异，又避免把整页大文件反复留存。
- 采集时间与节点标识。注明请求发生的时刻、出口地区或节点代号。若异常只在个别节点出现，时间与节点就是判断“局部”还是“全局”的核心。
- 重复样本。同一 URL 在若干分钟内多次请求，记录异常出现次数。稳定复现指向配置或内容差异，间歇出现更偏向节点或链路抖动。
- 回源日志的对应记录。源站访问日志中该时段是否收到边缘回源请求、返回了什么。若边缘报错而源站日志无对应请求，异常更可能发生在边缘内部。
一个假设例子：假设某页在边缘返回旧标题，而回源返回新标题，同时边缘响应的 Age 很大、ETag 与源站不同，那么“边缘缓存未更新”比“源站分发异常”更符合证据。此时下一步动作应是核对缓存规则与刷新范围，而不是修改页面内容。反过来，如果边缘与源站的 ETag 一致但正文仍不同，就要怀疑响应体在传输中被改写或截断，排查方向转向链路与压缩配置。
规模化后为什么不能照搬单点结论
个别样本成立，不代表可以推广。单节点、单 URL 的异常可能只是缓存副本过期；但当同类异常在多个节点、多个 URL 上重复出现，性质就变了。判断边界时要看三点：
- 覆盖面。异常 URL 是集中在同一目录、同一模板，还是随机散布。集中往往指向规则或配置，散布更指向节点或链路。
- 一致性。不同节点返回的异常内容是否相同。相同说明共享同一份错误缓存或同一套分发逻辑；不同说明各节点状态独立。
- 可恢复性。刷新缓存或切换节点后，异常是否消失，以及多久后是否复发。复发说明根因不在缓存副本本身。
需要提醒的是，抓取量或请求量在异常期间下降，不能单独证明边缘异常已影响索引——它也可能来自抓取预算调整、站点整体流量变化或爬虫自身的调度。只有把边缘异常证据与抓取日志、索引状态的变化时间对齐，才能谈影响，而不是把相关当成因果。
把证据整理成可交接的最小集合
实际动作可以这样落地：对每个可疑 URL，建立一条记录，包含回源与边缘两次请求的状态码、关键响应头、正文摘要、采集时间和节点标识，再附上源站日志中对应时段的回源记录。整理完成后，用“同 URL 对照是否稳定复现”作为分诊依据：稳定复现且 ETag 不一致，先处理缓存与分发规则；稳定复现但 ETag 一致，先查传输与响应体改写；间歇复现且源站日志无回源，先查节点与链路。这个分诊结果直接决定下一步找谁、改什么，也决定是否需要继续扩大采样范围。
最后要明确适用条件：以上对照只在源站可正常回源、且能同时获取两侧响应时才成立。如果源站本身已不可访问，或边缘不允许回源验证，就只能退回到单侧证据，结论强度会明显下降，此时应优先恢复可对照的采集条件，再判断异常归属。
