在現代伺服器租用維運中，AI 爬蟲速率限制早已不只是策略層面的註腳，而是一個真實存在的工程問題。如果所有自動化用戶端都被壓進同一套限流閾值中，那麼有價值的抓取器就會和高噪聲採集器被混為一談，最終網站回傳的不是結構化內容，而是不必要的存取摩擦。更合理的做法是實施選擇性彈性控制：對不可信的自動化流量維持嚴格約束，但對於行為更像規範爬蟲而非濫用流量的已驗證機器用戶端，則提供更寬的存取通道。

從協定層來看，速率限制本質上只是控制單位時間內請求壓力的一種方式。當用戶端超過允許範圍時，許多系統會回傳 HTTP 429，該狀態碼被定義為「請求過多」。官方 HTTP 規範同樣指出，具體實作會因伺服器、資源和策略而有所不同，因此並不存在適用於所有業務負載的統一閾值。同時，抓取指令與速率控制也不能混為一談：robots.txt 控制的是抓取權限，而服務端限流控制的是資源保護。主流爬蟲文件也進一步說明，諸如 crawl-delay 之類不被普遍支援的指令，並不是一種可靠的流量整形機制。

為什麼單一限流在真實流量中會失效

統一限流在白板設計圖上看起來很整潔，但生產環境流量從來都不是平的。真人工作階段通常具有突發性，瀏覽器渲染會並行拉取多個資源，監控代理依週期發送請求，而機器爬蟲則常常以高度規律的節奏遍歷內容樹。如果把這些流量都當成同一種類別，就會產生兩個明顯的問題：

  • 可信爬蟲過早收到 429 回應，導致抓取連續性下降；
  • 高成本端點不得不被過度保護，結果低成本內容頁也被迫繼承同樣嚴格的限制；
  • 如果識別能力薄弱，惡意機器人仍然可以浪費來源站資源；
  • 維運團隊失去可觀測性，因為所有自動化請求看起來都一樣可疑。

對技術受眾來說，核心思路其實很直接：速率限制應當與資源成本和身分可信度綁定。一個被快取的文字頁面，和一個每次請求都要存取儲存與運算資源的驗證搜尋端點，本質上並不相同。同樣地，一個已驗證且行為穩定的爬蟲，也不等於一個偽造請求標頭、頻繁輪換來源的殭屍網路機器人。一旦把這兩個維度拆開，更寬鬆的爬蟲策略反而會更安全。

「更寬鬆」到底意味著什麼

「更寬鬆」並不等於「完全放開」。它指的是只在資源收益合理的前提下，適度擴大允許範圍。在大多數環境中，你調整的是幾個變數，而不是按下一個總開關：

  1. 請求速率：對已驗證的爬蟲類別提高每秒允許的請求數。
  2. 突發視窗：允許更大的短時峰值，以便更高效率地抓取內容樹。
  3. 連線預算：將並行連線數與原始請求計數分開控制。
  4. 路徑敏感度：對公開 HTML、文件、訂閱源或快取靜態資源給予比搜尋、登入、購物車或寫入路徑更高的餘量。
  5. 回退行為：決定超限流量是在高壓下被延遲、回傳 429，還是直接丟棄。

這一點之所以重要，是因為圍繞 429 的 RFC 指南明確說明，伺服器在過載情境下並不一定必須回傳 429；在攻擊壓力下，直接丟棄連線或採取其他控制措施反而更合適。這意味著你的架構不能把單一回應碼視為整個防護模型。

先驗證，再放寬

爬蟲策略中最大的錯誤，就是僅憑 User-Agent 字串來建立信任。請求標頭文字太容易偽造，所以任何單純基於請求標頭的豁免規則，最終都會演變成一種繞過方式。更穩健的設計是使用分層驗證，在套用更寬鬆規則之前先計算可信度分數。

  • 請求標頭檢查：可作為第一道過濾，但絕不能作為最終證明。
  • 反向查詢與正向確認：驗證主機名稱宣告與 IP 解析是否一致。
  • 網路信譽：利用 ASN、網段歷史與長期穩定性進行判斷。
  • 行為畫像：觀察請求間隔、路徑遍歷、方法分布與錯誤率。
  • 存取分級：將自動化流量劃分為「已驗證」「高機率可信」「未知」與「敵對」。

一旦身分可信度被量化，限流表就可以做成非對稱結構。已驗證的機器用戶端獲得更大的令牌桶；未知用戶端使用預設閾值；可疑用戶端獲得更小的桶、額外驗證，或者直接拒絕。這個方法沒有一鍵白名單那樣炫目，但幾乎肯定更難被濫用。

圍繞資源成本來構建策略

並不是每個 URL 都應該繼承相同的存取預算。更適合極客理解的方式，是按照來源站邊際成本對路由進行分類：

  1. 低成本：快取 HTML、靜態檔案、文件、更新日誌、公開中繼資料。
  2. 中成本：未快取但樣板渲染較輕的內容頁面。
  3. 高成本：站內搜尋、動態篩選、匯出端點、預覽頁面。
  4. 關鍵路徑：登入、結帳、工作階段變更、寫入 API、管理後台路由。

更寬鬆的 AI 爬蟲速率限制幾乎只應該落在第一類路徑上，選擇性延伸到第二類，而很少跨越到更高成本區域。一套好的規則集，即使面對已驗證爬蟲，也會持續保護高成本與關鍵路徑。如果某個機器用戶端確實需要存取這些路徑，更安全的模型應當是提供一個獨立的驗證介面，並配套專屬配額、日誌與濫用控制。

為什麼 robots.txt 不是速率限制器

很多團隊至今仍把抓取權限與傳輸層控制混為一談，這會帶來一種虛假的安全感。官方爬蟲文件已經說明，robots.txt 用於告訴爬蟲哪些路徑可以抓取，而像 crawl-delay 這樣不被主流爬蟲普遍支援的規則，並不能可靠地控制存取頻率。換句話說，robots.txt 對於抓取範圍管理是有價值的，但它並不能保護你的來源站免受高頻請求衝擊。如果流量整形真的重要，就必須在邊緣層、代理層或應用層落實。

  • 使用 robots.txt 定義允許與禁止抓取的路徑。
  • 使用網站地圖與內部連結暴露重要內容。
  • 使用服務端速率控制保護運算、頻寬與儲存資源。
  • 使用日誌與遙測驗證策略是否符合真實情況。

更安全的寬鬆策略參考架構

實際落地時，通常將其設計為一條處理流水線，而不是一條單獨規則。具體語法會因技術堆疊不同而不同，但邏輯本身具有可移植性：

  1. 對請求進行分類。判斷它是真人、已驗證爬蟲、未知機器人，還是敵對自動化流量。
  2. 對路徑進行分類。將 URL 對映為低成本、中成本、高成本或關鍵路徑。
  3. 套用存取預算。根據策略矩陣分配速率、突發值與並行限制。
  4. 選擇回應模式。延遲、429、額外驗證、拖延處理，或者直接中斷連線。
  5. 記錄每個決策。包括身分評分、路徑類別、命中的桶、上游延遲與回應碼。

這個策略矩陣在概念上可能類似如下：

  • 已驗證爬蟲 + 低成本路徑 = 更寬鬆速率、中等突發值、中等並行數；
  • 已驗證爬蟲 + 高成本路徑 = 預設速率、較低突發值；
  • 未知機器人 + 任意路徑 = 保守速率與嚴格突發值；
  • 敵對自動化流量 + 敏感路徑 = 立即拒絕或強驗證。

這種基於矩陣的控制方式，比起單塊式限流更容易調校，因為每一個變數都有清晰的職責劃分。同時，它也能自然對映到反向代理、服務網格、閘道策略以及應用中介軟體之中。

可觀測性：不要太早慶祝

如果你放寬了爬蟲策略，卻只觀察總流量，那麼你很可能看不到真正的變化。真正重要的問題是：抓取效率是否提升了，同時來源站壓力是否仍然穩定。因此，監控體系必須同時覆蓋機器側效果與系統側影響。

  • 按用戶端類別統計 429 比率：已驗證爬蟲是否不再頻繁撞上限流器？
  • 中位延遲與尾延遲：公開路徑的 P95 或 P99 是否變差？
  • 來源站飽和度：CPU、記憶體、佇列深度與儲存等待時間。
  • 快取效率：策略變更前後的命中率是否變化？
  • 路徑熱度圖：哪些 URL 現在承受了更密集的機器存取？
  • 錯誤分布：按類別拆分 403、404、429、5xx 與連線重設。

在發布策略時，應採用分階段上線。先從一種爬蟲類別、一類路徑，以及小幅增加的 burst 開始，而不是一次性大幅提升持續速率。觀察數天之後，如果遙測資料依然健康，再逐步放寬。這樣的漸進式調校聽起來不刺激，但它恰恰是最可靠的工程方式。

伺服器租用與伺服器託管的影響

網站底層基礎設施模型會直接影響你能把策略放寬到什麼程度。在伺服器租用環境中，主要約束通常是共享或受限的運算資源在波動負載下的承載能力，因此爬蟲存取餘量應更多依賴快取能力與上游效率。而在伺服器託管環境中，你可能擁有更直接的網路與硬體控制權，但這也意味著你需要承擔更多關於可觀測性、邊緣過濾與失效保護的責任。爬蟲策略應當適配部署模型，而不是假裝所有伺服器拓撲的行為都完全一樣。

從工程實務來看，最可靠的收益通常來自以下幾個方面：

  1. 提升公開內容的快取命中率；
  2. 將靜態路徑與動態路徑拆分到不同控制平面；
  3. 減少對爬蟲可見的高成本參數與重複 URL；
  4. 無論機器人身分如何，都對敏感流程維持更嚴格的閘門；
  5. 盡量在請求路徑的更前端做出速率決策。

常見失敗模式

很多團隊理論上都明白這些原則，但在生產環境裡仍然會反覆踩中同樣的邊界問題。你需要特別留意這些模式：

  • 僅憑 UA 豁免：容易被偽造，也很難在被濫用後收回。
  • 統一路徑策略：低成本路徑與高成本路徑一視同仁。
  • 無限制突發：即便平均速率看似安全，短時峰值仍會壓垮後端。
  • 沒有回饋閉環：429 數量下降了，但來源站延遲卻在悄悄上升。
  • 把抓取範圍控制當成速率控制：robots.txt 無法取代真正的限流器。
  • 忽略重複 URL 面：參數膨脹會同時浪費爬蟲預算與伺服器容量。

這些並不是紙面上的理論錯誤，而是在團隊想「對機器人更友善」卻又沒有量化信任度與資源成本時，幾乎必然會在生產中出現的問題。

適合極客團隊執行的上線清單

  1. 盤點所有公開路由，並按來源站成本加上標籤。
  2. 定義機器用戶端類別，以及每種信任等級所需的證據。
  3. 為不同類別與路徑群組設定獨立的速率、突發值與並行預算。
  4. 對寫入路徑、驗證流程與重查詢端點維持嚴格限制。
  5. 使用便於解析的格式記錄策略決策。
  6. 分階段發布，並對比 429、延遲與快取指標。
  7. 每週檢討邊界案例，收緊任何吸引到偽裝流量的規則。

這個清單之所以聽起來非常維運化，是因為事實確實如此。好的抓取策略不是什麼神奇標籤，而是擁有更清晰命名方式的流量工程。

結論

實作 AI 爬蟲速率限制的最佳方式，是把它視為「信任 + 成本」問題，而不是某種市場偏好。先驗證用戶端，再分類路徑，只對那些能夠保護低成本公開內容的存取桶適度放寬，同時對敏感流程維持硬性控制。這樣的設計既能保持網站穩定，又能在真正有價值的情境中改善機器存取效率。對於運行現代伺服器租用環境或更偏底層自主管理的伺服器託管部署團隊來說，最優模式始終一致：基於證據進行選擇性放寬，並以日誌、指標與持續迭代為支撐。歸根結底，AI 爬蟲速率限制應當「因證明而寬鬆」，而絕不能「預設即寬鬆」。