网站抓取规则：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3cac69eceab0.html
📄
网站抓取规则：源站正常而边缘节点异常时应保留哪些证据
先给结论：此时最该保留的不是“源站一切正常”的截图，而是能证明异常发生在哪一跳、持续多久、对谁生效的三类证据——边缘节点的响应头与缓存状态、同一URL在不同节点或不同出口的对照结果、以及带时间戳的抓取端记录。缺少服务器权限也能做前两类中的一部分，但只能得出“异常与边缘节点相关”的倾向性判断，不能直接断定根因在CDN配置、回源链路还是抓取端本地网络。
为什么“源站正常”和“抓取异常”可以同时成立
矛盾现象是这样的：直接回源请求返回200，内容完整；但抓取端拿到的却是403、503、超时，或者返回一份明显过期的页面。两种解释都成立。
- 解释一：边缘节点自己出了问题。节点缓存了旧版本、节点上的WAF或限速规则误伤了抓取UA、某条边缘规则只在部分机房生效。源站确实没参与这次响应。
- 解释二：异常不在边缘，而在抓取端到边缘这一段。抓取端所在网络被目标节点拒绝、DNS解析到了不同节点、或者抓取端自身超时阈值太短，导致它没等到边缘正常返回就断开。
这两种解释的处置方向完全不同：前者要改边缘配置或清缓存，后者要改抓取端解析、出口或超时设置。所以证据的第一作用不是“证明谁错了”，而是把这两条路分开。
能区分两种解释的证据：对照与响应头
最有效的动作是做一次同URL、同时段、多出口对照，并完整保留每次请求的响应头。假设抓取端在A网络拿到503，用另一条出口（比如另一台机器、另一个网络）请求同一URL拿到200，且响应头里的缓存状态、节点标识、时间字段不同，那么异常更可能绑定在特定边缘节点或特定入口路径上。反过来，如果多个出口都在同一时间段失败，而回源始终正常，才更值得怀疑边缘规则是全局性的。
响应头里要重点留这几项（存在则记录，不存在也记录“缺失”这个事实）：
HTTP状态码与响应体前若干字节，用来区分是拦截页、错误页还是真实内容。- 缓存相关字段，如
Age、Cache-Control、X-Cache一类命中的标记，用来判断返回的是缓存副本还是回源结果。 - 节点或机房标识字段，用来把异常和具体节点对应起来。
- 日期与时间字段，用来和抓取端本地时间对齐，排除时钟偏差造成的误判。
注意一个容易过度解读的现象：某个节点抓取量归零，不能单独证明该节点被正确屏蔽或修复。它也可能只是抓取端换了DNS解析、该节点被临时摘除、或者抓取任务本身暂停。抓取量、请求量这类统计的下降有多种合理解释，必须和响应头、对照结果一起看。
没有完整日志和权限时，仍可执行的最小动作
如果你只有抓取端，没有边缘和源站权限，可以做的最小闭环是：固定一个URL，在故障时段内每隔较短间隔请求一次，同时记录状态码、响应头、响应体摘要和本地时间，并在另一条网络出口上重复同样的请求。把两组记录按时间对齐后，你会得到一张“哪个时间窗、哪个出口、哪个节点标识下失败”的对照表。
这个动作的结果会直接决定下一步：如果失败只出现在单一出口，下一步应查抓取端DNS与出口网络，而不是去动边缘配置；如果失败跨出口但集中在某个节点标识，下一步才值得向边缘侧确认该节点的规则与缓存状态；如果失败跨出口且无节点规律，则需要把范围扩大到回源链路和抓取端超时设置。
需要向边缘侧确认时，带上哪些证据才有效
向负责边缘的一方提问时，笼统说“抓取被拦了”通常得不到有效回应。更可行的做法是提供：具体URL、精确到秒的请求时间、响应状态码与完整响应头、命中的节点标识、以及同时间另一出口的对照结果。这样对方才能在自己的日志里定位到对应请求。
同时要明确适用条件：这套证据链只在“异常可复现且时间窗明确”时有效。如果异常是偶发、无法复现，那么保留的证据只能说明“曾经发生过”，不足以支撑配置层面的结论。另外，robots.txt 里的抓取限制不等于可靠的索引移除，边缘返回403也不等于源站主动拒绝，这两件事不能混为一谈。站点地图是否被处理、页面是否被收录，同样不能由这次边缘异常直接推出。
容易把结论带偏的几类证据
第一类是只有结论没有原始记录的截图，比如“源站200”的浏览器截图，它无法证明抓取端在同一时刻收到了什么。第二类是只保留状态码、丢掉响应头的记录，缺少缓存与节点字段就无法区分解释一和解释二。第三类是把单次成功当成已恢复，边缘节点的缓存和规则生效范围可能不同，单次成功只能说明该次请求路径当时可用。
把这几类排除后，剩下的证据才具备可复查性：有原始响应、有时间戳、有对照出口、有节点标识。满足这四点，即使没有源站权限，也能把问题范围收敛到一个可验证的方向，而不是停在“源站正常所以不是我们的问题”这种无法推进的状态。
