日志里出现带 Googlebot 字样的请求，并不等于蜘蛛真的来了。User-Agent 是一段客户端自报的字符串，任何脚本都能照抄。把假蜘蛛当成真蜘蛛，会浪费服务器资源；把真蜘蛛当成假蜘蛛挡掉，则可能让 URL 发现变慢，新页面迟迟不被抓取。下面这套流程，目的是在不误伤的前提下把两类请求分开。

一、先明确要解决什么问题

• 服务器资源被盗刷：假蜘蛛高频抓取，尤其是搜索页、筛选参数页这类动态地址。
• 真蜘蛛被误封：防火墙按 UA 关键字拦截，或按频率限速过严，导致整体抓取量下降。
• 数据判断失真：把假蜘蛛写进抓取频次报表，得出的结论是错的。
• 放行规则失效：robots.txt 和 WAF 白名单本来是给真蜘蛛配的，来源认错了，整套策略都会偏。

二、User-Agent 只能当第一道筛子

UA 是请求头里的自述信息，伪造成本极低，可以用来快速分流，但不能单独作为判定依据。常见的写法包括 Googlebot、bingbot、Baiduspider 等，但版本号和平台部分会变，不建议写一段固定字符串做精确匹配，也不要用 bot 这种宽泛关键词一刀切，会误伤正常工具和访客。

更稳的做法是：先按 UA 把请求分成“需要进一步验证”的一堆，再用下面的方法确认。

三、反向 DNS 验证

主流搜索引擎都公开了验证方法，核心是双向解析，顺序不能反。

1. 反向解析：拿请求来源 IP 做 PTR 查询，得到主机名。
2. 检查域名后缀：Google 的应以 googlebot.com 或 google.com 结尾，Bing 的为 search.msn.com。
3. 正向解析：把上一步得到的主机名再做一次 A/AAAA 查询，看是否解析回原始 IP。
4. 两者一致才认；不一致时再用原 IP 去比对官方 IP 段。

先看正向再看反向，容易被伪造的域名绕过去，因此顺序很重要。

四、官方 IP 段列表做兜底

Google、Bing 等会发布可下载的 IP 段文件，格式常见为 JSON 或纯文本。把这些列表定期同步到服务器或 CDN 的规则里，可以在反向解析失败（例如 DNS 超时）时提供第二层判断。列表会更新，建议按天或按周自动拉取，不要手工维护一份静态清单。

五、用日志和行为特征交叉验证

• 请求节奏：真蜘蛛频率相对稳定，并受抓取预算约束；假蜘蛛常表现为突发高频或固定间隔的机械请求。
• 路径分布：真蜘蛛会按链接关系走，同时请求 robots.txt、Sitemap；假蜘蛛往往只盯少数页面，比如价格页或搜索接口。
• 请求头：真蜘蛛一般不携带来源页 Referer，伪造者常留下浏览器风格的完整头部组合。
• 对响应码的反应：遇到 5xx，真蜘蛛会退避，假蜘蛛通常照抓不误。

六、确认之后怎么用

分清真伪之后，才能决定放行与拦截。真蜘蛛给稳定带宽和正常响应速度，Sitemap 与内链保持可访问；假蜘蛛按普通访客或黑名单处理。需要注意，对真蜘蛛返回 403、429 或长时间 5xx，会直接影响后续抓取频次，而且恢复通常比降速更慢。

落地检查清单

• 按 UA 统计日志中的 Top IP，人工抽查几条做反向 DNS。
• 把官方 IP 段接入防火墙或 CDN 白名单，并设置自动更新。
• 对可疑高频 IP 做限速，而不是直接封掉整个 UA 关键字。
• 定期查看蜘蛛的响应码分布，确认没有大面积 403、5xx。
• 保持 robots.txt 和 Sitemap 可公开访问，避免验证规则把真蜘蛛挡在外面。

判断蜘蛛真假的目的，不是做一份完美名单，而是让真蜘蛛顺畅走完发现和抓取流程，同时不让伪造流量掏空服务器。

这套流程不需要很复杂的基础设施，一段脚本加一份定期同步的 IP 列表通常就够了。关键是别把 UA 当成唯一证据，也别在没验证之前就把带 bot 字样的请求全部拒掉。