為什么入口頁要先分辨“来的是不是蜘蛛”
入口頁的日誌里，訪問者大致分三類：真搜尋引擎蜘蛛、伪装成蜘蛛的采集器與掃描器、以及普通用戶和自家监控。這三類的處理方式完全不同——给真蜘蛛更精简的頁面並记錄抓取节奏，對伪装流量不必特殊照顾，普通用戶則應该看到正常版本。如果混在一起統計，你會得到一份失真的資料：看着像是“蜘蛛天天来”，實际大部分請求来自掃描。
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 段規則，至少每季度检查一次；
- 监控“已確認蜘蛛”的抓取量趋势，而不是總請求量；出現異常先核對校驗規則是否失效，再看入口頁本身。
把這几步做扎實，入口頁的抓取记錄才有參考價值，後續的並發控制、内容分层和资源分配也才有依據。