Cloudflare BotBase 為爬蟲營運者加入可追蹤身分驗證
Cloudflare 於 2026 年 8 月 28 日發布 BotBase for Operators，讓機器人與爬蟲營運者能更清楚地提交、追蹤、修正並維護目錄條目。這項更新不只影響 AI 爬蟲，也反映網站防護方式正在改變：可問責的自動化流量，需要能夠持續驗證的身分，而不能只依靠看似熟悉的 User-Agent。
對獲授權的資料蒐集、搜尋索引、可用性監控、廣告驗證與市場研究而言，代理容量只是營運體系的一部分。爬蟲還必須穩定說明由誰營運、執行什麼工作、如何使用內容，以及網站如何驗證其身分。若這些聲明與實際網路路徑脫節，再大的代理池也無法恢復信任。
Cloudflare 本次更新內容
Cloudflare 表示，新的 BotBase 區域向所有客戶開放，並將營運者工作分成三部分：
- 瀏覽已追蹤的機器人目錄；
- 提交新的機器人；
- 查看提交歷史。
提交歷史會顯示「等待審查」「已接受」與「已拒絕」三種狀態。被拒絕的提交會提供可採取行動的原因。身分資料變更時，營運者可以編輯既有提交；仍在等待審查的提交也能取消。
審查流程會先執行自動檢查，再把不明確案例交由人工處理。官方說明的檢查包括：是否與現有記錄重複、User-Agent 模式是否足夠明確，以及宣稱的驗證方法是否真正有效。系統可能讀取公開 IP 清單、確認反向 DNS，或驗證 Web Bot Auth 簽章。
公開來源說明：Cloudflare，《BotBase for Operators: A clearer path to joining Cloudflare's directory of bots and agents》，2026 年 8 月 28 日。
這並不是通用的爬取許可。每個網站仍能自行決定允許哪些流量。因此，目錄收錄應被視為身分證據，而不是同意、合約授權或所有請求都會通過的承諾。
為什麼代理爬蟲需要獨立身分層
代理路徑改變目標網站看到的網路來源；爬蟲身分則說明誰應對行為負責。把兩者當成一個未記錄的假設，會產生多種問題：
- 目錄條目引用的 IP 清單已不包含目前出口；
- 輪換池加入無法歸屬於聲明主體的新位址；
- 某個區域的反向 DNS 有效，另一區域卻無效；
- User-Agent 過於寬泛，與其他用戶端重疊；
- 主要請求有有效簽章，但重試或備援用戶端沒有簽章；
- 供應商變更上游資源，公開身分記錄卻沒有同步更新。
正確做法是把身分與路由視為兩個彼此相關、但可以獨立測試的系統。
| 控制層 | 核心問題 | 主要證據 |
|---|---|---|
| 身分 | 誰對自動化行為負責？ | 營運者、用途、聯絡方式、行為聲明 |
| 驗證 | 身分聲明能否被檢查？ | IP 清單、反向 DNS、請求簽章 |
| 路由 | 哪條網路路徑承載請求？ | 閘道、工作階段、出口群組、區域、協定 |
| 權限 | 此處是否允許蒐集？ | 合約、網站政策、robots 指引、同意範圍 |
| 結果 | 回應是否符合任務需求？ | 狀態類型、內容核驗、延遲、新鮮度 |
任何一層都不能代替另一層。回應成功不代表身分已驗證；身分已驗證也不代表已取得蒐集權限。
建立爬蟲身分清單
為每個正式環境爬蟲建立版本化的內部身分清單，不在其中保存密鑰。至少包含：
- 責任團隊與營運聯絡人；
- 爬蟲用途與允許的使用情境；
- 精確 User-Agent 模式；
- 內容使用聲明；
- 直接營運或中介營運模式；
- 選定的驗證方法；
- IP 清單或反向 DNS 的維護流程；
- 採用簽章請求時的用戶端覆蓋範圍；
- 核准區域、代理產品與協定；
- 變更負責人、複核日期與回復規則。
這是一份控制文件，而不是行銷介紹。工程師應能直接用它比對線上路徑，不需要猜測。
核對輪換出口與聲明身分
1. 固定預期出口群組
依核准市場記錄不含憑證的出口群組識別碼。住宅、ISP、行動與資料中心代理分開管理；IPv4 與 IPv6 也應獨立記錄，因為其所有權與反向 DNS 行為可能不同。
2. 執行有界抽樣
在並行數一的條件下執行少量授權測試。只在驗證所需的最短時間保留出口位址；日常記錄不需要原始位址時，使用雜湊或短期權杖。
3. 比較三個集合
每個測試視窗計算：
已聲明但未出現：驗證來源存在、實際樣本未出現的位址；已出現且已聲明：符合驗證來源的活動出口；已出現但未聲明：現有身分方法無法驗證的活動出口。
第三個集合必須阻擋發布。不要在未驗證所有權時直接擴大 IP 清單。應隔離該出口群組、調查供應變化，確認正確後再更新身分清單。
4. 測試備援路徑
對每種核准重試、區域容錯移轉、協定降級與用戶端實作執行非破壞性測試。主要用戶端可能正確簽章，但舊工作程序、瀏覽器流程或緊急路由可能發出未簽章請求。
使用代理路由洩漏偵測指南確認代理失敗後不會靜默切換為直連。需要穩定工作階段時，再使用住宅代理工作階段黏性測試。
將身分驗證變更視為發布
遷移 IP 清單位置、變更反向 DNS、啟用簽章請求或新增代理供應商，都可能改變網站辨識爬蟲的方式。每次變更應採用小型發布流程：
- 建立變更記錄，標示受影響爬蟲與出口群組；
- 在測試環境或授權目標驗證新方法；
- 確認所有正式環境用戶端採用相同驗證；
- 同步更新目錄提交與內部清單；
- 依出口群組監控接受、拒絕、挑戰與阻擋結果；
- 舊方法只保留明確的重疊期間；
- 發現未聲明出口或未簽章請求時立即回復。
不要在同一次發布中同時變更 User-Agent、代理資源、驗證位置、重試策略與簽章程式碼，否則遭拒絕時將無法可靠歸因。
在不規避控制下衡量辨識品質
有效指標應著重一致性與權限，而不是繞過防護：
- 各出口群組的驗證覆蓋率；
- 使用精確聲明 User-Agent 的請求比例；
- 各用戶端與重試路徑的簽章成功率；
- 適用時的反向 DNS 正反向一致率；
- 未聲明出口比例；
- 接受、挑戰、阻擋與政策拒絕結果；
- 基礎設施變更到目錄更新的時間；
- 獲准請求的內容有效率與延遲。
不得快速輪換 IP 尋找能避開阻擋的路徑。如果目標網站拒絕爬蟲或發出限制訊號，應停止自動化流程，透過網站所有者或授權介面處理身分、權限或政策問題。
營運檢查清單
- [ ] 已記錄爬蟲用途、營運主體、內容使用與營運模式。
- [ ] User-Agent 足夠明確，並在所有用戶端保持一致。
- [ ] 驗證證據符合目前正式環境出口。
- [ ] IPv4 與 IPv6 出口群組分別測試。
- [ ] 重試與容錯移轉路徑保持相同驗證行為。
- [ ] 未聲明出口會被隔離，而不是靜默加入允許清單。
- [ ] 目錄與內部記錄在同一次變更更新。
- [ ] 權限證據與身分證據分開保存。
- [ ] 記錄不包含密碼、Cookie、簽章密鑰與不必要的原始 IP 歷史。
- [ ] 遇到阻擋或挑戰時進入停止與複核流程。
常見問題
BotBase 顯示已接受，是否就能爬取？
不能。它代表該機器人經審查後被目錄追蹤。網站所有者仍決定允許哪些流量；營運者也必須遵守合約、網站規則、robots 指引、同意要求與速率限制。
只使用可辨識的 User-Agent 是否足夠？
不夠。User-Agent 只是聲明。驗證可能依賴 IP 清單、反向 DNS 或簽章請求，實際流量必須持續符合這些證據。
住宅代理池能否用於已驗證爬蟲？
只有在營運模式、供應商條款、目標規則與驗證方法彼此相容時才可以。高度動態、共用的出口通常不適合依賴穩定自有 IP 清單的身分方案。
是否應長期保存原始出口 IP？
通常不需要。只保留身分驗證與事件處理所需的最少資料，優先使用短期證據、雜湊出口群組權杖與明確刪除期間。
出現無法解釋的拒絕後該怎麼辦？
比對聲明身分與實際路徑，檢查 User-Agent 是否過寬、驗證覆蓋率、反向 DNS 或簽章行為，以及近期基礎設施變更。不要透過增加請求量或加速輪換來回應。
合規說明
自動化蒐集只能用於合法且取得授權的目的。遵守目標條款、適用的 robots 指引、內容使用偏好、同意要求、隱私義務與合理速率限制。身分驗證不會凌駕存取控制。不得使用代理冒充其他營運者、隱藏被禁止的活動，或繞過網站阻擋與挑戰爬蟲的決定。
