一個 AI 代理剛剛造訪你的網站，你如何確認它是真的？
寫著 GPTBot 的 User-Agent 證明不了任何事。本文說明如何真正驗證 AI 代理：官方公布的 IP 段、反向 DNS 與 ASN 核對，以及如何為未通過驗證的流量分類。
一個 AI 代理剛剛請求了一個頁面，日誌上寫著 GPTBot/1.2。這串文字並非證據。User-Agent 由客戶端自行
寫入，任何人都能發送，因此驗證 AI 代理唯一可靠的途徑，是核對它發起連線所用的位址。真正發揮作用的檢查
只有三種：把來源 IP 與營運方公布的 IP 段檔案比對、執行正向確認的反向 DNS 查詢，或確認該 IP 由營運方
本身的 ASN 通告。
究竟適用哪一種，完全取決於營運方，而這正是麻煩之處。OpenAI 按 bot 分別公布 JSON 格式的 IP 段檔案； Anthropic 只公布單一前綴檔案，同時涵蓋 ClaudeBot、Claude-User 與 Claude-SearchBot；Apple 既支援反向 DNS，亦提供 IP 段檔案；Meta 兩者皆無，預設由你自行核對 AS32934。另有相當一部分爬蟲什麼都不公布，此時 標頭中的名稱只是裝飾，你只能依據來源與行為作判斷。
聲稱不用成本，核驗才有成本
不妨想想「User-Agent 含有 GPTBot 就略過機器人規則」這樣一條放行規則究竟代表什麼。它等於宣告：任何願意 輸入九個字元的客戶端，都能取得你原本只保留給可信爬蟲的待遇。爬蟲會讀你的 robots.txt，看清楚你歡迎哪些 代理，然後照樣裝扮。這種冒充談不上高明，只是成本極低，而且對任何從不查看標頭以外資訊的網站都行得通。
核驗的代價則高得多。你需要營運方目前的 IP 段、一個 DNS 解析器或路由資料，逐家維護，並在對方變更時同步 更新。已有研究者報告過自稱 PerplexityBot、卻來自 Perplexity 公布範圍以外位址的流量。這正是典型的失效 情況：名稱是借來的，網絡不是。
查詢某個代理請求實際來自哪個網絡
每一家營運方的文件都不一樣
這件事沒有統一標準，驗證只能逐家查。以下是AI 爬蟲目錄中的一部分，該目錄收錄了 150 個代理：
| 代理 | 營運方 | 公布內容 | 驗證方式 |
|---|---|---|---|
| GPTBot | OpenAI | openai.com/gptbot.json | 比對 IP 段，無反向 DNS 慣例 |
| ClaudeBot | Anthropic | claude.com/crawling/bots.json | 比對 IP 前綴，單一檔案涵蓋 Anthropic 所有 bot |
| PerplexityBot | Perplexity | perplexitybot.json | 比對 IP 段，已出現冒充個案 |
| Applebot | Apple | IP 段檔案與 rDNS | 反向 DNS 解析至 applebot.apple.com，並正向確認 |
| Amazonbot | Amazon | 反向 DNS 慣例 | 正向確認的反向 DNS，無 IP 段檔案 |
| Meta-ExternalAgent | Meta | 未按 bot 公布 | 確認該 IP 由 AS32934 通告 |
| Bytespider | ByteDance | 無 | 無法驗證，且無視 robots.txt |
| CCBot | Common Crawl | 無可用資料 | 無法驗證，運行於租用的雲端資源 |
| Google-Extended | 僅 robots 權杖 | 無從驗證，它從不作為 User-Agent 出現 |
Google-Extended 值得多看一眼，因為它打破了一般人的認知模型。它是一條用於退出 Gemini 訓練的 robots.txt 指令，而非爬蟲。若收到自稱 Google-Extended 的請求，按定義即屬偽造，因為根本不存在真實版本。
在目錄收錄的 150 個代理之中，有 33 個提供了可用的核驗方式，即公布的 IP 段、反向 DNS 或 ASN；有 9 個被 明確記錄為無視 robots.txt。其餘的則處於中間地帶：只有一個名稱，卻沒有任何東西為它背書。
冒充在你的日誌裡是什麼模樣
兩條請求，標頭完全相同，相隔數分鐘：
198.51.100.7 "Mozilla/5.0 ...; compatible; GPTBot/1.2; +https://openai.com/gptbot"
203.0.113.44 "Mozilla/5.0 ...; compatible; GPTBot/1.2; +https://openai.com/gptbot"
單看日誌行毫無分別。把位址解析出來，差異立即顯現：其一落在 OpenAI 公布的出口 IP 段之內，另一則由一家按 小時出租伺服器的主機商通告。後者還在九十秒內請求了 400 個產品頁，而且從未載入任何樣式表，遵守本身公布 抓取配額的爬蟲不會如此。
同樣的模式在各家營運方身上反覆出現：來自 VPS 網段的假 ClaudeBot；PTR 記錄指向主機商網域、甚至完全沒有 PTR 記錄的假 Applebot；PTR 看似合理、正向解析卻傳回另一個位址的假 Amazonbot，而正向確認這一步存在的 意義正在於此。每一次，標頭都完全吻合，網絡卻對不上。
已驗證、無法驗證與惡意，是三種不同的答案
一旦不再把標頭當作證據，流量便會分成幾類需要區別對待的群組，而二元的機器人標記無法表達這種差異。
已驗證的 AI 爬蟲屬於政策選擇：放行、計費，或按名稱封鎖，因為你不希望內容進入那份語料。聲稱某個身份卻未 通過 IP 核驗的請求則不是政策問題，而是偽造，絕不應繼承真實代理所享有的存取權限。完全沒有公布任何資料的 爬蟲無法驗證，需要的是限速而非判定。至於來自資料中心網段、根本不 聲稱任何 bot 名稱的無頭瀏覽器，正是你的放行名單從未留意的那一類。
正因如此，Agentscan 傳回的是類別而非布林值。每個請求都會得到 human、known_bot、
ai_agent 或 malicious_automation 其中之一，並附上信心值以及形成該判定的各項訊號。
偽造 User-Agent 也騙不過的訊號
IP 來源能回答大部分問題，但並非全部。代理可以運行在住宅位址上，爬蟲亦可以租用一個沒有歷史紀錄的乾淨 IP。 當標頭說謊時，還有三類訊號站得住腳：
JA4 TLS 指紋。 客戶端在發送第一個標頭之前，已經暴露了自己如何進行 TLS 交握：加密套件順序、擴充、 ALPN、版本。一個自稱 Chrome 124 的 Python 腳本，產生的交握特徵是任何 Chrome 版本都不會產生的。標頭是 聲稱，交握是行為。
無頭瀏覽器痕跡。 webdriver 標記、缺失的瀏覽器介面，以及 Playwright、Puppeteer 或原生 HeadlessChrome
留下的自動化標記。單獨來看每一項都很弱，但與資料中心來源疊加後，畫面便不再含糊。
標頭一致性。 真實瀏覽器會成組發送 Accept、Accept-Language 與 Accept-Encoding，順序穩定，並與所聲稱的 版本相符。人手構造的請求物件往往只發送其中一部分，而這些缺口足夠規律，可以作為訊號使用。
任何一項訊號都不足以單獨定案，而這正是重點所在。唯有把它們融合起來，才能把已驗證的爬蟲與技術嫻熟的冒充者 分開，並把兩者與一般訪客分開。同樣的疊加邏輯亦適用於更早期的爬蟲，詳見 如何驗證 Googlebot。
一套經得起真實流量考驗的政策
驗證只有在其後產生動作時才有意義。一個可行的預設方案：
- 在任何放行規則生效之前，先按該營運方的方法核驗身份。 IP 段檔案、反向 DNS 抑或 ASN，視乎對方公布了 什麼。
- 核驗失敗不是模糊訊號。 自稱 ClaudeBot 卻來自 Anthropic 前綴以外的請求就是冒充。應按未知爬蟲處理， 而非視為有待商榷的個案。
- 按用途拆分放行決策。 訓練爬蟲、AI 搜尋爬蟲與助理取頁請求應各有規則。封鎖搜尋爬蟲會令你從該引擎引用 的答案中消失，這是流量決策，而非保安決策。
- 對無法驗證的流量限速。 對 Bytespider、CCBot 以及其他未公布核驗方式的代理，名稱說明不了任何事，但 請求頻率、路徑模式與來源卻能說明很多。
- 記錄類別，而不只是封鎖數。 知道 AI 代理流量上月增長了兩倍，比一個封鎖計數器有價值得多，尤其在你仍 須決定把哪一部分變現的時候。
Agentscan 以一次 POST /v1/agentscan/check 完成上述工作：經反向 DNS 驗證的放行名單、公布 IP 段比對、IP
來源、無頭標記與 JA4 全部在單次呼叫中處理，並設有快取，重複查詢可在 50 毫秒內傳回。這個速度足以放進
middleware，而不必留給夜間的日誌檢討。
總結
你無法憑一個代理的自稱去驗證它。把來源 IP 與營運方真正公布的資料比對，把核驗失敗視為偽造，再以 JA4、無頭 痕跡與 IP 來源判斷放行名單無法擔保的其餘流量。問題從來不是「這是不是機器人」，而是剛剛抵達的屬於四類流量 中的哪一類，以及你打算如何對待每一類。