怎麼確認來的真的是 GPTBot？2026 爬蟲身分驗證三關卡

Q: Q: 官方 IP 清單多久更新一次？我要多久同步一次？

A: 各家差很多。2026-08-05 實測時，GPTBot 清單的 creationTime 是 2025-10-30、九個月沒動；ChatGPT-User 卻在實測當天更新，而且我們前後兩次呼叫間隔數分鐘，網段數就從 290 變成 289。建議一律走自動同步、每日執行，並在筆數異常變動時中止落地並告警，不要手工維護。

8/5/202637 min 分鐘閱讀

#GPTBot#ClaudeBot#AI 爬蟲#User-Agent#反向 DNS#FCrDNS#Cloudflare#Verified Bots#WAF#Bot 管理

怎麼確認來的真的是 GPTBot？三道關卡驗證 AI 爬蟲身分

2026-08-05 這天，我們把四份官方爬蟲 IP 清單一次抓下來數過。OpenAI 的訓練爬蟲 GPTBot 只用 21 個網段，而使用者觸發的 ChatGPT-User 用了 289 個。同一家公司、同一個網站，兩份清單的規模差了十幾倍。

差這麼多，代表什麼？代表「AI 爬蟲」根本不是單一一種流量，而你在 log 裡看到的那串 User-Agent，說到底只是一個字串。它可以是真的，也可以是任何人手打的。

所以要驗證 GPTBot 真假，比對 UA 這件事本身完全不夠用。這篇文章講的是請求進到你伺服器之後、怎麼把「它說它是誰」變成「它確實是誰」——三道關卡：官方 IP 清單比對、反向 DNS 雙向驗證、Cloudflare Verified Bots 的兩條門檻。文中所有數字都是 2026-08-05 當天實際打出來的，附可重現指令，而且這些值會變，你照著跑一次拿到的可能跟我寫的不一樣。那正是重點之一。

文章主視覺，說明一則網路請求要通過三層檢查才算確認身分

圖說：一則請求要依序通過三道關卡——官方 IP 清單、反向 DNS 雙向驗證、行為門檻——才算完成身分確認

重點摘要

UA 不是身分：User-Agent 由請求端自己填寫，伺服器沒有任何機制可以否證它，比對 UA 只是讀對方的自我宣告——連 robots.txt 的標準 RFC 9309 都直接寫著「Crawlers set their own name」（§2.2.1）
一個可重現的實測（2026-08-05）：同一個 https://claude.com/crawling/bots.json，只換 User-Agent，Python-urllib/3.13 拿到 403、curl/8.7.1 與 Chrome UA 拿到 200——Anthropic 的爬蟲 IP 清單自己就被 bot 防護擋著
四份官方清單的規模差距（2026-08-05 實測）：GPTBot 21 個網段、OAI-SearchBot 35 個、ChatGPT-User 289 個、Anthropic 三隻 bot 共用的清單 20 個（其中 19 個是 /32 單一 IP）
第一道關卡是 IP 清單比對，只對有公布清單的爬蟲有效；第二道是反向 DNS（FCrDNS）雙向驗證，正解反解各做一次，缺一步就會被自訂 PTR 記錄騙過去
Cloudflare Verified bots 文件（頁面標示 Last updated 2026-07-01）的兩條門檻：誠實自我識別、非濫用行為；UA 命中已知 bot 但來源無法驗證，會被標記為 fake bot
「未驗證」不等於「惡意」：處置端要留限流與人工複核的出口，直接封鎖的風險是擋掉真的

User-Agent 只是一個可以任意填的字串：為什麼 UA 比對不算驗證

User-Agent 是請求端在 HTTP 標頭裡自己寫上去的一行字，伺服器只能照收，沒有任何辦法否證。這是協定設計本身的性質，不是某家實作的疏漏。所以「我說我是 GPTBot」跟「我是 GPTBot」之間，隔的不是一道弱驗證，而是根本沒有橋。

這句話有正式規格背書。robots.txt 的標準是 IETF 的 RFC 9309「Robots Exclusion Protocol」（Standards Track，2022 年 9 月），它的第 2.2.1 節開宗明義寫著「Crawlers set their own name, which is called a product token」——爬蟲的名字是它自己取的。標準對這個名字的唯一要求也只是「SHOULD be a substring of the identification string that the crawler sends to the service」，也就是它應該是自己送出那串 UA 的子字串。整條規則鏈上，沒有任何一步需要第三方確認。同一份文件第 1 節還補了一句更硬的：「These rules are not a form of access authorization.」

你可能覺得這句話太理論。那我們換個方式示範：不是示範怎麼假冒，而是示範「UA 這個字串的威力有多大」。

一個你現在就能自己跑的實測（2026-08-05）

我們在 2026-08-05 這天做了一件很單純的事——對同一個網址發三次請求，網址一個字都不改，只換 User-Agent。網址是 https://claude.com/crawling/bots.json，也就是 Anthropic 官方公布自家爬蟲 IP 範圍的那份清單。

結果如下：

User-Agent	HTTP 狀態碼
`Python-urllib/3.13`	403
`curl/8.7.1`	200
`Mozilla/5.0 ... Chrome/128.0 Safari/537.36`	200

（2026-08-05 實測，來源：https://claude.com/crawling/bots.json）

重現指令三行，你可以直接貼進終端機：

curl -s -o /dev/null -w "%{http_code}\n" \
  -A "Python-urllib/3.13" https://claude.com/crawling/bots.json
# 403

curl -s -o /dev/null -w "%{http_code}\n" \
  -A "curl/8.7.1" https://claude.com/crawling/bots.json
# 200

curl -s -o /dev/null -w "%{http_code}\n" \
  -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36" \
  https://claude.com/crawling/bots.json
# 200

不想用 curl 也行，直接用 Python 標準庫跑，會更貼近真實情境：

import urllib.request, urllib.error

# 不設 User-Agent：urllib 會送出預設的 Python-urllib/<版本>
try:
    urllib.request.urlopen("https://claude.com/crawling/bots.json", timeout=20)
except urllib.error.HTTPError as e:
    print("HTTPError", e.code)      # → HTTPError 403

# 顯式設一個自己的 User-Agent
req = urllib.request.Request(
    "https://claude.com/crawling/bots.json",
    headers={"User-Agent": "MyCompany-BotListSync/1.0"},
)
print(urllib.request.urlopen(req, timeout=20).status)   # → 200

同一份檔案、同一個伺服器、同一個時間點，唯一的變數是那行字。這件事我們沒在其他地方看過有人寫，所以特別把重現步驟寫全，你可以自己驗一次再決定要不要相信。

這個實測真正說明的事

它說明的不是「Anthropic 的設定有問題」，而是一個更基本的道理：UA 既然能決定你被怎麼對待，它就同樣能被拿來假裝成別人。

一個字串如果重要到足以觸發放行或阻擋，那它就是一把鑰匙；而這把鑰匙的複製權，在敲門的人手上。把 UA 當驗證，等於把門鎖交給敲門的那個人自己保管。

這個結構在資安上有個更廣泛的名字，就是身分驗證與可否證性的問題——宣稱者提供的資訊，如果驗證方無法獨立查核，那就不構成驗證。這條原則在網站流量判定上成立，在 API 場景裡同樣成立，而且是被寫進弱點清單的等級：想看它在介接層怎麼出事，可以對照 OWASP API Security Top 10 的身分驗證失效項目；想從更基礎的角度理解可否證性為什麼是資安的地基，我們的資安完整指南有更完整的脈絡。

所以，怎麼判斷訪客是不是 bot、又是不是「它宣稱的那隻 bot」？答案只能來自請求端控制不了的東西。而它控制不了的東西只有兩樣：它從哪個 IP 來，以及那個 IP 在 DNS 上長什麼樣。

說明自我宣告與可查核事實之間沒有橋樑，因此比對 User-Agent 不構成身分驗證

圖說：左邊是請求端的自我宣告（User-Agent），右邊是伺服器能獨立查核的事實（來源 IP、DNS 記錄）；兩者之間本來就沒有橋

第一道門檻：比對官方公布的 IP 清單（2026-08-05 四家現況）

最直接的驗證方式是查來源 IP 有沒有落在官方公布的網段裡。OpenAI 與 Anthropic 都有公開這種清單，格式是 JSON，任何人都能抓。

我們在 2026-08-05 當天把四份清單全部抓下來數了一遍，結果如下。這些值會變動——尤其最後一欄的 creationTime，它就是清單自己標示的產生時間：

爬蟲	用途	清單網址	網段數	`creationTime`
GPTBot	訓練資料抓取	`https://openai.com/gptbot.json`	21	2025-10-30
OAI-SearchBot	搜尋索引	`https://openai.com/searchbot.json`	35	2026-01-02
ChatGPT-User	使用者觸發的即時抓取	`https://openai.com/chatgpt-user.json`	289〜290	2026-08-05 01:03
ClaudeBot／Claude-User／Claude-SearchBot（三隻共用同一份）	訓練／使用者觸發／搜尋	`https://claude.com/crawling/bots.json`	20（IPv4 20、IPv6 0，其中 19 個是 /32 單一 IP）	2026-05-01

（全部為 2026-08-05 實測。你自己跑得到的數字很可能不同——為什麼會不同、又該怎麼處理，就是本文〈抓官方清單這一步本身就會失敗〉要談的事。）

自己數一次的指令：

curl -s -A "curl/8.7.1" https://openai.com/gptbot.json | python3 -c \
  "import sys,json; d=json.load(sys.stdin); print(d['creationTime'], len(d['prefixes']))"

把網址換成另外三個，就能複製整張表。

三個能從這張表讀出來的東西

第一，訓練爬蟲的出口 IP 極穩定。GPTBot 那份清單的 creationTime 停在 2025-10-30，到我們實測那天已經九個月沒動過。這對維運方是好消息：白名單設一次可以撐很久。

第二，使用者觸發的流量出口高頻變動。ChatGPT-User 的清單就在我們實測那天更新，時間戳記精確到 2026-08-05 01:03。更誇張的是，我們前後兩次呼叫只隔了幾分鐘，網段數就從 290 變成 289。這種東西你手工抄一份進 WAF，隔天就過期了。

第三，兩家的網段風格不一樣，維護成本結構因此不同。OpenAI 三份清單走的是涵蓋一整段位址的網段（如 /24、/28）；Anthropic 那份 20 筆裡有 19 筆是 /32，也就是單獨一個 IP。差別在哪？網段那種寫法，供應商在自己的範圍內換機器，你的規則不用動；單點那種寫法，對方換一台你就得改一條。所以 Anthropic 這份清單的更新頻率雖然低（2026-05-01 之後就沒動），一旦動了，維護方式比較接近「整批換掉」而不是「調整範圍」。

順帶一提，這個「289 對 21」的規模落差不只是趣聞。它直接決定了手工維護白名單這條路走不走得通——我們在 AI Agent 自己上門時伺服器端要準備什麼這篇裡專門拆過這件事。

這道門檻的邊界在哪

IP 清單比對很乾淨，但它只對「有公布清單」的爬蟲有效。沒公布的怎麼辦？那就進不了這道關卡，得靠第二道。

還有一個實務前提常被忽略：既然清單會變，你就必須自動同步。而同步這件事，正是 Anthropic 那份清單埋著的坑。

抓官方清單這一步本身就會失敗：Python 標準庫的靜默 403

回到 Anthropic 清單那個 403。它不是趣味冷知識，它是一個會讓你整套白名單失效的地雷。

想像一下常見的做法：寫一支小腳本，每天凌晨抓四份官方清單、解析出網段、更新 WAF 白名單。用什麼寫？多數人會用 Python，而 Python 標準庫的 urllib 不設 User-Agent 時，送出的預設值就是 Python-urllib/<版本>。

然後呢？Anthropic 那份清單回 403。

為什麼這個失敗特別危險

因為它會靜默。

如果腳本沒檢查 HTTP 狀態碼，直接把回應丟給 JSON 解析器，兩種結果都很糟：解析失敗，腳本拋例外死在半路，白名單維持舊版（還算好）；或者更糟——你的腳本有 try/except 包住、把失敗當成「這次沒有資料」，於是寫進一份空的或殘缺的白名單。

寫進空白名單會發生什麼事？你把真爬蟲全部擋掉了。 不是擋掉假的，是擋掉真的。而且這個故障不會觸發任何告警，因為腳本「跑完了」、沒有 exit code 非零、log 裡也沒有紅字。你會在幾週後才發現網站的 AI 曝光掉了，然後花好幾天回頭查是哪裡出問題。

我們的經驗是，這類故障的偵錯成本遠高於故障本身——因為沒有人會第一時間懷疑那支跑了半年都「正常」的同步腳本。

修法就三件事

顯式設 User-Agent。 不要依賴預設值。用一個能識別你的組織的字串，例如 MyCompany-BotListSync/1.0，出事時對方也查得到是誰在抓。我們實測過：同一支 urllib 腳本，只加上這個標頭，403 就變成 200。
檢查 HTTP 狀態碼再解析。 非 200 一律當失敗處理，不要進到解析步驟。這行程式碼三秒鐘就能寫，卻是整條鏈路唯一的守門員。
比對筆數差異，異常就中止並告警。 新舊版差距超過門檻（例如筆數掉了一半、或直接變成 0）時，不要落地，改成保留舊版 + 發告警。ChatGPT-User 從 290 變 289 是正常波動，從 289 變 0 就是災難。

第 3 點才是真正的保險。前兩點防的是已知的失敗模式，第 3 點防的是你還沒遇過的那些。

import json, urllib.request

UA = "MyCompany-BotListSync/1.0"

def fetch_prefixes(url: str) -> list:
    req = urllib.request.Request(url, headers={"User-Agent": UA})
    resp = urllib.request.urlopen(req, timeout=20)
    if resp.status != 200:                      # ← 守門員：非 200 一律當失敗
        raise RuntimeError(f"{url} returned {resp.status}")
    return json.load(resp)["prefixes"]

def safe_update(url: str, previous: list) -> list:
    fresh = fetch_prefixes(url)
    if not fresh or len(fresh) < len(previous) * 0.5:   # ← 筆數腰斬就不落地
        raise RuntimeError(f"suspicious shrink: {len(previous)} -> {len(fresh)}")
    return fresh

這支同步腳本，公司裡有人在顧嗎？

一支會靜默失敗的同步腳本，出事時不會有人發現——只會看到爬蟲流量突然歸零。CloudInsight 技術團隊可協助盤點雲端環境裡這類「沒人負責的自動化」，把告警補上。

👉 聯繫我們的技術團隊

第二道門檻：反向 DNS（FCrDNS）雙向驗證怎麼做

沒公布 IP 清單、但有穩定網域的爬蟲怎麼驗？用反向 DNS 雙向驗證，也就是 FCrDNS（Forward-Confirmed reverse DNS）。這是 Google 官方驗證 Googlebot 的方法，文件裡明白寫著要做 reverse DNS lookup 與 forward DNS lookup 兩步。不是什麼小眾偏方，而是這個領域既有的標準做法。

流程三步，缺一步都不成立：

反解：拿來源 IP 去查 PTR 記錄，得到一個主機名。
檢查網域：確認這個主機名落在該供應商的官方網域底下（例如 Googlebot 落在 googlebot.com 或 google.com）。
正解回去：把第 2 步得到的主機名再解析成 IP，確認它跟第 1 步的來源 IP 一致。

實際跑起來長這樣：

# 步驟 1：反解，取得主機名
dig -x 66.249.66.1 +short
# → crawl-66-249-66-1.googlebot.com.

# 步驟 3：把主機名正解回 IP，跟原本的來源 IP 比對
dig +short crawl-66-249-66-1.googlebot.com
# → 66.249.66.1   （與步驟 1 的來源 IP 相同 → 閉環成立，通過）

上面這組輸出是 2026-08-05 實測的結果。步驟 2 在這個例子裡是肉眼可判的：主機名結尾是 googlebot.com，落在 Google 的官方網域內。

為什麼一定要正反各做一次

這是最多人做一半就收工的地方，也是最致命的。

反解查的是 PTR 記錄，而 PTR 記錄是由擁有那段 IP 的人設定的。換句話說，任何人只要控制自己的 IP 反解，就能把主機名設成看起來很官方的樣子。只做反解、看到字串裡有 googlebot.com 就放行，等於又回到「相信對方的自我宣告」——只是這次宣告換了個欄位而已。

正解那一步才是關鍵：正向 DNS 記錄由網域擁有者控制。攻擊者可以隨便設自己 IP 的 PTR，但他改不了 googlebot.com 的 A 記錄。所以「反解得到的主機名，正解回來要等於原始 IP」這個閉環，才是真正把驗證權從請求端拿回到你這邊。

說明反向 DNS 驗證必須反解與正解各做一次形成閉環，只做一半就會被偽造的記錄騙過

圖說：閉環才算通過——來源 IP 反解成主機名、主機名再正解回同一個 IP；只做反解那一半，環是開口的

這道門檻的適用範圍

FCrDNS 的好處是不需要對方公布 IP 清單，只需要對方有穩定的網域命名慣例。壞處也很明顯：它多了兩次 DNS 查詢，在高流量下要做快取；而且如果某家爬蟲的 PTR 記錄設得零散或根本沒設，這條路一樣走不通。

所以第一道與第二道不是二選一，是互補。有清單的用清單（快、確定），沒清單的用 FCrDNS（慢一點、但通用）。

Cloudflare Verified Bots 的兩條門檻：誠實自我識別與非濫用行為

如果你的站前面掛著 Cloudflare，那麼有一套現成的判定框架可以直接參考。依 Cloudflare Verified bots 文件（頁面標示 Last updated 2026-07-01），一隻 bot 要被列為已驗證機器人，得同時滿足兩條門檻：

門檻	內容	對站方的意義
① 誠實自我識別	透過 Web Bot Auth 密碼學簽章、公布 IP 清單搭配穩定 UA、或反向 DNS，讓對方能獨立確認身分	這就是本文前兩道關卡的官方版本——身分要能被第三方查核，不是自己說了算
② 非濫用行為	遵守 robots.txt、維持合理的請求頻率、未規避站方表達的意願	身分為真還不夠，行為也要合格；違反的 bot 就算身分驗得過也不該享有豁免

（來源：Cloudflare Verified bots 文件，頁面標示 Last updated 2026-07-01）

第二條門檻常被忽略，但它才是分水嶺

多數人談 bot 驗證只談第一條——「是不是真的」。Cloudflare 把第二條並列，說的是另一件事：身分為真跟該不該放行，是兩個獨立的問題。

一隻身分完全正確、但請求頻率高到壓垮你的來源伺服器、還無視 robots.txt 的爬蟲，該不該擋？當然該。驗證通過只是取得「不被當成假冒者」的資格，不是取得無限額度的通行證。

fake bot 是怎麼被標記的

Cloudflare 另有一組 fake bot 管理規則，判定邏輯很單純：UA 比對到已知 bot，但來源無法驗證，就標記為 fake bot。

這條規則的形狀值得抄下來。它不是「UA 看起來怪就擋」，而是「UA 宣稱得很具體，但事實對不上」——後者才是真正的訊號。一個誠實填 MyCompany-Scraper/1.0 的腳本不會被標記，一個假裝自己是 Googlebot 卻來自無法驗證的 IP 的請求才會。

如果你的 Cloudflare 後台還沒開到這一層，或者不確定 bot 相關設定放在哪些選單底下，可以先看我們的 Cloudflare CDN 完整教學把基礎設定的位置對一遍再回來。

把三道關卡組成一條可稽核的判定流程

前面三道關卡各自成立，但它們要串成一條流程才有用。我們實際落地時用的順序是這樣：

先看 UA 有沒有命中已知 bot 名單。 沒命中的就不是本流程的對象，走一般流量處理。
命中的話，查來源 IP 是否落在該爬蟲的官方 IP 清單裡。 落在裡面 → 通過，標記為已驗證。
不在清單裡（或該爬蟲根本沒公布清單），改跑 FCrDNS 雙向驗證。 反解、檢查網域、正解回來三步全過 → 通過。
兩道都沒過 → 標記為「未驗證」，進限流佇列。

翻成規則語言大致長這樣（以下為示意，實際語法依你的 WAF 平台而定）：

# 偽碼：三道關卡的判定順序
if ua_matches_known_bot(request.user_agent):
    bot = identify(request.user_agent)
    if bot.has_official_ip_list and ip_in_prefixes(request.ip, bot.prefixes):
        verdict = "verified"                  # 第一道：IP 清單
    elif fcrdns_ok(request.ip, bot.dns_domains):
        verdict = "verified"                  # 第二道：反向 DNS 雙向
    else:
        verdict = "unverified"                # → 限流，不是封鎖
else:
    verdict = "not_a_known_bot"

「未驗證」不等於「惡意」——這條處置原則請務必守住

第 4 步的處置寫的是「限流」而不是「封鎖」，這是刻意的。

未驗證的來源有幾種可能：真的是假冒者；也可能是那隻爬蟲剛換了出口 IP、而你的清單還沒同步；還可能是你的同步腳本昨天靜默失敗了（見本文〈抓官方清單這一步本身就會失敗〉）。三種情況在 log 裡長得一模一樣。

直接封鎖的代價是不對稱的：擋掉一個假冒者，你少了一次無害的抓取；擋掉一隻真爬蟲，你的內容從那個 AI 系統的知識來源裡消失，而且你不會收到任何通知。所以我們的建議是——未驗證流量進限流佇列、保留樣本、留一個人工複核的出口，觀察一段時間再決定要不要升級成封鎖。

想同時把處置層（限流、挑戰、封鎖各自的適用場景）看清楚，可以延伸讀 CDN 與 DDoS 防護的三層機制；如果你懷疑自己「以為開放、其實擋掉了」，那就要往上一層查政策與 CDN／WAF 之間的落差，我們在 robots.txt 說可以，AI 就真的爬得到嗎這篇裡有完整的三層檢查方法。

一個規則設計上的現實：有些爬蟲你在 IP 層分不出來

還有一件事會直接影響你的規則怎麼寫。

回頭看 2026-08-05 那張表：OpenAI 把 GPTBot、OAI-SearchBot、ChatGPT-User 拆成三份清單，所以你可以在 IP 層直接分流——訓練爬蟲跟使用者觸發流量走不同規則、給不同額度，完全可行。

Anthropic 不一樣。ClaudeBot、Claude-User、Claude-SearchBot 三隻共用 https://claude.com/crawling/bots.json 這一份清單。這代表什麼？代表一則請求驗證通過之後，你知道「它確實是 Anthropic 的爬蟲」，但你沒辦法從 IP 判斷它是訓練、使用者觸發還是搜尋。要分辨，只能退回 UA 層——而 UA 層正是我們整篇文章在說「不能單獨當驗證」的那一層。

這不是矛盾，是分工：IP 層負責「是不是真的」，UA 層負責「是哪一隻」。 兩層的功能不同，順序不能顛倒。先用 IP 或 FCrDNS 確認來源為真，通過之後才拿 UA 來做分類——這時候 UA 已經是可信的了，因為能通過第一道關卡的請求，本來就來自對方掌握的位址。

訓練爬蟲跟搜尋爬蟲的差別為什麼值得分開處理？因為它們對你的價值不同。搜尋與使用者觸發的抓取通常伴隨引用與流量，訓練抓取則是單向的內容輸出。想量化它們各自吃掉你多少資源，可以參考 AI 爬蟲吃掉多少頻寬那篇的算法。

這套判定要落在哪一層？

這套判定要落在哪一層、規則寫在哪家平台的哪個位置，各朵雲的做法都不一樣。CloudInsight 代理 AWS、GCP、Azure、阿里雲與騰訊雲，提供中文即時客服與台灣時區技術支援，不用等隔天回信。

👉 立即諮詢企業方案｜加入 LINE 即時諮詢

驗證通過之後：能進來，不等於會被引用

三道關卡跑完，你回答的是「誰進來了」。這半題很重要，但它就只是半題。

另外半題是：這些爬蟲把你的內容抓回去之後，AI 的回答裡到底有沒有用上？被引用的時候，長什麼樣子？這條軌看的東西完全不同——不是 WAF 規則、不是 IP 網段，而是內容本身的結構：段落能不能被獨立理解、事實有沒有可驗證的出處、問題與答案的距離有多近。

至於進來之後，內容有沒有被 AI 的回答採用、被引用時長什麼樣子，那是另一條完全不同的軌，看的是內容結構而不是 WAF 規則。與 CloudInsight 同一團隊經營的 AI SEO Hacker 把內容端怎麼被 AI 搜尋引用的完整流程整理成一份說明，需要把這半題補起來時可以接著看；本文到此為止只負責身分判定。

把兩件事分開看，維運上會清爽很多：身分判定的問題出在 log 與規則，內容引用的問題出在文章本身。用 WAF 規則解決不了引用率，用改文章也解決不了假冒爬蟲。

常見問題

Q: 只比對 User-Agent 就能確認是不是 GPTBot 嗎？

A: 不能。User-Agent 是請求端在 HTTP 標頭裡自己填的字串，伺服器沒有任何機制可以否證它。我們在 2026-08-05 實測過，同一個網址只換 UA 就會拿到 403 或 200 兩種不同結果——這正說明那行字有多大影響力，也說明它有多容易被拿來假裝成別人。確認身分必須靠來源 IP 或反向 DNS。

Q: 官方 IP 清單多久更新一次？我要多久同步一次？

A: 各家差很多。2026-08-05 實測時，GPTBot 清單的 creationTime 是 2025-10-30、九個月沒動；ChatGPT-User 卻在實測當天更新，而且我們前後兩次呼叫間隔數分鐘，網段數就從 290 變成 289。建議一律走自動同步、每日執行，並在筆數異常變動時中止落地並告警，不要手工維護。

Q: 反向 DNS 驗證跟 IP 清單比對，只做一種可以嗎？

A: 兩者互補，建議都做。IP 清單比對快又確定，但只對有公布清單的爬蟲有效；反向 DNS（FCrDNS）不需要對方公布清單，適用於有穩定網域命名的爬蟲，代價是多兩次 DNS 查詢。實務順序是先查清單，查不到再跑 FCrDNS，兩道都沒過才標記為未驗證。

Q: 被 Cloudflare 標記成 fake bot 的流量，一定是惡意的嗎？

A: 不一定。依 Cloudflare 的 fake bot 管理規則，判定條件是「UA 比對到已知 bot 但來源無法驗證」，而來源驗不過可能是因為那隻爬蟲剛換出口 IP、或你的清單同步失敗了。所以未驗證流量建議先進限流佇列、保留樣本並留人工複核出口，不要直接封鎖——擋錯真爬蟲是不會有告警的。

Q: 為什麼 Claude 的訓練爬蟲跟使用者觸發流量用同一份 IP 清單？

A: 2026-08-05 實測，ClaudeBot、Claude-User 與 Claude-SearchBot 三隻確實共用 https://claude.com/crawling/bots.json 這一份清單，共 20 個網段、其中 19 個是 /32 單一 IP。實務影響是：你在 IP 層只能確認「它是不是 Anthropic 的爬蟲」，要分辨是訓練、使用者觸發還是搜尋，只能在驗證通過後退回 UA 層判斷。

結論：兩道門檻缺一不可，而且要自動化

驗證 AI 爬蟲身分這件事，如果只記三句話，記這三句：

第一，UA 永遠不是身分。 它是請求端自己填的一行字。我們在 2026-08-05 用同一個網址、只換 UA 就拿到 403 和 200 兩種結果，這個實測你可以自己重現一次——它證明的不是某家防護有問題，而是那行字的份量。

第二，把清單同步做對，比把規則寫漂亮更重要。 顯式設 User-Agent、檢查 HTTP 狀態碼、比對筆數差異異常就中止告警。這三件事加起來不到二十行程式碼，卻是整條驗證鏈唯一會靜默崩掉的地方。ChatGPT-User 的清單在我們實測那天就更新了，而且我們相隔數分鐘的兩次呼叫拿到的筆數還不一樣——手工抄一份進 WAF，撐不過幾天。

第三，未驗證流量走限流，不走直接封鎖。 留限流佇列、留樣本、留人工複核的出口。驗證這件事不做會怎樣？不是被爬爆——是你以為擋掉了壞的，其實擋掉的是真的，而且沒有任何告警會告訴你。

想現在就動手的話，順序是：先把四份官方清單的自動同步做起來（含狀態碼檢查），再補 FCrDNS 當第二道，最後才調處置策略。三步都不需要換平台，也不需要等預算。

呼應文章結論，說明爬蟲身分驗證需要靠自動同步與告警長期運作

🎯 立即行動

驗證這件事不做會怎樣：不是被爬爆，是你以為擋掉了壞的，其實擋掉的是真的。

👉 立即諮詢，取得最適合您的方案 👉 加入 LINE 官方帳號，即時獲得技術支援

參考資料

IETF RFC 9309《Robots Exclusion Protocol》（Standards Track，2022 年 9 月；robots.txt 的正式規格，2026-08-05 讀取）
Cloudflare — Verified bots（頁面標示 Last updated 2026-07-01）
Cloudflare — Fake bot managed rules
Anthropic — Does Anthropic crawl data from the web, and how can site owners block the crawler?（2026-08-05 實測可存取）
Google — Verify Google crawlers and fetchers（2026-08-05 實測可存取）
OpenAI 官方爬蟲 IP 清單：https://openai.com/gptbot.json、https://openai.com/searchbot.json、https://openai.com/chatgpt-user.json（2026-08-05 一手實測）
Anthropic 官方爬蟲 IP 清單：https://claude.com/crawling/bots.json（2026-08-05 一手實測）

需要專業的雲端建議？

無論您正在評估雲平台、優化現有架構，或尋找節費方案，我們都能提供協助

預約免費諮詢

DevOps