很多站点运营者会定期看访问日志，但日志里写着 Baiduspider、Googlebot、bingbot 的请求，并不一定来自真正的搜索引擎。如果直接按 User-Agent 放行，可能把采集爬虫放进站内；如果一律拦截，又可能误伤真蜘蛛，影响新 URL 的发现。身份核验不是安全部门的专属工作，而是站点运营的基础自查项。
为什么只看 User-Agent 不够
User-Agent 是请求头里的一个字段，客户端可以随意填写。抓取脚本改一行字符串，就能把自己伪装成搜索蜘蛛。只靠这个字段做判断，等于把门禁钥匙交给了来访者自己。
- UA 字符串可以任意伪造，成本极低。
- 同一台机器可以轮换多个搜索引擎的 UA。
- 部分第三方蜘蛛池会模拟搜索引擎 UA 抓取页面，日志里看起来很像真蜘蛛。
- 真蜘蛛的 UA 也可能随版本变化，拿旧规则去匹配容易漏判。
可用的核验维度
反向 DNS 与域名后缀
对访问 IP 做反向解析，看主机名是否落在搜索引擎官方域名下，例如 Googlebot 常见 crawl-xxx.googlebot.com 一类的主机名。更稳妥的做法是再做一次正向解析，确认能解析回同一个 IP。只做反向解析不够，因为反向记录也可以被配置。
官方 IP 段清单
主流搜索引擎通常会公布自己的抓取 IP 段。把这些网段整理成清单，定期与日志中的来源 IP 比对。清单会更新，建议每季度复核一次，不要一份列表用几年。
请求行为特征
- 真蜘蛛一般会先读取 robots.txt，再按链接关系抓取页面。
- 抓取路径有一定规律，不会只盯着某个参数页反复请求。
- 请求频率有波动，通常不会在短时间内拉取大量不存在的 URL。
- 伪装爬虫往往集中抓取列表页、详情页，对静态资源和 robots.txt 兴趣不大。
日志字段是否完整
核验的前提是日志里能拿到足够信息。至少应记录客户端 IP、User-Agent、请求时间、请求路径、状态码和响应字节数。如果站点前面有 CDN 或反向代理，还要确认日志里保留的是真实客户端 IP，而不是节点 IP。否则后续所有判断都会失真。
在服务器和 CDN 层怎么处理
建议先观察、再限速、最后才考虑拦截。直接按 UA 封禁，误伤概率不低。
- 日志按天切割，保留至少 30 天，方便回溯。
- 建立白名单前，先跑一段观察期，记录哪些 IP 频繁来访。
- 对可疑 IP 先做限速，而不是直接封禁，避免误伤共享出口。
- 源站和 CDN、WAF 的规则要同步，只改一层容易出现策略不一致。
- 定期清理过期规则，尤其是已经不再使用的旧 IP 段。
核验的目标不是简单地区分好坏，而是让放行和拦截都有可查的依据。
常见误判
- 把真蜘蛛当成采集器封掉，导致新页面长期不被发现。
- 把伪装蜘蛛当成搜索引擎放行，占用带宽和抓取资源。
- 只核验 UA，不核验 IP 和反向解析，规则很容易被绕过。
- CDN 回源场景下，日志里全是节点地址，无法判断真实来源。
- 封禁规则没有排除移动端和合作方抓取，影响正常访问。
一个可执行的自查清单
- 日志是否包含完整 UA 和真实客户端 IP？
- 是否维护了主流搜索引擎的 IP 段清单，并定期更新？
- 反向 DNS 是否做过正反双向验证？
- 对可疑请求是限速还是直接封禁，规则是否写在源站和 CDN 两层？
- 封禁规则上线前，是否用小流量验证过？
- 多久复核一次抓取白名单和拦截名单？
最后提醒一句：身份核验只是站点运营的一环。即使确认对方是真蜘蛛，抓取量、抓取路径和内容质量仍然需要持续观察。把日志、规则和内容更新放在同一张表里看，才能判断问题到底出在识别、放行还是内容本身。