入口站每天都會收到大量請求，其中不少請求的 UA 寫着 Googlebot、Bingbot、Baiduspider。但 UA 是請求头里最容易改的一行，任何脚本都能把它伪装成搜尋引擎的名字。如果只看 UA 来决定放行、限流還是封禁，日誌會被污染，真蜘蛛也可能被一起挡住。
為什么 UA 不能作為唯一依據
UA 字符串没有簽名，也不與来源 IP 绑定。用 curl 加一個 -A 參數，就能發出一個“Googlebot”請求。部分采集程序、掃描器甚至普通浏览器插件也會顺手借用搜尋引擎的 UA。结果是：入口站看到大量“蜘蛛”，但其中真正来自搜尋引擎的只是少數。
反過来，如果因為某段時間“蜘蛛”請求太多，就用 UA 關鍵詞做全量拦截，搜尋引擎的真實抓取也會被拒绝。入口頁拿不到抓取，整個蜘蛛池的 URL 發現鏈條就會断掉。
可驗證的三條线索
1. IP 段與 ASN
主流搜尋引擎都會公布自己的爬虫 IP 段，通常以 JSON 或文本形式提供。把入口站的訪問日誌按 IP 聚合，再與官方 IP 段比對，是成本最低的一层篩選。不在公布范围内的 IP，即使 UA 寫着搜尋引擎，也只能当作普通訪客處理。
比 IP 段更稳一点的是 ASN。部分搜尋引擎的抓取 IP 會随云服務調整，但所属自治域相對固定。如果你的服務器或 CDN 支持按 ASN 放行，可以减少 IP 列表過期带来的誤判。
2. 反向 DNS 正反查
反向 DNS 驗證分两步：先對来源 IP 做 PTR 查询，看解析出的主机名是否属于搜尋引擎官方域名；再對该主机名做一次正向解析，確認它解析回的 IP 與最初来源 IP 一致。两步都通過，才能基本確認對方不是随便指向一個域名的伪造者。
以 Googlebot 為例，官方建议检查 PTR 是否落在 googlebot.com 或 google.com 下，並做正向確認。Bingbot、Baiduspider 也有類似机制。反向解析可以放在限流层之前，也可以放進日誌分析流程里离线核對。
3. 請求行為與频率
真蜘蛛的抓取行為通常有迹可循：會讀取 robots.txt，會按 sitemap 或連結结构訪問，單 IP 的請求間隔不會像压测工具那样密集。伪装流量往往集中在少數 URL 上反复請求，或者對静態资源和入口頁一视同仁地猛抓。把行為特征和 IP 驗證结合，判断會更有把握。
入口站的放行與限流建议
- 先驗證再放行：對声称是搜尋引擎的請求，先過 IP 段和反向解析，通過後再给較高配額。
- 保留日誌字段：记錄 IP、UA、請求時間、狀態碼和响應時間，方便事後核對，而不是只凭 UA 做實时拦截。
- 限流按 IP 而不是按 UA：按来源 IP 做频率限制，避免一個伪造 UA 拖慢整個入口站。
- 给驗證结果留缓存：反向 DNS 查询有開销，對同一 IP 的驗證结果可以短時間缓存，减少重复查询。
- 不要直接返回 403：對未通過驗證的請求，可以用限速或返回空内容，而不是一律封禁，以免誤伤使用共享出口的合法訪客。
常见誤区
- 把 UA 里的“spider”“bot”当成白名單關鍵詞，结果放過了大量伪装請求。
- 只做了 PTR 查询，没有做正向確認，域名可以被人為指向伪造的主机名。
- 在 CDN 或反向代理後直接讀连接 IP，讀到的是回源节点地址，導致所有蜘蛛看起来都来自同一處。
- 把搜尋引擎的驗證 IP 段寫死在配置里，長期不更新，新 IP 段上线後真蜘蛛被挡。
入口站不需要讨好所有爬虫，但至少要让真蜘蛛進得来、讀得到。驗證身份的意义不是追求零誤判，而是把誤判控制在可接受范围内。
把 UA、IP、反向解析和行為放在一起看，入口站對“谁来了”會清楚很多。蜘蛛池的入口资源是否有效，最终還是要回到日誌里：真蜘蛛有没有来、来了之後讀了多少、下一次還来不来。身份驗證只是第一步，別让它變成挡住真蜘蛛的那道门。