入口頁上线之後，日誌里很快會出現各種訪問。這里面有搜尋引擎的爬虫，也有采集程序、监控探针、安全掃描器，還有一部分會把 UA 直接寫成搜尋引擎的名稱。如果不做核驗，把伪装請求当成爬虫来統計，最後得到的“抓取量”會明顯虚高，判断入口頁是否被正常抓取也會跑偏。
為什么只看 UA 不可靠
UA 是請求头里的一個字符串，客戶端想寫什么就寫什么。伪装成常见爬虫的 UA 成本极低，而不少統計工具預設按 UA 归類。所以 UA 可以作為第一层筛子，用来把明顯不相關的流量分出去，但不宜作為判定身份的依據。
三层核驗思路
第一层：IP 归属與 ASN
先看請求来源 IP 落在哪個網段、属于哪個 ASN。主流搜尋引擎通常會公布自己的爬虫 IP 段，或提供官方反查渠道，以官方文档為准去比對，比凭经驗记几個 IP 開头可靠得多。注意两点：一是 IP 段會更新，核驗規則要定期复核；二是同一段 IP 也可能被云服務商复用，所以归属匹配只能算“可能是”。
第二层：反向解析與正向確認
對可疑 IP 做反向 DNS 解析，看主机名是否落在搜尋引擎自有域名下；再把解析出来的主机名做一次正向解析，確認能指回原 IP。這就是常说的 forward-confirmed 反查。只有反向、正向都自洽，可信度才明顯提升。反查有額外開销，建议對采样日誌或首次出現的 IP 做，而不是每個請求都查。
第三层：請求行為特征
- 抓取节奏：真爬虫通常有相對稳定的並發與間隔，不會瞬間打满你的连接數。
- 路径分布：真爬虫會顺着入口頁的出鏈走，采集脚本往往只盯固定模板或參數组合。
- 請求头完整度：Accept、Accept-Encoding、Referer 等字段的组合方式，常能暴露差异。
- 對 robots.txt 的訪問：不少搜尋引擎爬虫會先取一次 robots.txt，但這不是硬性證據，只能作為參考。
常见誤区
- 按 UA 一刀切封禁。誤封真爬虫的代價是入口頁長期不被抓取，恢复周期不好估。
- 只查一次就長期信任。IP 與規則都會變，静態白名單迟早失效。
- 把所有高频請求都当恶意。爬虫在發現新入口頁时确實可能短时集中抓取，先看整体分布再决定是否限速。
- 用反查结果直接封 IP。共享出口 IP 的场景下，封禁可能波及正常用戶。
實操建议
- 日誌里同时记錄 UA、IP、狀態碼、响應時間與請求路径，方便後續關联分析。
- 把核驗结果分成“放行 / 观察 / 限速”三档，而不是只有放行和封禁两档。
- 對確認身份的搜尋引擎爬虫不设過嚴的频率限制；對無法確認身份的請求，用限速、驗證等方式降低影响。
- 定期复核 IP 段與反查規則，例如每月更新一次白名單。
- 關注趋势而不是單日數字：抓取量突然翻倍或归零，都值得查一查是不是核驗环节出了問题。
核驗的目的不是把谁挡在外面，而是让你對“哪些請求值得信任”有一個可解释的判断，從而在統計抓取质量和調整入口頁时不被虚假資料带偏。
把這三层核驗跑顺之後，你會發現很多原本看起来“抓取很好”的入口頁，實际有效抓取並没有那么多；也會發現一些被忽略的入口頁其實一直被稳定訪問。基于更接近真實的判断去做調整，节奏會稳得多。