入口站每天都会收到大量请求，其中不少请求的 UA 写着 Googlebot、Bingbot、Baiduspider。但 UA 是请求头里最容易改的一行，任何脚本都能把它伪装成搜索引擎的名字。如果只看 UA 来决定放行、限流还是封禁，日志会被污染，真蜘蛛也可能被一起挡住。
为什么 UA 不能作为唯一依据
UA 字符串没有签名，也不与来源 IP 绑定。用 curl 加一个 -A 参数，就能发出一个“Googlebot”请求。部分采集程序、扫描器甚至普通浏览器插件也会顺手借用搜索引擎的 UA。结果是：入口站看到大量“蜘蛛”，但其中真正来自搜索引擎的只是少数。
反过来，如果因为某段时间“蜘蛛”请求太多，就用 UA 关键词做全量拦截，搜索引擎的真实抓取也会被拒绝。入口页拿不到抓取，整个蜘蛛池的 URL 发现链条就会断掉。
可验证的三条线索
1. IP 段与 ASN
主流搜索引擎都会公布自己的爬虫 IP 段，通常以 JSON 或文本形式提供。把入口站的访问日志按 IP 聚合，再与官方 IP 段比对，是成本最低的一层筛选。不在公布范围内的 IP，即使 UA 写着搜索引擎，也只能当作普通访客处理。
比 IP 段更稳一点的是 ASN。部分搜索引擎的抓取 IP 会随云服务调整，但所属自治域相对固定。如果你的服务器或 CDN 支持按 ASN 放行，可以减少 IP 列表过期带来的误判。
2. 反向 DNS 正反查
反向 DNS 验证分两步：先对来源 IP 做 PTR 查询，看解析出的主机名是否属于搜索引擎官方域名；再对该主机名做一次正向解析，确认它解析回的 IP 与最初来源 IP 一致。两步都通过，才能基本确认对方不是随便指向一个域名的伪造者。
以 Googlebot 为例，官方建议检查 PTR 是否落在 googlebot.com 或 google.com 下，并做正向确认。Bingbot、Baiduspider 也有类似机制。反向解析可以放在限流层之前，也可以放进日志分析流程里离线核对。
3. 请求行为与频率
真蜘蛛的抓取行为通常有迹可循：会读取 robots.txt，会按 sitemap 或链接结构访问，单 IP 的请求间隔不会像压测工具那样密集。伪装流量往往集中在少数 URL 上反复请求，或者对静态资源和入口页一视同仁地猛抓。把行为特征和 IP 验证结合，判断会更有把握。
入口站的放行与限流建议
- 先验证再放行：对声称是搜索引擎的请求，先过 IP 段和反向解析，通过后再给较高配额。
- 保留日志字段：记录 IP、UA、请求时间、状态码和响应时间，方便事后核对，而不是只凭 UA 做实时拦截。
- 限流按 IP 而不是按 UA：按来源 IP 做频率限制，避免一个伪造 UA 拖慢整个入口站。
- 给验证结果留缓存：反向 DNS 查询有开销，对同一 IP 的验证结果可以短时间缓存，减少重复查询。
- 不要直接返回 403：对未通过验证的请求，可以用限速或返回空内容，而不是一律封禁，以免误伤使用共享出口的合法访客。
常见误区
- 把 UA 里的“spider”“bot”当成白名单关键词，结果放过了大量伪装请求。
- 只做了 PTR 查询，没有做正向确认，域名可以被人为指向伪造的主机名。
- 在 CDN 或反向代理后直接读连接 IP，读到的是回源节点地址，导致所有蜘蛛看起来都来自同一处。
- 把搜索引擎的验证 IP 段写死在配置里，长期不更新，新 IP 段上线后真蜘蛛被挡。
入口站不需要讨好所有爬虫，但至少要让真蜘蛛进得来、读得到。验证身份的意义不是追求零误判，而是把误判控制在可接受范围内。
把 UA、IP、反向解析和行为放在一起看，入口站对“谁来了”会清楚很多。蜘蛛池的入口资源是否有效，最终还是要回到日志里：真蜘蛛有没有来、来了之后读了多少、下一次还来不来。身份验证只是第一步，别让它变成挡住真蜘蛛的那道门。