日誌里出現大量带搜尋蜘蛛 UA 的請求，並不代表這些請求都来自搜尋引擎。区分真實蜘蛛與伪装流量，關系到带宽占用判断、日誌分析和後續屏蔽策略的方向。
為什么要先做 IP 核驗
UA 是請求方自己填寫的字段，任何脚本都能伪装。如果只凭 UA 判断，容易出現两種偏差：把伪装流量当成真實抓取，據此調整站点结构；或者把真實蜘蛛当成攻击流量屏蔽，導致入口長期不被訪問。IP 核驗不是萬能的，但它是把“声称”變成“可驗證”的第一步。
核驗的基本步骤
- 取日誌中的来源 IP，做反向 DNS 查询，查看是否落在官方公布的爬虫域名後缀下。
- 對反向解析得到的主机名再做一次正向解析，確認解析结果與原始 IP 一致。只做反向解析容易被伪造的 PTR 记錄绕過。
- 與官方公布的 IP 段列表比對，確認该 IP 确實属于该搜尋引擎的出口范围。
- 记錄核驗的時間点。IP 段會更新，几個月前的结论未必仍然成立。
反向解析、正向回查、IP 段比對，三步都通過才可基本認定為真實蜘蛛；只通過其中一步时，结论要保守一些。
日誌层面的分辨信号
除了 IP，行為特征也能提供參考：
- 請求节奏：真實抓取通常相對稳定，並遵守站点限速；伪装流量常表現為突發高並發或長時間均匀掃描。
- 路径偏好：抓取一般從已知入口向内延伸；掃描型流量更倾向于遍歷常见後台路径、配置文件與备份文件。
- 头部特征：Accept、Accept-Encoding、Referer 等字段是否符合浏览器或爬虫的常規形態。
- 错誤碼分布：大量 404、403 集中在非内容路径上，通常不是正常抓取行為。
容易誤判的几種情况
核驗過程中，有几類情况需要額外注意：
- CDN 回源：源站日誌里看到的可能是 CDN 节点 IP，而不是蜘蛛 IP。這種情况下需要在 CDN 日誌或回源头信息里取原始客戶端 IP。
- 共享出口與代理：部分抓取會经過代理或云服務出口，IP 归属查询结果可能落在云厂商網段，不能直接據此判定為伪装。
- IPv6 與双栈：同一蜘蛛可能同时使用 IPv4 與 IPv6，核驗时两條鏈路都要覆盖。
- 移動端與桌面端 UA：不同 UA 的抓取来源可能不同，混在一起統計會掩盖差异。
處理方式與记錄习惯
核驗後建议分成三類處理：確認的真實蜘蛛正常放行並保留日誌；確認的伪装流量按业務規則限速或拦截，但要留出回滚余地；暂时無法確認的先观察，不要急于封禁整段 IP。同时保留核驗的時間、方法和结论，便于後續复盘——搜尋引擎的 IP 段與爬虫域名會調整，一次性的判断很难長期有效。
把 IP 核驗当成日誌分析的常規环节，而不是一次性任務，能减少因誤判带来的两類损失：既不至于對伪装流量做過度調整，也不至于把真實抓取挡在门外。