看日志时很容易产生一种错觉：只要 User-Agent 里写着 Googlebot 或 Bingbot，就默认那是搜索蜘蛛。实际上 UA 是客户端自己填的一段字符串，改起来比改浏览器标签还简单。日志里混进伪造的蜘蛛请求，几乎是每个有一定流量的站都会遇到的事。
为什么 UA 不能当作身份证明
HTTP 请求头是客户端自报家门，服务器没有强制校验机制。任何人写个脚本，把 UA 改成 Googlebot/2.1，请求就会以这个身份出现在日志里。
常见的伪装动机有这么几类：
- 批量扫描漏洞、试探登录路径，用蜘蛛 UA 降低被拦截的概率；
- 抓取站内内容做镜像或训练数据，伪装成搜索引擎减少被封；
- 第三方工具做站点体检或压力测试，顺手套了个蜘蛛 UA；
- 统计报表里凑一个搜索来源，让数据看起来好看。
这些请求对服务器的消耗是真实的：它们占带宽、占连接数，严重的还会挤占真蜘蛛的抓取体验。
验证真蜘蛛的三步
第一步：从日志里取出 IP 和 UA
按 UA 关键字筛选出一批请求，把对应的 IP 列出来去重。不要只凭一条日志下判断，先看整体分布：某个 IP 短时间内请求几百次、并且集中在某几个目录，多半不是搜索蜘蛛的行为模式。
第二步：反向 DNS 查询，再做一次正向确认
用 IP 反查 PTR 记录，看域名是否落在搜索引擎的官方域名后缀下。只做反向查询还不够，因为 PTR 记录本身也可能被伪造；规范的做法是拿反查到的域名再正查一次 A 记录，确认能解析回原来的 IP。这是主流搜索引擎官方推荐的验证思路。
第三步：比对官方公布的 IP 段
Google、Bing 等都会公开蜘蛛使用的 IP 段，并提供可机器读取的列表文件，方便定期拉取比对。把日志里的 IP 与这些网段对照，能快速筛掉明显对不上的请求。注意列表会更新，建议按周或按月重新拉一次，而不是抄下来长期使用。
验证的重点不是每个请求都查一遍，而是找出可疑样本并定期复核。全量校验既费时间，也没必要。
验证结果不同，处理方式也不同
- 确认是真蜘蛛：不要封。转而关注它的抓取频次、响应时间和状态码分布，看服务器是否拖慢了它。
- 确认是伪装请求：robots.txt 里的 UA 屏蔽只是君子协定，脚本完全可以忽略。真正起作用的是限速、WAF 规则、按 IP 或 IP 段拦截，必要时在 CDN 层处理。
- 暂时无法确认：先按普通访客对待，观察行为特征，别急着封整个 IP 段——共享 IP 和云服务出口很容易误伤。
几个容易踩的坑
- 把 CDN 回源 IP 或反向代理 IP 当成蜘蛛 IP。站点前面有 CDN 时，日志里记录的可能是节点地址，需要先还原真实来源。
- 只根据 UA 放行某些路径，等于给伪装者开了门。
- 误封真蜘蛛的 IP 段。一旦发生，表现是抓取量骤降、新页面长时间没人访问，排查起来很费时间。
- 把访问量大的第三方工具全部当成恶意流量。有些是正常的监控或站长工具，先看请求路径和行为再定性。
把验证做成常规动作
比较省事的做法是固定节奏：每周从日志里抽取一批蜘蛛请求，跑一遍反查与 IP 段比对，记录可疑 IP 的变化趋势。同时盯几个指标——整体抓取量、平均响应时间、5xx 比例。如果抓取量突然下降，先确认是不是自己把真蜘蛛挡在了门外，再去查其他原因。
总结一句：UA 是标签，不是证件。真正能说明身份的，是反向解析和官方 IP 段的交叉验证。把这个动作做熟之后，日志里的真假蜘蛛会变得容易分辨，服务器资源也不至于被白白消耗。