爬虫控制，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1e67787c71d1.html
📄
爬虫控制，源站正常而边缘节点异常时应保留哪些证据
先给结论：源站正常、边缘节点异常时，最该保留的不是“谁对谁错”的结论，而是能证明差异发生在哪一层的原始材料。具体包括：同一 URL 在源站与边缘节点的完整响应头、状态码与响应体摘要，带时间戳的请求标识，边缘缓存与回源记录，以及规则版本与生效时间。只保留边缘侧截图或只保留源站日志，都不足以支撑后续判断。
矛盾现象：源站日志干净，边缘侧却出现异常
典型情形是：直接回源请求返回 200，内容正确；但经过边缘节点访问时，同一路径出现 403、404、空响应或旧内容。此时有两种合理解释。
解释一：边缘层拦截或改写。边缘的 WAF、Bot 管理、缓存规则或重写规则在源站之前生效，请求根本没有以预期形态到达源站，或响应在返回途中被替换。
解释二：源站对边缘回源身份的处理不同。边缘回源时使用的 IP、UA、Host 或请求头与直连请求不同，源站可能对这类回源请求返回了不同结果，只是直连测试没复现。
这两种解释会导致完全不同的修复动作：前者要改边缘规则，后者要改源站对回源请求的判定。仅凭“源站正常”这一条，无法区分。
能区分两种解释的证据清单
要区分上述两种解释，需要同时保留两侧的原始记录，并保证它们能按同一请求对齐。
- 请求唯一标识：边缘生成的 request ID、trace ID 或回源请求 ID。没有它，两侧日志无法配对，只能靠时间猜测。
- 完整响应头：包括
Server、Via、Age、Cache-Control、X-Cache类字段，以及任何自定义头。响应头能显示响应由哪一层生成、是否命中缓存。 - 状态码与响应体摘要：记录状态码和响应体前若干字节的哈希或摘要，而不是只记“报错”。空响应体和错误页是不同证据。
- 边缘规则版本与生效时间：WAF、Bot 管理、缓存、重写规则的版本号和变更时间。规则变更时间与异常出现时间是否吻合，是重要线索。
- 回源请求的原始形态：边缘实际发出的 Host、UA、源 IP 段、请求方法、路径与查询串。与直连测试逐项对比。
- 时间同步说明：两侧日志的时区与时钟偏差。时间戳对不齐时，配对结论不可靠。
其中，request ID 与规则版本是最关键的两项。缺少它们，其余证据只能形成弱相关，无法排除巧合。
一个假设例子：如何用证据排除其中一种解释
假设某路径直连源站返回 200，经边缘访问返回 403。保留证据后发现：边缘日志中该请求的 WAF 规则命中记录，与规则版本变更时间相差数分钟；同时边缘回源记录显示该请求并未到达源站。这组证据指向解释一，即边缘层拦截。
反过来，若边缘日志显示请求已回源，且回源请求的 UA 与直连测试不同，源站日志中对应 request ID 返回 403，则指向解释二。此时下一步动作应是调整源站对回源身份的判定，而不是修改边缘拦截规则。
这个例子是假设的比较方法，不代表任何真实项目结果。它的价值在于说明：证据必须能指向“请求在哪一层被改变”，而不只是证明“两层结果不同”。
证据保留时的边界与常见误判
保留证据时要注意几个边界，否则容易把相关当成因果。
- 边缘请求量下降或源站抓取量归零，不能单独证明拦截正确。缓存命中、上游调度、客户端重试策略变化，都可能产生同样现象。
- robots.txt 的抓取限制不等于可靠的索引移除。边缘异常与抓取控制是不同层面的问题，不要混用结论。
- 站点地图提交不保证收录，HTTPS 也不保证安全无漏洞或排名。这些与边缘异常的证据链无关，不应作为判断依据。
- 不同搜索引擎对抓取控制的支持情况须分别核查，不能把一家的行为直接套用到另一家。
实际动作上，建议在异常复现时立即冻结两侧日志片段、导出规则版本快照，并用同一 request ID 做一次配对核对。配对成功后再决定改边缘还是改源站；配对失败时，先补齐标识与时间同步，再谈修复。这一步的结果直接决定后续动作的方向，跳过它容易在错误的一层反复调整。
