为什么入口页要先分辨“来的是不是蜘蛛”
入口页的日志里，访问者大致分三类：真搜索引擎蜘蛛、伪装成蜘蛛的采集器与扫描器、以及普通用户和自家监控。这三类的处理方式完全不同——给真蜘蛛更精简的页面并记录抓取节奏，对伪装流量不必特殊照顾，普通用户则应该看到正常版本。如果混在一起统计，你会得到一份失真的数据：看着像是“蜘蛛天天来”，实际大部分请求来自扫描。
UA 校验：能筛掉一部分，但别当门锁
UA 是最省事的初筛手段，读一行日志就能判断，成本几乎为零。常见做法是匹配特征串，把带 Baiduspider、Googlebot、bingbot 等标识的请求先挑出来。
但 UA 可以随意伪造，一条命令就能把请求头写成 Baiduspider。所以 UA 只适合做粗分和统计口径，不适合作为放行或拒绝的唯一依据。
UA 校验常见的三个漏判
- 只匹配主标识，漏掉带后缀的变体，例如移动端 UA 或渲染型蜘蛛；
- 大小写、多余空格、括号里的注释部分导致匹配失败；
- 只按关键词包含判断，把第三方的测试工具、监控脚本也算成了蜘蛛。
IP 校验：反查加正查，两次解析才算确认
更可靠的方式是“反向解析 + 正向解析”配对验证，具体流程：
- 取请求的真实来源 IP；
- 做反向解析（PTR）得到主机名，看是否落在搜索引擎官方域名下，例如 *.baidu.com、*.googlebot.com、*.search.msn.com；
- 把主机名再正向解析一次，看结果是否与来源 IP 一致；
- 两次都一致才算通过，任何一步失败就按普通访客处理。
搜索引擎大多提供官方 IP 段列表，可以定期拉取并落地成本地规则，先做快速匹配，命中之后再走反查，能省掉大量 DNS 查询。
性能与缓存
反查是网络请求，单次几十毫秒很正常，蜘蛛集中抓取时容易成为瓶颈。把“IP → 判定结果”写进本地缓存，TTL 设几小时到一天即可；同时给 DNS 查询设超时，超时就按未通过处理，不要让页面卡在等待上。
识别出来之后，可以做什么
- 给通过校验的请求输出更精简的入口页，降低带宽和渲染压力；
- 单独统计抓取频率、抓取深度和返回码，判断入口页是否真的被走通；
- 在并发控制上把真蜘蛛和扫描器分开限速，避免伪装流量挤占配额；
- 保留采样日志，为误判留出人工复核的入口。
几个容易踩的坑
- 把 CDN 或反向代理的回源 IP 当成蜘蛛 IP：必须取到真实客户端 IP，否则校验必然失败；
- 校验失败就直接返回 403：网络抖动、DNS 超时都会造成误伤，建议降级为普通页面而不是拒绝；
- 忽略 IPv6：不少蜘蛛已有 IPv6 出口，规则里只写 IPv4 会漏掉一部分；
- 把识别结果当成收录保证：识别只解决“给谁看什么、怎么统计”，和收录之间没有直接因果关系。
识别蜘蛛的目的是把资源用在对的地方，而不是把门关得更紧。宁可放行一个伪装者，也不要拦掉一个真蜘蛛。
一份可落地的检查清单
- 日志至少保留：时间、IP、UA、请求 URL、返回码、响应时间、真实客户端 IP；
- UA 粗筛加 IP 反查正查，两级都通过才标记为已确认蜘蛛；
- 判定结果本地缓存，DNS 查询设超时并准备降级策略；
- 定期更新官方 IP 段规则，至少每季度检查一次；
- 监控“已确认蜘蛛”的抓取量趋势，而不是总请求量；出现异常先核对校验规则是否失效，再看入口页本身。
把这几步做扎实，入口页的抓取记录才有参考价值，后续的并发控制、内容分层和资源分配也才有依据。