引擎收录：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /53e4ccacad0b.html
📄
引擎收录：源站正常而边缘节点异常时应保留哪些证据
先给结论：当源站响应正常、边缘节点却返回异常时，最该保留的不是一句“节点坏了”，而是能证明“同一时刻源站与边缘结果不同”的成对证据。至少留下带时区的时间戳、请求 URL、源站直连响应头与正文摘要、边缘节点响应头与正文摘要、节点标识（如回源 IP 或节点代号）、以及当时的 DNS 解析结果。缺少这组对照，后续无论是切流量、报障还是决定是否暂时移除页面，都只能靠猜。
为什么“源站正常”本身不能作为处理依据
源站正常只说明回源链路的一端没问题，它无法解释用户实际拿到的是什么。边缘节点可能因为缓存了旧的 404、被安全策略拦截、回源超时后返回兜底页，或者对某个 UA、某个地区返回了不同内容。这些情况下源站日志可能干干净净，但抓取工具和真实用户看到的却是错误页面。
判断影响范围时，一个可操作的动作是做 A/B 对照请求：同一 URL、同一时间窗，分别直连源站和经边缘节点请求，记录两者的状态码、Content-Length、Cache-Control、X-Cache 一类可区分缓存的响应头，以及正文前若干字节的哈希。若两者哈希不同而源站返回 200，基本可以把问题定位在边缘层，而不是内容本身。这一步的结果直接决定下一步：是清理节点缓存，还是先查回源配置。
必须成对保留的几类证据
证据的价值在于可复现和可对照，单独一份截图或一次 curl 输出通常不够。建议按下面几类留存，且每一类都带上时间与时区。
- 请求侧：完整 URL、请求方法、请求头中的 Host、UA、Accept-Encoding，以及发起请求的出口 IP 或地区。
- 源站侧：直连时的状态码、响应头、正文摘要或哈希、回源耗时。
- 边缘侧：经节点请求的状态码、响应头（尤其缓存命中标识、Age、Via）、正文摘要或哈希、节点代号或回源 IP。
- 解析侧：当时的 DNS 解析结果，确认请求确实落到了异常节点而不是别的线路。
如果异常表现为间歇性，单次对照可能正好落在正常窗口。此时应把对照请求重复多次并记录每次结果，用命中异常的比例说明问题，而不是用一次成功就宣布恢复。要注意，抓取量或请求量突然归零，并不能单独证明边缘处理正确，它也可能是抓取工具降频、robots 规则变化或统计口径调整造成的，必须结合上面的成对证据一起看。
把证据转成可执行的处理方案
拿到成对证据后，处理顺序会比凭感觉操作清晰得多。可以按下面的判断推进：
- 若源站 200、边缘返回 404 或 5xx，且响应头显示缓存命中，先针对该 URL 清理节点缓存，再重新做一次对照请求，确认边缘结果是否与源站一致。
- 若清理后仍不一致，检查边缘的回源配置、安全规则和 UA/地区策略，把异常请求与正常请求的请求头差异列出来，这往往就是触发点。
- 若边缘返回的是兜底页或验证页，记录该页面的特征字符串，便于在批量检测中快速识别，而不是逐条人工看。
- 若确认是节点侧问题且短期无法修复，再评估是否需要临时调整该 URL 的对外暴露方式，但这一步要以已保留的证据为前提，避免误伤正常内容。
这里要区分一个常见误区：在 robots.txt 中加抓取限制，并不等于可靠的索引移除；它只约束合规抓取行为，已经进入索引的结果未必随之消失。同理，站点地图不保证收录，提交与否和边缘异常是两条线，不要用提交站点地图来代替排查节点问题。
一个假设例子：如何用对照结果决定下一步
假设某旧页面在源站直连时返回 200，正文哈希为 A；经某边缘节点请求时返回 200，正文哈希为 B，且响应头带缓存命中标识。两次请求间隔不到一分钟，URL 与 UA 相同。这个组合说明边缘返回了与源站不同的内容，优先动作是清理该 URL 的节点缓存并复测。复测后哈希变为 A，则问题属于缓存陈旧，记录清理时间与复测结果即可收尾；若复测后哈希仍为 B，则问题更可能在回源或节点策略，需要把两次的完整响应头一并交给负责边缘配置的一方，而不是继续在源站侧排查。
这套做法同样适用于旧内容、旧系统或旧合作关系退出时的取舍：先保留能证明“哪一层返回了什么”的证据，再决定哪些部分可以下线、哪些需要保留可访问状态。证据齐全时，退出动作是有边界的；证据缺失时，任何删除或切换都可能把可恢复的问题变成不可追溯的问题。把成对证据留好，再动手，才是这类异常下更稳妥的顺序。
