AI 爬蟲已經把 robots.txt 當空氣：Anubis 用工作量證明把它們擋在外面

過去半年，許多自架 Forgejo、Gitea、Wiki、文件站的管理員應該都遇過同一件事：明明站台流量沒漲，伺服器的 CPU 和頻寬卻被打到滿載。打開 access log 一看，全是 OpenAI、Anthropic、Perplexity、ByteDance 旗下的爬蟲在反覆掃同一份 Git diff 頁面，一秒內按同一個連結十幾次。robots.txt 對它們毫無效力。

Anubis 是 Xe Iaso 為了這個問題寫出來的反向代理。從 2025 年初發布至今，已經被聯合國、Codeberg、各大開源專案站採用，下載次數突破 20 萬，GitHub 上累積近兩萬顆星。它的核心想法很單純：在使用者進入站台之前，先讓瀏覽器解一道工作量證明（Proof of Work）。

為什麼 rate limit 和 UA 封鎖已經救不了你

傳統三件套早就被打穿。robots.txt 是君子協議，AI 公司不照辦；單純擋 User-Agent 沒用，現代爬蟲早就把 UA 換成 Chrome；依 IP rate limit 則被住宅代理池稀釋——一個爬蟲行動跑在幾萬個動態 IP 上，每個 IP 一天只發幾次請求，加總起來卻是一天幾百萬。

更麻煩的是這些爬蟲特別喜歡掃動態頁面。Forgejo 的 commit diff、MediaWiki 的歷史版本、文件站的搜尋結果頁——每一頁都是即時渲染，CPU 開銷遠高於靜態 HTML。當伺服器 5 分鐘內被刷上千次 diff 頁，磁碟 I/O 撐不住，整站連帶被拖垮。

把整批服務丟到 Cloudflare 後面是一種解法，但對於不希望 TLS 終止在第三方、或不想把私有 Git 流量交給美國 CDN 的站台來說並不適合。Anubis 鎖定的就是這個中間地帶——沒有 CDN 規模、又不想被吃乾抹淨的中小型自架服務。

工作量證明在伺服器層做了什麼

Anubis 的機制可以用一句話描述：每個沒帶有效 JWT cookie 的請求，會被導到一個 JavaScript 頁面，要求瀏覽器找出一個 nonce，使得 SHA-256 雜湊結果開頭有 N 個 0。

具體被雜湊的內容包含 Accept-Encoding、Accept-Language、X-Real-IP、User-Agent、當前的 UTC 週次（讓挑戰每週自動失效），以及伺服器的 key fingerprint。預設難度是 5 個前導 0，一般筆電大約 1 到 3 秒可以解出，手機則需要 5 到 10 秒。

解出來之後伺服器簽一個有效期一週的 JWT，存進瀏覽器的 cookie，後續請求只要帶這個 cookie 就直接放行。為了避免 cookie 被偷出來大量重用，Anubis 還會隨機挑一部分請求重新驗證 PoW 解答，發現偽造立刻清掉 cookie 並重新挑戰。

這個設計的關鍵不在「擋住」爬蟲，而在「拉高成本」。爬蟲若想跑無頭瀏覽器解 JS，記憶體佔用立刻上看數百 MB；若硬寫一個 native solver，每個目標站還是要花 CPU 算雜湊。當原本一天能掃幾千萬頁、現在剩幾十萬頁，AI 公司就會把預算移到沒設防的站台。

一份典型的反向代理設定

實務上 Anubis 是一個獨立的 Go binary，跑在內部 port（例如 8923），前面接 Caddy 或 Nginx Proxy Manager，後面接真正的後端服務（Forgejo、MediaWiki、文件站等）。

Caddy 的設定大致長這樣：

1
2
3

git.example.tw {
    reverse_proxy 127.0.0.1:8923
}

而 Anubis 自己的 docker-compose 則指向後端：

services:
  anubis:
    image: ghcr.io/techarohq/anubis:v1.25.0
    ports:
      - "127.0.0.1:8923:8923"
    environment:
      BIND: ":8923"
      TARGET: "http://forgejo:3000"
      DIFFICULTY: "5"
      COOKIE_DOMAIN: "git.example.tw"
      POLICY_FNAME: "/data/cfg/botPolicies.yaml"
    volumes:
      - ./cfg:/data/cfg:ro

botPolicies.yaml 控制哪些 UA 直接放行（例如 Googlebot、Bingbot 經過 reverse DNS 驗證的請求）、哪些被直接拒絕、哪些走 PoW 挑戰。Anubis 預設只對 UA 含 Mozilla 字串的請求觸發挑戰，這是一個刻意的權衡：合法的 API client、curl、wget 不會掛 Mozilla，所以不會被擋；但披著 Chrome UA 的爬蟲就一定吃挑戰。

部署完之後最好搭配站台監控（例如 Beszel 或 Telegram bot）看 PoW 通過率、5xx 比例和 CPU 變化。多數站台的觀察是頻寬下降六到九成，CPU 同步降回正常水位。

Codeberg 被繞過的教訓

2025 年 8 月 Codeberg 公開表示 AI 爬蟲學會解 Anubis 的挑戰，這件事在開源圈裡掀起一陣討論。實情並不是 Anubis 設計失敗，而是 PoW 本身就是經濟學賽局：當目標站台價值高到值得投資解題基礎建設，攻擊者就會去做。已有實作證明用 Go 或 Rust 寫的 native solver 比瀏覽器跑 JS 快十幾倍，平均成本下降到爬蟲集團可以接受的程度。

對應的回擊在 Anubis 後續版本中已陸續加入：動態調整難度、依 IP 信譽分群、結合 fingerprint 訊號做次級挑戰。但這場仗本質上不會有終結的一天，跟 captcha 演化的歷程一樣，雙方會持續來回。

務實的判斷是：對於 80% 的中小型自架站台，PoW 依然有效——攻擊者的成本仍高於收益，會優先掃軟柿子。當站台規模大到出現在 AI 公司的高價值目標清單上，才需要再疊一層 fingerprint 偵測或 WAF。

哪些站該裝、哪些不該裝

值得裝的場景非常明確：自架的 Forgejo、Gitea、Gogs、cgit、MediaWiki、BookStack、文件 Wiki、論壇（Discourse、Flarum）。這些站動態渲染重、頁面數多、又是 AI 訓練資料的主要目標。

不建議裝的也很清楚：純靜態的個人部落格、商業介紹頁、需要被 Google/Bing 索引的 SEO 內容站、公開的 API endpoint。Anubis 會擋掉沒開 JS 的瀏覽器和搜尋引擎爬蟲（除非明確把它們加進 allowlist），SEO 的損失通常大於頻寬節省。

介於兩者之間的混合站，比較好的做法是在 reverse proxy 層分路徑：/docs/* 開放給搜尋引擎和爬蟲，/wiki/edit、/repo/*/commits、/search 這類動態路徑才丟給 Anubis 處理。Caddy 的 handle_path 或 NPM 的 location regex 都可以做到，不需要為了一兩個熱點頁面把整站封起來。

把成本曲線扭回守方這邊

AI 爬蟲對開源基礎設施的衝擊還會持續好幾年，Anubis 不是銀彈，但它把成本曲線扭到對守方有利的位置。對於正在自架服務的個人或團隊，花 30 分鐘把它擺到 Forgejo 或 Wiki 前面，往往比升級 VPS 規格便宜得多。

如果手上的 VPS 已經被爬蟲流量逼到要擴容，與其加錢買頻寬不如先看流量組成。NCSE Network 提供臺灣本地的高效能 VPS 主機（Intel Gold CPU、NVMe SSD、是方電訊機房），也能協助規劃反向代理與 PoW 防護的部署架構，需要評估自架服務的防禦設計時可以參考。