很多站点运营者會定期看訪問日誌，但日誌里寫着 Baiduspider、Googlebot、bingbot 的請求，並不一定来自真正的搜尋引擎。如果直接按 User-Agent 放行，可能把采集爬虫放進站内；如果一律拦截，又可能誤伤真蜘蛛，影响新 URL 的發現。身份核驗不是安全部门的专属工作，而是站点运营的基础自查項。
為什么只看 User-Agent 不够
User-Agent 是請求头里的一個字段，客戶端可以随意填寫。抓取脚本改一行字符串，就能把自己伪装成搜尋蜘蛛。只靠這個字段做判断，等于把门禁钥匙交给了来訪者自己。
- UA 字符串可以任意伪造，成本极低。
- 同一台机器可以轮換多個搜尋引擎的 UA。
- 部分第三方蜘蛛池會模拟搜尋引擎 UA 抓取頁面，日誌里看起来很像真蜘蛛。
- 真蜘蛛的 UA 也可能随版本變化，拿舊規則去匹配容易漏判。
可用的核驗维度
反向 DNS 與域名後缀
對訪問 IP 做反向解析，看主机名是否落在搜尋引擎官方域名下，例如 Googlebot 常见 crawl-xxx.googlebot.com 一類的主机名。更稳妥的做法是再做一次正向解析，確認能解析回同一個 IP。只做反向解析不够，因為反向记錄也可以被配置。
官方 IP 段清單
主流搜尋引擎通常會公布自己的抓取 IP 段。把這些網段整理成清單，定期與日誌中的来源 IP 比對。清單會更新，建议每季度复核一次，不要一份列表用几年。
請求行為特征
- 真蜘蛛一般會先讀取 robots.txt，再按連結關系抓取頁面。
- 抓取路径有一定規律，不會只盯着某個參數頁反复請求。
- 請求频率有波動，通常不會在短時間内拉取大量不存在的 URL。
- 伪装爬虫往往集中抓取列表頁、詳情頁，對静態资源和 robots.txt 兴趣不大。
日誌字段是否完整
核驗的前提是日誌里能拿到足够信息。至少應记錄客戶端 IP、User-Agent、請求時間、請求路径、狀態碼和响應字节數。如果站点前面有 CDN 或反向代理，還要確認日誌里保留的是真實客戶端 IP，而不是节点 IP。否則後續所有判断都會失真。
在服務器和 CDN 层怎么處理
建议先观察、再限速、最後才考虑拦截。直接按 UA 封禁，誤伤概率不低。
- 日誌按天切割，保留至少 30 天，方便回溯。
- 建立白名單前，先跑一段观察期，记錄哪些 IP 频繁来訪。
- 對可疑 IP 先做限速，而不是直接封禁，避免誤伤共享出口。
- 源站和 CDN、WAF 的規則要同步，只改一层容易出現策略不一致。
- 定期清理過期規則，尤其是已经不再使用的舊 IP 段。
核驗的目标不是简單地区分好坏，而是让放行和拦截都有可查的依據。
常见誤判
- 把真蜘蛛当成采集器封掉，導致新頁面長期不被發現。
- 把伪装蜘蛛当成搜尋引擎放行，占用带宽和抓取资源。
- 只核驗 UA，不核驗 IP 和反向解析，規則很容易被绕過。
- CDN 回源场景下，日誌里全是节点地址，無法判断真實来源。
- 封禁規則没有排除移動端和合作方抓取，影响正常訪問。
一個可执行的自查清單
- 日誌是否包含完整 UA 和真實客戶端 IP？
- 是否维護了主流搜尋引擎的 IP 段清單，並定期更新？
- 反向 DNS 是否做過正反双向驗證？
- 對可疑請求是限速還是直接封禁，規則是否寫在源站和 CDN 两层？
- 封禁規則上线前，是否用小流量驗證過？
- 多久复核一次抓取白名單和拦截名單？
最後提醒一句：身份核驗只是站点运营的一环。即使確認對方是真蜘蛛，抓取量、抓取路径和内容质量仍然需要持續观察。把日誌、規則和内容更新放在同一張表里看，才能判断問题到底出在识別、放行還是内容本身。