git.kernel.org 遭 AI 爬蟲大規模佔用資源

重點摘要

• Linux 核心基礎設施管理員 Konstantin Ryabitsev 揭露，git.kernel.org 每日處理約 600 萬筆來自 AI 爬蟲的請求，消耗約 20% 的整體 CPU 容量，其中 14 到 16 個 CPU 核心持續僅為爬蟲渲染 HTML。
• 儘管部署了 Anubis 工作量證明挑戰，仍有 33% 的爬蟲成功繞過防禦；合法開發者流量僅佔總流量的 2%，顯示基礎設施面臨嚴重的資源錯配與安全威脅。
• Datasette 作者 Simon Willison 指出此問題對提供大量可爬取頁面的開源工具構成潛在風險，開源社群正考慮減少可爬取 URL 數量及限制匿名使用者的高資源消耗操作。

2026 年 8 月 29 日，Linux 核心 git 基礎設施管理員 Konstantin Ryabitsev 在個人部落格發布題為「Creepy crawlies」的文章，記錄了 git.kernel.org 承受的 AI 爬蟲負載。伺服器每日接收約 600 萬筆來自 AI 爬蟲的請求，主要針對個別修補提交頁面逐一抓取，與過去幾年尚能應付的常態相比，已不在同一個數量級。9 月 7 日，Datasette 與大型語言模型開源工具作者 Simon Willison 也在部落格轉貼這篇報告，讓這場基礎設施危機得到更廣泛的討論。這個數字只說了量，問題的核心在於請求的方式。

AI 爬蟲的無節制抓取已對開源基礎設施造成嚴重的資源侵蝕，迫使維護者在開放存取與系統生存之間做出艱難抉擇。

基礎設施資源如何被爬蟲佔用？

git.kernel.org 的基礎設施由五個地理分佈的節點組成，總計 90 個 CPU 核心。Ryabitsev 的資料顯示，爬蟲流量吃掉了約 20% 的總 CPU 容量，換算下來，90 個核心中有 14 到 16 個全天候只在為爬蟲把 git commits 轉成 HTML，別無其他工作。Ryabitsev 在文章中把成本結構說得很直白：「我們為爬蟲渲染修補提交所花費的 CPU 週期，超過了所有其他合法存取方式的總和，包括 git 複製。」服務爬蟲所耗費的算力，已高於服務所有真實開發者的總和。

在總流量中，合法的開發者或使用者存取估計只佔 2%，其餘 98% 都是自動化請求。這種比例失衡浪費了運算資源，也可能拖慢真正需要存取核心程式碼的開發者。根本原因在於爬蟲繞過了更有效率的管道：它們選擇透過網頁介面逐個渲染 HTML 修補提交，而非使用資源消耗遠低的 git-clone 協定，逼得伺服器把力氣花在渲染網頁，而不是直接傳輸原始資料。這個方式上的落差，決定了接下來每一種防禦手段的上限。

防禦機制為何失效？

初期，Ryabitsev 嘗試用 fail2ban 進行 IP 封鎖，加上自治系統號碼層級的封鎖。爬蟲技術隨之演進：根據 Linuxiac 的報導，爬蟲已從使用可識別的使用者代理字串，轉向分散式的住宅與行動 IP 代理網路，讓 fail2ban 等傳統手段很難有效識別並阻擋惡意流量。

為了因應更靈活的爬蟲，Ryabitsev 部署了 Anubis 工作量證明挑戰，並逐步把難度提升至第 4 級和第 5 級，要求請求者在存取內容前先解決計算任務，藉此拉高爬蟲的操作成本。結果是：Anubis 成功阻擋了 66%。剩下 33% 的機器人仍然解題通過。AI 爬蟲背後有足夠的運算資源撐場，單靠提高難度撐不了多久。

更根本的問題在 URL 空間本身。linux.git 儲存庫包含 148 萬筆修補提交，加上 922 個分支儲存庫，在 git.kernel.org 上產生了數十億個有效的爬取目標 URL。這種龐大的 URL 空間讓爬蟲能分散請求，繞過基於頻率或單一 IP 的封鎖機制，即使有防禦措施，也能持續抓取資料。這場貓捉老鼠的遊戲，說明了開源基礎設施面對大規模自動化流量有多脆弱，也讓社群開始認真思考更根本的架構調整。

開源工具面臨的潛在威脅

Willison 轉貼 Ryabitsev 的報告時，同時帶出了自己的處境：他的工具 Datasette 面臨同樣的威脅，因為它也服務「大量可爬取的網頁」。Willison 在 Hacker News 上發現 Ryabitsev 的文章後，進一步把這個議題帶入更廣泛的討論。

這種處境並不少見。許多開源工具設計之初是為了方便人類使用者存取資料，並未充分考慮大規模自動化爬蟲的資源消耗。當爬蟲流量遠超人類流量時，伺服器資源可能被迅速耗盡，導致服務中斷或延遲。這場爭議背後，是 AI 訓練資料需求與開源基礎設施維護之間的直接衝突：當爬蟲行為對基礎設施造成過度負擔，維護者就不得不在開放存取與資源保護之間取捨。

未來的緩解策略與社群回應

Ryabitsev 與社群目前考慮的方向，包括減少可爬取的 URL 數量，以及限制匿名使用者的高資源消耗操作。兩項策略的邏輯一致：縮小爬蟲能取得的目標範圍，同時拉高操作成本，例如限制 HTML 渲染的頻率或數量，迫使爬蟲轉向資源消耗更低的 git-clone 協定。

對 Willison 來說，這個案例也是一次提醒：Datasette 這類服務大量可爬取頁面的工具，可能需要內建更強的速率限制或驗證機制。技術選擇之外，攸關的是開源維護者能否長期撐住。git.kernel.org 的數字已說清楚了：600 萬筆每日請求、14 到 16 個核心持續空轉服務爬蟲，而真實開發者流量只佔 2%。從 Ryabitsev 到 Willison，兩個開源專案已先後指出自己正承受這道壓力，下一個是誰，還沒有答案。