看日誌时很容易产生一種错觉：只要 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 段的交叉驗證。把這個動作做熟之後，日誌里的真假蜘蛛會變得容易分辨，服務器资源也不至于被白白消耗。