蜘蛛抓取频率，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d6fb7fc313ec.html
📄
蜘蛛抓取频率，源站正常而边缘节点异常时应保留哪些证据
先给结论：当源站日志显示抓取请求正常返回，而边缘节点侧出现异常时，不要只保存一份“抓取变少”的结论，而要同时保留源站响应、边缘响应、请求路径和变更时间四类证据，才能判断问题出在缓存、回源、规则还是节点本身。只留抓取次数曲线，通常无法区分两种完全不同的解释。
矛盾现象：源站看起来没问题，边缘侧却不对劲
常见现象是：源站访问日志里，来自搜索引擎的请求仍有稳定记录，状态码也正常；但从边缘节点的监控或日志看，同一时间段的请求量、回源量或响应状态出现明显波动。此时容易得出“抓取频率下降是因为边缘节点故障”的判断，但这个判断缺少关键中间证据。
更稳妥的做法，是把源站和边缘节点当成两条独立的证据链。源站正常只能说明应用和数据库这一层没有明显故障，不能说明边缘到源站之间的链路、缓存策略或请求改写没有问题。反过来，边缘节点异常也不必然导致抓取频率变化，因为抓取方可能仍在按自己的节奏请求，只是请求没有到达你观察的那一层。
两种解释：抓取方主动降频，还是边缘链路把请求弄丢了
第一种解释是抓取方主动降低了请求强度。触发条件可能是页面质量、重复内容、服务器历史响应表现或抓取预算分配变化。这种情况下，请求可能根本没有发到边缘节点，或者发到了但数量本身就在减少。
第二种解释是边缘链路把请求处理坏了。比如缓存规则把动态请求当成静态资源缓存，回源时改写了路径，节点超时后返回了错误页，或者安全规则误拦截了部分请求。这种情况下，抓取方可能仍在正常发起请求，但你在边缘侧看到的是失败、重试或回源异常。
两种解释都会表现为“边缘节点异常”，但处理方向完全不同：前者要检查内容与抓取关系，后者要检查边缘配置与回源链路。
能区分两种解释的证据：请求路径与响应状态要成对保留
要区分上述解释，关键是保留同一请求在源站和边缘两侧的对应记录。建议至少保留以下内容：
- 源站访问日志：包含时间、请求路径、状态码、响应大小、User-Agent。重点不是总请求数，而是来自目标抓取方的请求是否连续。
- 边缘节点日志或监控：包含同一时间窗口内的请求量、回源量、缓存命中状态、边缘返回状态码。若边缘只提供聚合数据，也要保留原始时间粒度。
- 请求路径与改写记录：边缘规则、重写规则、缓存键配置的版本和变更时间。没有变更时间，就无法判断异常是配置改动引起还是外部抓取变化引起。
- 响应内容样本：从边缘和源站分别取同一 URL 的响应头与正文摘要，确认返回的是正常页面、错误页还是重定向。
- 时间对齐证据：源站日志、边缘日志和抓取方可能使用的时区要统一标注，避免把不同时间窗口的数据误判为同一事件。
假设一个场景：某天边缘节点回源量下降，同时源站日志显示抓取请求也减少。若边缘日志里同一时间段出现大量 5xx 或超时，而源站日志没有对应记录，说明请求可能在边缘侧就被终止，没有到达源站。若边缘日志显示请求正常回源，但源站日志里路径被改写成了不存在的地址，问题就落在路径改写而不是抓取方降频。这两种证据组合指向不同的下一步动作。
保留证据后的实际动作：先复现一条请求，再决定改哪里
拿到上述证据后，不要立刻改缓存或关安全规则。先选一条在边缘侧表现异常的 URL，用相同请求头和路径分别请求边缘节点和源站，记录两次响应的状态码、响应头和正文差异。这个动作的结果会直接决定下一步：如果边缘返回错误而源站正常，优先检查边缘缓存与回源配置；如果边缘和源站返回一致，但抓取方请求确实减少，则要回到内容与抓取关系上排查。
另外，保留证据时要注意：robots.txt 的抓取限制不等于可靠的索引移除，站点地图不保证收录，HTTPS 也不保证安全无漏洞或排名。这些事实不影响当前判断，但能提醒你不要把边缘异常简单归因于“抓取方不来了”。若涉及具体搜索引擎的抓取行为，不同搜索引擎的支持情况须分别核查，不能用一个平台的日志推断另一个平台。
退出旧节点或旧合作关系时，哪些证据仍然值得留下
如果场景是旧边缘节点或旧合作关系需要退出，证据保留的重点会从“排查当前故障”转向“证明退出没有破坏抓取”。此时应保留退出前后的源站日志对比、边缘节点最后一段时间的请求记录、配置变更清单，以及仍然有价值的部分，比如可复用的缓存规则、回源策略和监控指标。不要因为合作关系结束就把所有日志清空，否则后续出现抓取波动时，无法判断是退出动作导致还是其他原因。
判断证据是否足够，可以用一个简单标准：换一个没有参与当时处理的人，能否仅凭这些记录还原“请求从哪里来、经过哪里、返回了什么、什么时候改过配置”。如果做不到，就还需要补充对应时间段的原始日志或配置版本。
