為什么 User-Agent 不足以判断来源

User-Agent 只是請求头里的一段字符串，客戶端可以随意填寫。任何脚本都能把它改成搜尋引擎蜘蛛的名字。所以当訪問日誌里出現大量带蜘蛛 UA 的請求时，先別急着下结论——這些請求可能来自搜尋引擎，也可能来自监控脚本、采集工具、第三方代理，甚至是被放大的恶意請求。把它直接当成真實抓取量来做运营判断，容易得出错誤结论。

三種可以交叉使用的核驗方式

反向 DNS 與正向確認

主流搜尋引擎通常會给出来源驗證方法。常见做法是：先對来訪 IP 做一次反向 DNS 查询（PTR），得到主机名；再對這個主机名做一次正向解析，確認它解析回的是同一個 IP；最後检查主机名的域名後缀是否属于官方域名。這几步同时满足，才有理由認為来源可信。只看 UA，或者只做第一步而不看後缀，都不够。

官方 IP 段比對

部分搜尋引擎會公布抓取所用的 IP 段列表，並定期更新。把訪問日誌里的 IP 與這份列表比對，是成本較低的做法。需要注意的是列表會變，建议寫成定时任務而不是一次性對照；同时要保留比對结果，避免某次誤判之後長期把某個網段封掉。

行為特征與日誌交叉

真實的搜尋蜘蛛通常有几個特征：請求集中在站点的主要路径上，會顺着連結结构逐层推進，對相同 URL 有相對稳定的回訪节奏，抓取时段的分布也比較規律。而伪造来源的請求往往集中在少數動態接口、带參數的地址，或者干脆是全站掃描，請求間隔极短，UA 與行為並不匹配。把 UA、IP 與請求路径、频率放在一起看，判断會稳得多。

誤封真蜘蛛的代價

反過来，把真蜘蛛当成攻击流量挡掉，代價同样不小。表現通常不是立刻掉量，而是新的 URL 迟迟進不了抓取队列，已收錄頁面的回訪變慢，站内层級較深的頁面逐渐被忽略。這種變化是缓慢的，很多人會先去排查内容或内鏈，反而忽略了服務器侧的拦截規則。所以每次調整 WAF、限速或防火墙策略之後，都值得留一段時間观察蜘蛛請求的到達情况，再决定是否繼續收紧。

蜘蛛池场景下的一個常见誤区

在做 URL 發現或抓取观察时，有些站点會借助蜘蛛池来增加日誌里的抓取痕迹。這里要分清两件事：日誌中出現更多請求，不等于搜尋引擎對你的站点有了更高的抓取意愿；判断抓取是否健康，仍然要看真實来源的請求量、抓取路径覆盖和回訪間隔。如果統計时把模拟 UA 的請求也算進去，資料會被高估，後續的調整方向也會跟着偏。核驗来源的第一步，就是先把這部分請求筛出去。

可以落地的检查清單

• 把 UA、IP、請求路径、响應狀態寫進同一份日誌，方便交叉比對。
• 對高频来源做反向 DNS 加正向確認，並记錄驗證结果，而不是只信 UA。
• 官方 IP 段列表定期更新，比對脚本定时跑。
• 調整防火墙或限速規則後，观察一段時間内真蜘蛛的請求到達率。
• 区分真實抓取與模拟請求，統計口径前後保持一致。

核驗来源的目的不是把請求挡在外面，而是让判断建立在真實資料上。挡错和放错，都會让後續的抓取優化失去參照。