爬虫控制怎样取得可复查的状态证据 - 用日志、响应与版本记录判断抓取状态

📍 WDQWDWQD987AAAAA:216.73.216.36
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1e1ad95fac6a.html
📄

爬虫控制怎样取得可复查的状态证据 - 用日志、响应与版本记录判断抓取状态

可复查的状态证据，指别人拿着你的记录就能重新得到同一结论，而不是只看到一句“已控制”或“已封禁”。对爬虫控制来说，最直接的证据来自三类可留存材料：服务器访问日志中与目标爬虫相关的请求记录、这些请求对应的HTTP状态码与响应头、以及robots.txt或WAF规则本身的版本与生效时间。三者能互相对上，才算可复查；只有其中一项，通常只能说明“可能生效”，不能说明“已经生效”。

常见误解：改完robots.txt就等于控制住了

很多人把“写了Disallow”当成控制完成的标志。实际上robots.txt只是抓取限制的声明，合规爬虫可能遵守，恶意爬虫完全可以忽略；它也不等于索引移除，被限制抓取的URL仍可能因为外链或历史记录出现在结果里。因此，只保存一份robots.txt文本，无法证明爬虫是否真的来过、是否真的被限制。可复查的证据必须包含“请求侧”的记录，而不只是“规则侧”的文本。

第一步：先固定判断口径，再收集证据

在动手前先写下你要验证的具体命题，例如“某爬虫在最近7天内对/product/路径的请求是否返回429或403”。命题越具体，证据越容易复查。建议同时记录以下字段：

如果日志里只有IP没有User-Agent，或者只有User-Agent没有状态码，证据链就是断的。此时应把它标为“待补证”，而不是直接下结论。

第二步：用可复核的对比确认状态

单次抓取结果容易受缓存、CDN节点、测试时间影响。可复查的做法是做一次前后对比，并保留原始输出：

  1. 在规则生效前，记录一次目标URL的响应状态与响应头；
  2. 应用限制规则，记录规则内容的哈希值与生效时间；
  3. 在生效后再次请求同一URL，记录状态码与响应头；
  4. 把两次结果并列保存，注明请求来源、时间和使用的工具版本。

判断结果时注意条件：返回403通常表示服务器拒绝，返回429通常表示限流，返回200则说明本次请求未被拦截。但状态码只反映这一次请求，不能推断所有IP、所有路径都被控制。若你用的是搜索引擎官方工具查看抓取统计，要分清那是网页搜索的抓取数据，与平台推荐或付费广告的抓取是不同体系，不能互相替代。

第三步：把证据整理成可交接的最小集合

时间和人手有限时，优先保留能独立说明问题的最小集合，而不是导出全部日志。一个可用的最小集合包括：规则文件快照及其哈希、规则生效时间、一段带时间戳的访问日志摘录、对应的状态码统计、以及一份说明“本次结论适用范围”的短备注。备注里要写清哪些路径、哪些时间段、哪些User-Agent被覆盖，哪些没有。这样即使换人复查，也能判断结论是否仍然成立。

如果日志量太大，可以先按状态码聚合，例如统计某路径下403、429、200各自的数量，再抽取少量原始行作为样本。聚合数据用于看趋势，原始行用于验证真实性，两者都要留。

需要单独核查的边界

HTTPS只说明传输层加密，不代表站点没有漏洞，也不代表抓取控制已经到位。站点地图提交不保证收录，robots.txt限制也不保证移除索引。不同搜索引擎对同一规则的支持情况可能不同，涉及具体搜索引擎时应分别查看其官方文档并分别留存证据，不要用一份记录推断所有引擎的行为。

下一步建议：先选定一个最需要控制的路径，按上面的最小集合做一次前后对比，把规则哈希、日志摘录和状态码统计放在同一个文件里，标注采集时间与适用范围。之后每次调整规则，都在同一文件追加新记录，而不是覆盖旧记录。

图1 图2
nginx