Heritrix 評測：WARC 完整性與封存式爬取的營運成本

Heritrix 是 Internet Archive 的開源封存爬蟲——也是 Wayback Machine 背後那條已在實際環境運作二十年的軟體譜系。它的任務，是忠實擷取網站當下回應的內容，寫入可在多年後重新播放的 WARC 檔案。從架構上看，它是一個 Java 引擎；每次爬取都是以 XML 撰寫的 Spring bean 圖，整個工作生命週期則透過 REST API 控制。它不是資料擷取器：沒有 selector 語法、沒有欄位對映，最後也不會吐出一排排資料列。

我用受控的本機測試環境對 3.16.0 進行實測，並逐筆檢查它實際寫出了什麼。最亮眼的是完整性：20 個被抓取的 URI 產生了 61 筆 WARC 記錄，每筆 response 都帶有 payload digest 與 capture IP，每筆 request 也都透過關聯回到它所屬的 response，而且這一切都不需要動任何設定開關。真正折騰人的反而是操作體驗——41 MB、114 個 jar（lib/ 內共有 142 個檔案；另外 28 個是打包進去的 LICENSE 與 NOTICE 文字），而且在第一次抓取前就得先面對約 750 行的 job 設定——不過我這次所有爬取都透過 curl 無頭完成，完全沒有點過任何 Web UI。

儲存結果也揭露了一個不那麼顯眼的預設行為。測試用的兩個 URL 回傳了逐位元完全相同的內容，而原生設定檔把它們都完整抓取並封存：兩筆 response 記錄、零筆 revisit 記錄，儘管兩個 response 的 payload digest 是一樣的。只有在加入歷史處理器後，content-digest 去重才會生效；預設設定並不啟用它，而且它省的是儲存空間，不是頻寬。

Heritrix 到底是什麼

封存不是抓資料，這一點最值得先釐清。Heritrix 不會直接給你資料列，也不會在最後產出 CSV。它的輸出其實就是 HTTP 對話本身——標頭、內文與擷取中繼資料——以專為保存設計的格式儲存；而它正是這個領域的參考實作。拿它去要一份產品價格清單，就像叫法庭速記員幫你寫摘要一樣不對題。

截至 2026 年 7 月 27 日的最新數字：這個 repo 有 3,285 顆星、36 個未解決議題，而 3.16.0 是最新釋出版本，發布於 2026-07-03。也就是說，我實測的就是這個版本，所以這裡不是在抱怨舊版問題。授權則有一個小地方要注意：LICENSE 檔本身是標準 Apache-2.0，但 GitHub 的自動偵測顯示為「Other」，因為部分第三方隨附檔案各自帶有不同條款。如果 Heritrix 要放進商業產品，這件事值得法務花五分鐘看一下，而不是只看側邊欄徽章就算了。

還有一個結構性事實，會影響其他一切：Heritrix 不會驅動瀏覽器。它是透過 HTTP 抓取，並從回傳的位元組中抽取連結。它在現代封存領域的兄弟產品 Browsertrix Crawler 則剛好相反——用真實 Chromium，記錄瀏覽器實際做了什麼。兩者都能寫出 WARC，但這篇評測只測了 Heritrix 的非瀏覽器路徑；沒有比較任何系統的規模或吞吐量。

鏈、bean 與 SURT：一場爬取到底怎麼組成

在底層，Heritrix 的 job 就是一個 Spring application context。不是「有用到 Spring」，而是它本身就是一個以 XML 撰寫的 Spring bean 圖；爬取流程的每一部分都可以替換成不同的 bean。

frontier 負責 URI queue，並按 host 分區。這也是 politeness（禮貌抓取）能運作的原因，而且後面會很重要。

processor chains 分三段做事：candidate chain（這個新發現的 URI 要不要排程？）、fetch chain（DNS、robots、HTTP 抓取、連結抽取），以及 disposition chain（寫入 WARC、更新狀態）。要替 Heritrix 增加能力，通常就是在正確的 chain 中插入對應的 processor bean；我後來把去重打開，也是用這個方式。

scope 是一組依序運作的 DecideRules，作用在 SURT 上——也就是 Sort-friendly URI Reordering Transform。它會把 http://www.example.com/a 重寫成 http://(com,example,www,)/a，讓主機名稱前綴可以按層級排序。預設 scope 是根據 seeds 的 SURT 前綴生成的。規則按順序接受或拒絕，最後命中的規則生效。

WARC writer 位在 disposition chain 裡，politeness 則由 frontier 裡三個數字決定：delayFactor、minDelayMs、maxDelayMs。robots 的遵循策略則是設定在 fetcher 上的一個 policy 字串。

而且這一切都能透過 REST API 操作，這件事比我原本預期的還重要。

設定是整個體驗裡最沉的一段

在第一次抓取之前，你需要先部署這些東西：

大部分 job 設定你平常根本不會碰，但也不能省略；在 crawler 開始抓取前，有兩個欄位是必填：你的 seed，以及 metadata.operatorContactUrl。原生值只是個占位符，在你把它改成一個可識別實際操作者的真實 URL 之前，它不會開始爬。

這個要求建立了一條問責路徑：操作者必須在爬蟲執行前提供聯絡 URL。它不能證明身分一定正確、不能證明爬取一定有授權，也不能保證符合相關規範，但它至少把聯絡資訊變成工作的一部分，而不是可有可無的習慣。

有兩個設定層面的發現，真的讓我意外。

它可以在比文件最低需求更高的新 JDK 上跑。 Getting Started 文件要求 Java 17 或更高版本。Heritrix 3.16.0 在 OpenJDK 26.0.1 上成功啟動、提供 REST API，並且在這個測試環境完成了所有爬取，過程中不需要 --add-opens、--enable-preview 或任何 Security Manager 的繞道做法。這是單一 macOS arm64 結果，不是完整相容性矩陣；但至少證明這個版本在這台主機上不是只侷限於 JDK 17。

你完全可以不碰 Web UI。 整個 job 生命週期都能靠 REST 走完，我是用 curl 把整件事自動化的：建立 job、PUT beans 檔、build、launch、unpause、輪詢直到 controller 狀態顯示 FINISHED、terminate、teardown。這才是「Heritrix 能不能放進 pipeline」的真正答案——可以，而且全程無頭，不需要點任何瀏覽器畫面。很多文章都會截 Jetty UI 的圖，讓人以為那是主要介面；其實它只是方便，不是必要。

有一個跟主機環境有關的部署細節也值得記下：這台 Mac 有透過 Surge 設定系統層級的 HTTP proxy。Heritrix 的 Java client 繼承了這個 proxy，連 127.0.0.1 的測試流量也經由代理送出，結果即使 OS 例外清單與 NO_PROXY 都在，還是拿到 503。啟動 JVM 時加上 -Djava.net.useSystemProxies=false，把測試結果從 2 次 503 變成 18 次 200。這是環境互動，不是 Heritrix 的缺陷；只有在你不想繼承系統 proxy 設定時，這個參數才有意義。

實際會被封存下來的內容

我把原生預設設定檔跑在一個受控測試環境上——本機伺服器提供一組已知端點，包括 HTML 頁面、三層深度的連結鏈、robots.txt 與 sitemap，以及故意設計的 404 和 500 路由——然後逐筆解析產出的 WARC 記錄，而不是只看摘要行就算了。

20 個被抓取的 URI 產生了 61 筆記錄：

也就是說，對每個 URI 都維持了乾淨的 1:1:1 response / request / metadata 比例，而且完全是預設行為，沒有任何我手動加的設定。逐筆檢查後，這種完整性也站得住腳：

HTTP 狀態碼也原封不動保存下來了，包括比較難看那幾種：200 OK、404 Not Found、500 Internal Server Error 都以真實狀態列的形式出現在已儲存的 response 裡，而不是被當成失敗刪掉。

最後這一點，比任何事情都更能把封存和抓資料分得很清楚。抓資料器會把 500 視為要重試或略過的錯誤；封存器則把它視為「伺服器當下就是這麼回的」，而這本身就是值得保存的事實。Heritrix Output wiki 已經描述了這種記錄結構；但我以前沒看到過的是，對一組已知端點做實測後，記錄數量與 20/20 的關聯結果竟然這麼完整。它真的就是這樣運作。

去重結果：兩種方式都測過了

我的測試環境提供 /dup/one 和 /dup/two，兩者的內容逐位元完全一致。不同 URL、相同內容——這正是 content-digest 去重要處理的情境。我跑了兩次：一次用原生設定檔，一次是在加入 digest-history 鏈之後（BdbContentDigestHistory，再加上 fetch chain 裡的 ContentDigestHistoryLoader 與 WARC writer 後面的 ContentDigestHistoryStorer）。

在預設狀態下，兩個 response 雖然拿到相同 digest，但沒有任何 history processor 去處理它，因此兩份 payload 都完整寫入了檔案。加上那條鏈之後，第二次擷取就變成一筆指向相同 payload digest 的 WARC revisit 記錄，這正是 WARC 1.1 規格對 revisit 的定義。

這些並不是什麼秘密。Duplication Reduction Processors wiki 頁面已經說明 skipIdenticalDigests 預設為 false，而且要做不依賴 URL 的去重，必須加入那些 loader 與 storer bean。這不是「被我挖出來的隱藏行為」；幾乎我在這裡測到的每一件事，都是文件早就寫明的 Heritrix 行為，只是我補上了第一手數字。落差不是文件，而是人們的理解；而我看過的理解通常都停在「Heritrix 會去重」這句話，沒有任何關於設定的註解。

兩個值得牢記的推論：

去重發生在寫入時，不是發生在頻寬上。 這點是從機制直接推導出來的，不是我另外用儀表量的；但 content digest 的原理本來就如此：只有等位元組都到齊後才能比對 digest，所以第二個 URL 一樣會先從來源端被抓回來。啟用那條鏈，減少的是你存了多少，不是你傳了多少，也不是目標伺服器得回多少。把去重算進禮貌抓取或頻寬節省，方向其實是反的。

建立在「反正會去重」上的儲存估算，常常會嚴重失準。 如果你要封存的是一個模板重複率很高的網站——例如鏡像 PDF、標準化的落地頁、同一篇文章的列印版——卻把磁碟容量估算成相同內容會自動壓縮，那麼原生設定檔實際吃掉的空間可能會比你想像的大很多。兩個 URL 的測試只能證明預設行為，不代表在百萬級 URI 下的效果；那個效果取決於重複率、payload 大小與重爬設計。

Scope 與 robots 的表現，跟它們承諾的一樣

爬蟲自己說「沒抓到」的話，其實沒什麼價值，所以這兩項都用伺服器端的 hit counter 量過——由目標伺服器自己統計請求次數，與 Heritrix 的日誌無關。

Scope。 同時，範圍內的 host 仍然正常被爬取，所以 scope 的約束是正常運作的，而不是爬取壞掉了。要補一個說明：我這裡只跑了預設 scope 的這一邊，沒有做擴大 scope 的正向控制，因此請把它理解成對文件設計的驗證，而不是雙向證明。

Robots。 這個連結本來就可以被存取；只有 robots policy 阻擋了它。遵守是真的，留有逃生口也是真的，這樣的設計才合理——有些封存需求本來就必須凌駕 robots，而這應該要靠你刻意把 ignore 寫進設定檔來啟用。

禮貌抓取：抓 20 個本機頁面花了 57.7 秒

有一個數字，足以決定 Heritrix 適不適合你的專案。

同一個測試環境、同樣三輪處理、同一台本機 host、延遲低於毫秒級：

實際延遲幾乎就卡在 minDelayMs 的下限：對一個延遲低於毫秒的來源站來說，delayFactor × fetch-time 幾乎可以忽略，真正主導的是下限本身。兩列之間的倍率其實沒什麼參考價值，因為「關掉禮貌延遲」那一列的分母只有幾十毫秒，而且每次執行都會有抖動。真正穩定的是絕對下限：預設 Heritrix 在這個測試環境中，每次對同一 host 的請求大約都會等三秒，把 20 頁的爬取拉成接近一分鐘的總時間。

給你一個具體感受：假設某大學圖書館得在一個政府網站退役前，把 50,000 頁全部封存，而且都在同一個 host 上。以每 host 3 秒下限計算，光是強制等待就有 150,000 秒——大約 42 小時，也就是快兩天，還沒算抓取本身的時間。這是依據我量到的 3,036 ms 下限換算的：50,000 × 3.036 秒 = 151,800 秒 = 42.2 小時；就算直接採設定值 3,000 ms，也還是 41.7 小時，四捨五入就是 42，而不是 41。這不是我實測的完整爬取，但卻是你的專案計畫需要的算術。

公平地說，Heritrix 的 politeness 是以 host 為單位運作，因為 frontier 本來就是按 host 分 queue。跨上千個網域的大範圍爬取，會在這些 queue 之間平行化，因此不會把這個上限整體套在所有請求上。我的測試環境只有單一 host，這正是這個數字的最壞情況；如果你的封存目標是一個大型單站，這個最壞情況就是你的現況。

而且這是個特性。這個延遲，正是讓封存爬蟲變成「站長能容忍而不是直接封鎖」的原因。把它調低，是在替別人的伺服器做決定；而這個工具會把決定攤在檯面上，而不是預設走激進路線。

我沒有測的部分

這些量測只涵蓋受控測試環境中的爬取紀律，不延伸到更廣的情境。超出邊界之外的部分包括：

• 跨次爬取去重與重爬。 我只測了單次爬取內的 content-digest 去重。要跨不同爬取持續保留 URI 歷史資料庫（FetchHistoryProcessor + PersistLog）是另一套機制，我沒有驗證。
• 規模與長期穩定性。 沒有百萬 URI frontier、沒有 checkpoint-and-restore、也沒有多日執行。我的測試驗證的是紀律，不是耐久力。
• JavaScript 渲染內容的擷取。 Heritrix 預設走非瀏覽器路徑，而我測的也是這條路。選配的瀏覽器式行為在這裡沒有測試。
• 高延遲來源站上的 polite 機制。 本機延遲低於毫秒，因此 minDelayMs 本來就會主導。delayFactor 在真實慢站上的放大效果，並沒有在我的資料中獨立出來。
• sitemap 回收率。 robots.txt 有被請求，而且 sitemap 指令有被遵循，但我沒有另外逐一確認每個 <loc> 條目是否都被抓到。

第一個正式工作前，哪些事要先明確化

原生設定檔很長，但會改變封存意義的決策其實不多。先從 scope 開始。Seeds 會生成預設 SURT 前綴，而 DecideRules 可以依序擴大或縮小範圍。先用代表性的範圍內與範圍外 URL 檢查最後的規則順序，再用伺服器端流量或其他獨立請求日誌驗證。只看 crawl report，無法證明某個被排除的 host 從未被碰到。

接著，先決定 robots policy 與操作者身分對這次蒐集代表什麼。這次測試的預設行為會遵守 fixture 的 disallow 規則，而把 robotsPolicyName 改成 ignore 之後，原本被擋的路徑就會被抓到。這個切換在機械上很簡單，但在制度上很重要。除了可用的 operatorContactUrl 之外，也應該把誰批准了這個決定、為什麼批准，一併記錄下來；必要的 URL 只是給站方一條聯絡路徑，並不會補上授權理由。

儲存規劃也需要自己做明確選擇。如果你希望相同內容變成 revisit 記錄，那就要在估算檔案容量前先加入並檢查 content-digest history processors。這次測到的鏈是在抓取之後改變表示方式，所以來源端的流量仍然要把兩個 URL 都算進去。跨爬取去重是另一種機制，不應該從這個「兩個 URL、單次爬取」的結果直接推論出來。拿一個已知有重複內容的小型驗證爬取來測試，是確認部署後 bean 圖是否真的產生預期記錄類型的便宜方法。

最後，把 politeness 當成排程輸入，而不是臨時才調的旋鈕。就這個本機單 host 測試環境而言，minDelayMs 幾乎完全決定了總時間。實務專案應該用目標 host 數量和蒐集期限，去對照每 host 的配置下限，再在具有代表性的延遲條件下測試。廣域爬取與單站爬取對 host 分區 frontier 的壓力完全不同；這篇評測只量了後者。REST 的生命週期也應該納入 runbook：build、launch、unpause、poll、terminate、teardown 都是值得在自動化中追蹤的獨立狀態。

優點與缺點

優點

• 預設就有很好的封存完整性：20/20 response 都帶有 payload digest、capture IP，以及完整 request↔response 關聯，不需任何設定。
• 會如實保存錯誤回應——200、404、500 狀態列都原封不動保留。
• 以伺服器端計數器驗證 scope 紀律：範圍外抓取為零，而範圍內 host 則正常爬取。
• robots 遵循真的會抑制抓取，而且為有明確封存需求時保留了可刻意啟用的 ignore 逃生門。
• 可完全無頭、只靠 REST 操作——建立、建置、啟動、輪詢、teardown，全部都能用 curl 完成，不必點 UI。
• 在 OpenJDK 26.0.1 上可乾淨執行，且不需要任何 JVM 參數，這點比多數二十年老程式碼庫更符合現代 Java 的使用方式。
• 強制要求 operator contact URL，表示 crawler 不會匿名執行。
• 爬取流程的每一部分都是可替換的 bean，所以我只用三個 bean 插入就能開啟去重，而不是分支重構。

缺點

• content-digest 去重預設關閉，而且會把相同 payload 完整寫入——對儲存規劃來說是個真實陷阱。
• 部署負擔很重：41 MB 發行包、114 個 jar、Java 引擎加 Jetty、以及約 750 行的 Spring job 設定。
• 預設 politeness 會帶來每 host 約 3 秒的下限；20 個 URI、單一 host 的爬取就花了 57.7 秒。
• 預設路徑沒有 JavaScript 渲染，所以只能由前端產生的內容抓不到。
• 設定面對熟手友善、對一般使用者不友善；沒有五分鐘內完成第一次爬取的路徑。
• 輸出不是結構化資料。要從 WARC 取出欄位，得再做一個獨立專案。

誰適合用，誰該直接跳過

Heritrix 是給那些交付成果就是封存本身的機構與團隊使用的。圖書館、國家檔案館、法務與合規保存、把網頁當一手資料來蒐集的研究團隊、以及任何需要在五年後證明某個 URL 在特定日期曾提供過什麼的人。如果你已經在用「WARC」、「replay」與「provenance」這些詞，那這就是你整個生態系本來就圍繞的工具，而它的重量，就是換來這種互通性的代價。

它的 host 分區 frontier 與長期的網頁封存經驗，使它成為跨多網域廣域爬取的合理候選。這是架構與專案歷史上的考量，不是這個測試環境的規模結果；長期吞吐量、checkpoint 回復與百萬 URI 行為，這裡都還沒測。

如果你要的是資料而不是封存，就直接跳過。若你的目標是把產品、清單或聯絡人整理成試算表，Heritrix 會很完美地把頁面抓下來，然後你還得另外寫一條管線把資料解析出來——而你會為了這件事付出 Java 引擎、Spring 設定，以及 3 秒禮貌延遲的成本。若你的目標是前端渲染的 SPA，也請跳過，因為非瀏覽器抓取器只會抓到 shell，不會抓到內容；那種情境應該用瀏覽器型封存器。還有，如果你今天就需要第一個結果，也請跳過，因為上手曲線是真的存在。

替代方案，以及代管 API 何時合適

在封存領域，直接的現代對應物是 Browsertrix Crawler——它是瀏覽器型封存器，會驅動 Chromium 並記錄瀏覽器實際做了什麼。它可以擷取 Heritrix 預設 HTTP 回應拿不到的 JavaScript 產生內容，但也會增加瀏覽器部署與執行成本。這篇評測沒有做 head-to-head 比較，所以決策應該從擷取需求開始：需要瀏覽器生成的狀態，就偏向瀏覽器型封存器；傳統 HTTP 資源，則仍是 Heritrix 的原生路徑。

相關評測：Browsertrix Crawler 評測。

如果你面對的是完全不同的問題——你不要封存，而是想從頁面中取得結構化資料——那就應該用輸出結果來比較 Heritrix 與抽取系統，而不是把它們當成同一類爬蟲。Heritrix 是免費且自架的：你自己跑 JVM、自己維護 beans 檔、自己估算磁碟、自己調禮貌延遲。當你的交付物是保存本身時，這模型就很合適。

揭露： Thunderbit 是本出版方的產品，並未在這個 Heritrix 測試環境中進行測試。它屬於代管式抽取工具：輸出的是頁面內容或結構化紀錄，而不是適合長期保存的 WARC 檔。當你需要可重播的封存與來源追溯時，請選封存器；當你要的是資料列或文件文字，且能接受代管操作時，再考慮抽取服務。

封存還有自己的授權問題，而且這和一般抓資料不完全一樣。Heritrix 預設會遵守 robots.txt，並要求你在抓取任何位元組前先表明身分，這是很好的基線——但符合 robots 的爬取，不代表就自動等於授權合法。著作權、服務條款、個資與你所屬機構的任務範圍，都會疊加在上面；ignore policy 是給有法律依據的組織使用的，不是方便的切換開關。如果你正在建立封存計畫，請在磁碟塞滿之前先把授權範圍釐清；若這對你來說是新領域，也可以看看 網頁抓取與封存的法律面。

試試 Thunderbit 做網頁資料擷取

結論

Heritrix 值不值得用？值得——如果你的輸出是封存，而且你願意找人去學 Spring bean。

這個測試環境已經給出很清楚的判斷：原生設定檔穩定保留了 response、request 與 capture metadata；scope 與 robots 控制能依設定影響伺服器端抓取；整個 job 生命週期也能透過 REST 跑完。以這個單一 host 的小範圍測試來看，這些都是相當實用的封存管線特性。

營運成本也同樣明確：Java 發行包與龐大的 Spring 設定、在本地測試中主導時間的每 host 延遲、以及需要額外 history processors 才會啟用的 content-digest 去重。需要 WARC 完整性的團隊，可能會接受這些成本；需要抽出欄位的團隊，則應該從別的類別開始。

在正式爬取之前，請先拿實際 job 設定確認去重鏈、禮貌延遲、scope、robots policy、操作者身分與儲存假設。原生設定檔只是起點，不代表這些營運決策已經被隱含決定好了。

試試 Thunderbit 做網頁資料擷取 Get Started Free

常見問題

operatorContactUrl 會讓爬取變成已授權嗎？ 不會。它只是強制 job 必須帶上一個聯絡 URL，讓站方有一條可追溯的問責路徑，但並不代表已獲授權、身分正確、著作權狀態合法，或符合相關法規。這些都仍是 crawler 外部的部署決策。

content-digest 去重會減少對來源站的請求嗎？ 在這次測試的設定中不會。兩個 URL 都先被抓回來，之後才比對它們的 payload digest。history chain 改變的是第二份 payload 在 WARC 儲存中的表示方式，而不是把第二個 URL 變成被跳過的網路請求。

Heritrix 可以不使用 Web UI 嗎？ 可以。這次測試的整個生命週期——建立、上傳設定、建置、啟動、unpause、輪詢、終止與清理——全都透過 REST API 與 curl 完成。內嵌 Jetty UI 並不是必需的。

原生 Heritrix 設定檔會自動去重相同 payload 嗎？ 以這次設定來看，不會。原生設定檔會把兩個相同 response 都存成完整的 response 記錄。加入 content-digest history chain 之後，第二次擷取才會變成 revisit 記錄，所以去重是你必須自行配置與驗證的管線選擇，不是自動預設行為。

我應該怎麼選 politeness 延遲？ 把這裡的本機時間數據當作機制驗證，而不是正式建議。延遲應根據目標站規則、與站方的協議、伺服器容量、爬取目的，以及你自己的重試與併發策略來設定，然後再用日誌確認實際同 host 請求間隔。