服務器日誌里出現带 Googlebot、Bingbot、Baiduspider 字样的請求，並不等于搜尋引擎真的来了。User-Agent 只是一個客戶端自报的字符串，任何脚本都能原样複製。對站点来说，做蜘蛛驗證主要為了两头：一头是別把真蜘蛛誤封，另一头是別让伪装成蜘蛛的采集器把连接數和带宽吃光。
只認 User-Agent 會出什么問题
把 UA 当成唯一判據，通常會出現两種誤判。一種是放行：随便一個爬虫脚本改掉 UA，就能绕過频率限制，反复抓列表頁和搜尋接口。另一種是誤伤：某些正常来源的請求恰好带着相似字符串被一刀切掉，或者反過来把真蜘蛛限得太死，抓取量掉下去却找不到原因。
三层核對：UA、反向 DNS、IP 归属
比較稳妥的做法是按顺序做三次核對，任何一层不通過就当作普通訪客處理。
第一步：UA 與来源 IP 是否對得上
搜尋引擎官方爬虫的 UA 里通常带有自己的标识和說明連結，同时来源 IP 會落在官方公布的地址段内。UA 寫着 Googlebot 但 IP 属于某個 IDC 或代理池，基本可以判定為伪装。
第二步：反向解析，再正向核對一次
對来源 IP 做反向 DNS，看域名是否属于官方爬虫域名；拿到域名後再做一次正向解析，確認解析结果與原始 IP 一致。只做反向解析容易被伪造的 PTR 记錄骗過，正向回查能补上這一环。
第三步：確認地址段是否在官方公布范围内
搜尋引擎會發布自己的抓取 IP 段列表，並定期更新。把這三步组合起来，誤判率會低很多，代價是要维護一份地址段清單和少量缓存。
在日誌和服務器配置里怎么落地
- 保留完整訪問日誌：来源 IP、UA、請求路径、狀態碼、响應時間，判断抓取異常时這几項缺一不可。
- 给驗證過的蜘蛛單獨打标簽，再按标簽做限流，而不是拿 UA 字符串做正則匹配。
- 把驗證逻辑放在 CDN 或網關层，避免每個應用進程重复解析 DNS。
- DNS 查询要有缓存和超时，解析失敗时按普通訪客對待，不要直接拒绝，否則一次 DNS 抖動就可能誤伤。
假蜘蛛常留下的痕迹
伪装爬虫的行為特征通常比 UA 更明顯：
- 抓取节奏非常均匀，間隔几乎没有波動，像固定 sleep 的脚本；
- 只抓有資料價值的接口或列表頁，不請求静態资源；
- 無视 robots.txt 里声明的限制路径；
- 並發數遠超正常抓取，且集中在少數几個 IP 上；
- 来源 IP 分散在同一机房段，UA 却在多個名稱之間切換。
以上只是概率性线索，不能單獨作為封禁依據。先限速、观察一段時間，再决定是否長期拦截，比直接拉黑更安全。
限流與白名單的顺序
- 先驗證，再打标簽，最後才落實限流策略，顺序颠倒容易誤伤正常抓取。
- 對驗證通過的蜘蛛给合理並發上限，而不是完全放開；服務器扛不住时優先降速，而不是回 403。
- 對未驗證的請求按普通訪客處理，用频率限制和资源配額控制消耗。
- 定期复查規則：地址段會變，官方爬虫域名也會調整，寫死的正則總有一天會失效。
蜘蛛驗證不是一次配置就完事的工作，它更像日誌分析的一部分。把 UA、反向 DNS、IP 段三层核對固定成流程，再结合日誌里的抓取路径與响應時間一起看，才能在保護服務器的同时，不让真正的搜尋蜘蛛吃閉门羹。