搜索引擎抓取日志：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5f4d3c29927c.html
📄
搜索引擎抓取日志：源站正常而边缘节点异常时应保留哪些证据
先给结论：当源站回源正常、边缘节点却对爬虫返回异常时，最该保留的不是一条错误截图，而是能证明“同一时间、同一 URL、源站与边缘结果不同”的成对证据。只有这组对照成立，才能把问题从源站代码排查转向 CDN、WAF 或边缘规则排查。
为什么单看源站日志会得出错误结论
源站正常并不等于爬虫看到的页面正常。爬虫请求通常先到达边缘节点，再由边缘节点决定是否回源。如果边缘层拦截、缓存了错误响应，或者对特定 User-Agent 返回不同状态码，源站日志里可能只留下一次正常回源，甚至完全没有记录。
此时如果只依据源站日志判断“服务正常”，下一步就会错误地去检查页面内容或站点地图。真正需要保留的是边缘侧与源站侧的同一请求记录，让两边能对齐时间、URL 和响应状态。
需要固定下来的证据类型
证据要能回答三个问题：谁在什么时间请求了哪个 URL，边缘返回了什么，源站返回了什么。按这个目标，优先保留以下内容。
- 边缘节点访问日志：至少包含请求时间、完整 URL、HTTP 方法、User-Agent、响应状态码、响应大小、缓存命中状态、边缘节点标识。若平台支持，再保留请求 ID 或 Ray ID 一类可关联字段。
- 源站访问日志：同一时间窗口内对应 URL 的记录，重点看是否收到回源请求、回源状态码和响应时间。
- 成对请求样本：用同一 URL、同一 User-Agent，分别从边缘和源站发起请求，保存两次响应的状态行与响应头。这一步是区分“边缘改写”与“源站故障”的关键。
- 边缘规则变更记录：WAF 规则、缓存规则、重定向规则、Bot 管理策略的变更时间和变更人。很多边缘异常不是故障，而是某次规则调整的副作用。
- robots.txt 与站点地图的当前响应：确认边缘是否对这两个路径返回了与源站不同的内容。抓取限制与索引移除是两回事，robots.txt 禁止抓取不等于页面会从索引中消失。
一个可执行的对照动作
假设某栏目页在源站返回 200，但爬虫侧显示 403。先不要改代码，做一次带假设的对照：
- 用爬虫的 User-Agent 请求边缘地址，记录状态码和响应头。
- 用同一 User-Agent 直接请求源站地址，记录状态码和响应头。
- 若边缘为 403、源站为 200，则保留这两条记录及请求时间，作为边缘层拦截的证据。
- 若两边都是 200，则问题可能出在爬虫侧的解析、渲染或抓取预算，而不是边缘拦截。
这个动作的结果会直接决定下一步：边缘与源站不一致时，去核对 WAF 和 Bot 规则；两边一致时，转向页面渲染和内部链接排查。没有这组对照，后续修改就是在猜。
什么情况下这套证据会失效
一个反例是：边缘节点按地理位置或节点线路返回不同结果。你从办公网络请求到的正常响应，未必代表爬虫实际落到的节点也正常。如果只保留单节点样本，结论就可能不成立。
因此证据里要注明请求来源、节点信息和时间。若无法确认爬虫实际命中的节点，至少保留多个时间点的样本，并标注不确定性，而不是把单次正常当作全局正常。
保留证据之后怎么推进
把边缘日志、源站日志、成对请求样本和规则变更记录放在同一时间轴上，先确认异常是否可复现。可复现时，用最小变更回滚或放行规则验证；不可复现时，继续按时间点采样，避免用一次结果下结论。HTTPS 只说明传输加密，不代表边缘规则不会拦截，也不代表页面一定被收录。不同搜索引擎对边缘异常的响应方式可能不同，需要分别核查，不能用一个引擎的结果推断另一个。
