VPS 自架 Firecrawl 替代方案比較

自架 Firecrawl 替代方案必須具備的功能

自架 Firecrawl 替代方案只有一項工作：接收 URL，並回傳代理程式可以讀取的乾淨 Markdown。託管 API 會按頁面計費，因此代理程式越常發出請求，費用就越高；如果你已經支付 VPS 費用，也可以用它執行相同工作。這些專案的差異集中在一個問題：你的主機是否必須啟動 headless browser（在沒有視窗的情況下執行的實際瀏覽器引擎）？

這個答案會決定記憶體用量、每個頁面的成本，以及哪些頁面會回傳空內容。本指南比較 Draco、Hound 與自架 Firecrawl release，使用固定版本安裝其中最輕量的方案，並透過 MCP（model context protocol）將它連接至代理程式。

四個專案，以及各自的實際定位

Draco 是以 Rust 撰寫的單一執行檔，採用 MIT 或 Apache-2.0 授權。版本 v0.20.5 於 16 July 2026 發布。draco scrape <url> 會將 markdown 輸出至 stdout。draco serve 會執行在 127.0.0.1:3002 上接收請求的 daemon；127.0.0.1:3002 是 Firecrawl 使用的連接埠。它不提供 container image，也不會啟動瀏覽器。

Firecrawl self-hosted 是 hosted product 背後的引擎，採用 AGPL-3.0 授權。其 docker-compose.yaml 定義七個服務：playwright-service、api、redis、rabbitmq、nuq-postgres、foundationdb 和 foundationdb-init。您可以取得完整的 crawl queue，但必須執行一個小型分散式系統。

Hound 位於 master-fetch repository，並以 hound-mcp 的名稱發布至 PyPI，採用 MIT 授權；截至 3 August 2026，版本為 13.0.1。它需要 Python 3.11 或更新版本。它首先是 MCP server，其次才是 fetcher：它會先嘗試 plain HTTP，只有在 plain fetch 回傳 blocked 時，才會啟動 Patchright 瀏覽器。

Trawl 之所以列在這裡，是因為人們搜尋其他專案時也會遇到它，但它的用途不同。它使用修改 fingerprint 的 Firefox 解決 JavaScript challenges 和 CAPTCHA，可在 *arr media stack 中取代 FlareSolverr。它不是 markdown extractor。下方的使用規範一節會說明，為何這項區別會決定它是否適合加入您的 agent stack。

瀏覽器池為何會讓小型 VPS 主機耗盡資源

每個開啟的瀏覽器分頁都是獨立的 renderer process，會保留自己的 DOM（document object model）與 JavaScript heap。因此，記憶體用量會隨同時開啟的頁面數量增加，而不是隨每天擷取的頁面數量增加。其中兩個專案都將這項成本寫入自己的 compose 檔案。

[
  {
    "label": "Firecrawl api",
    "memory_limit_gb": 8
  },
  {
    "label": "Firecrawl playwright",
    "memory_limit_gb": 4
  },
  {
    "label": "Hound (browser included)",
    "memory_limit_gb": 3
  }
]

Firecrawl 的 compose 檔案將 api container 的上限設為 8 GB，並將 Playwright container 的上限設為 4 GB，同時設定相應的 swap limit。Hound 的 compose 則為一個內含 bundled Chromium 的 container 設定 3 GB。這些上限是專案選定並公開的數值，不是對閒置系統進行測量所得；此外，Redis、RabbitMQ、PostgreSQL 與 FoundationDB 仍會額外占用資源，這些用量不包含在 Firecrawl 的數值中。

若上限高於主機實際擁有的 RAM，就沒有作用。主機耗盡記憶體時，kernel 的 out-of-memory killer 會終止某個 process，因此 container 可能會從 docker compose ps 消失，而應用程式 log 中不會留下錯誤。任何無法解釋的重新啟動後，都應讀取 dmesg -T | tail。完整 Firecrawl stack 應預留 8 GB，並將 4 GB 視為測試主機的最低需求。各項服務的數值設定方式，請參閱 Docker Compose 中的記憶體限制。

還有一項瀏覽器細節，可能讓人花上一個晚上的時間排查。Docker 會在 /dev/shm 為 container 提供 64 MB 的 shared memory，而 Chromium 會將 renderer buffer 放在其中，因此處理大型頁面時可能發生 crash。兩個瀏覽器 stack 都會提高這項配置：Hound 的 compose 包含 shm_size: "1gb"。以 Playwright 建置任何 image 時，都應複製這一行。

JavaScript 依賴程度高的頁面之擷取品質

對於靜態 HTML、伺服器端呈現的部落格、文件頁面及新聞文章，這些工具產生的 Markdown 幾乎相同，因此速度最快者勝出。差異會出現在用戶端呈現的頁面：傳送的 HTML 只是空殼，文字會在載入後由 JavaScript 載入。

Draco 會分層提升處理能力。第 0 層與第 1 層完全不執行 JavaScript，只解析 HTML。第 2 層會在行程內的 V8 isolate 中執行頁面自己的 JavaScript。這是沒有瀏覽器環境的 JavaScript 引擎；README 指出，頁面程式碼在其中無法取得主機功能繫結。這種方式只需瀏覽器一小部分的記憶體，就能處理許多單頁應用程式。當 Draco 遇到無法處理的限制時，draco scrape 會以代碼 3 結束，needs_browser。請在腳本中檢查這項結果，因為空檔案搭配成功的結束代碼，會在不知不覺中將錯誤內容寫入代理程式的上下文：

draco scrape https://example.com > page.md
echo "exit=$?"

Firecrawl 的 playwright-service 會驅動真正的 Chromium，因此能呈現瀏覽器所呈現的內容。但自架版本仍不同於代管產品：文件指出，自架執行個體無法使用 Fire Engine，因此缺少雲端服務的反封鎖與 IP 輪替功能，且不支援 /agent 與 /browser 端點。Hound 則刻意處於兩者之間。它會透過 HTTP 擷取內容，並依每個請求逐步提升處理層級；其暖機中的瀏覽器會在閒置逾時後關閉，因此安靜的伺服器仍能維持接近基準的資源使用量。

安裝固定版本的 Draco

README 提供單行安裝程式。將內容傳送給 shell 執行前，先確認它的行為：它會安裝至 $HOME/.draco/bin/draco，一律取得 latest 版本，而且不會驗證簽章或雜湊值。在伺服器上，請固定版本並驗證下載內容。

cd /tmp
curl -fsSLO https://github.com/0xchasercat/draco/releases/download/v0.20.5/draco-linux-x86-64.tar.gz
curl -fsSLO https://github.com/0xchasercat/draco/releases/download/v0.20.5/SHA256SUMS
sha256sum --ignore-missing -c SHA256SUMS

這會輸出 draco-linux-x86-64.tar.gz: OK。FAILED 行表示你取得的位元組與專案發布的內容不一致，因此請刪除檔案並重新開始。

mkdir -p draco-v0.20.5
tar -xzf draco-linux-x86-64.tar.gz -C draco-v0.20.5
sudo install -m 755 "$(find draco-v0.20.5 -type f -name draco | head -n1)" /usr/local/bin/draco
draco scrape https://example.com

最後一個命令會在遠低於 1 秒內，以 markdown 格式輸出範例頁面。find 並非裝飾性內容：封存檔的目錄結構不屬於專案的公開契約，官方安裝程式也是以相同方式尋找二進位檔。

請讓 daemon 使用專用帳號執行，不要使用你的登入使用者。寫入 /etc/systemd/system/draco.service：

[Unit]
Description=Draco fetch daemon
After=network-online.target
Wants=network-online.target

[Service]
User=draco
ExecStart=/usr/local/bin/draco serve --host 127.0.0.1 --port 3002 --max-concurrency 4
Restart=on-failure
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

sudo useradd --system --no-create-home --shell /usr/sbin/nologin draco
sudo systemctl daemon-reload
sudo systemctl enable --now draco
curl -s http://127.0.0.1:3002/health

daemon 開始監聽後，/health 會立即回應。Connection refused 表示它尚未監聽，因此請查看 journalctl -u draco -n 50。通常原因是其他程序已占用 3002，因為這也是 Firecrawl 的預設連接埠；--port 可變更其中任一方。若要深入了解 unit 檔案，請參閱：systemd 服務 unit 與 timer。

現在以 agent 實際使用的方式取得內容：

curl -X POST http://127.0.0.1:3002/v1/scrape \
  -H 'content-type: application/json' \
  -d '{"url": "https://example.com", "formats": ["markdown"]}'

讓 fetch daemon 不暴露在公用網際網路

沒有驗證機制的 fetch API 就是開放 Proxy。任何能連到該連接埠的主機，都能讓您的伺服器以您的 IP 位址請求任意 URL。濫用通報會寄給您的服務供應商，而不是寄給濫用者。Draco 的文件所列 serve 旗標不包含 API key，因此必須透過網路層提供保護。agent 與服務執行於同一台主機時，請維持預設的 127.0.0.1 綁定位址。agent 位於其他主機時，請讓兩端都使用私有 tunnel；通常可自行架設 WireGuard VPN，並將服務綁定至 tunnel 位址，而不是 0.0.0.0。接著從另一台主機確認公用 IP 沒有回應。ufw 防火牆基本設定 和 最小權限使用者帳戶 分別涵蓋這兩個部分。

代理程式碼會變更嗎？實務上的 API 相容性

Draco 回應 Firecrawl v1 路由：/v1/scrape、/v1/map、/v1/crawl、/v1/batch/scrape 和 /v1/search；其 README 也說明會接受並忽略未知欄位。已經向 /v1/scrape 發送請求的代理程式，只需改用新的 base URL，不需要其他變更。請注意另一端的變化：Firecrawl 自行代管頁面現在使用 /v2/crawl 進行測試，而目前的 SDK 使用 v2，因此將 v2 client 指向 Draco 時，會要求 Draco 未提供的路由。修改代理程式碼前，先使用 curl 測試每個呼叫，並讀取 JSON body，而不要只看 status code，因為這些實作之間最容易出現差異的是欄位名稱。

Robots.txt、速率限制，以及應停留的界線

Draco 預設會讀取 robots.txt，而 --ignore-robots 會停用此功能。Firecrawl 也記錄了相同的預設值。兩者都維持不變。接著設定自己的速率：--delay 會在請求之間加入毫秒級間隔，--max-concurrency 則限制平行工作數；daemon 預設值為 8。在共用 VPS 連線上，設定為 2 到 4 較為合適，而且整體速度通常不會變慢，因為網站開始對你套用速率限制後，所耗費的時間往往超過降低並行數所節省的時間。請快取擷取的內容，讓第二次 agent 執行不必再次增加來源的負載。這也是控制 AI agent 成本中最便宜的項目。

挑戰頁面是另一個主題，而 Trawl 正是為此設計：Cloudflare Turnstile、reCAPTCHA、hCaptcha 和 GeeTest。挑戰頁面就是網站明確拒絕自動化流量。繞過這類頁面會違反網站的使用條款，在某些地區也可能違法，因此本指南只涵蓋擷取基礎架構，並止步於此。能夠通過挑戰頁面的技術，也正是網站管理者會監控並封鎖的技術，因此建立在這些技術上的 pipeline 不僅不受歡迎，也很脆弱。當某個來源重要到這種程度時，請尋找它的 RSS feed、公開 API 或 bulk export。這些方式的執行成本都較低，而且不會在挑戰頁面變更的那一週失效。

將它透過 MCP 連接至 agent

MCP（model context protocol）是 agent 用來呼叫工具的介面。Draco 在同一個 binary 中內建 MCP server，並透過 stdio 提供服務：

{ "mcpServers": { "draco": { "command": "draco", "args": ["mcp"] } } }

這些工具會以 draco_scrape、draco_search 及 draco_interact_* 集合的形式出現在 agent 中。只有當 agent process 與 binary 位於同一台機器時，stdio 才能運作，因為傳輸使用的是該 process 的標準輸入。若 agent 位於其他主機，Hound 會改用 HTTP 提供 MCP：hound --http --host 127.0.0.1 --port 8765 會在 http://127.0.0.1:8765/mcp 發布 endpoint，您可透過 tunnel 連線。傳輸方式與應公開的內容，請參閱 在 VPS 上執行 MCP server。

使用 search 取得配對內容。只能 fetch 的 agent 必須等您提供 URL。加入 自架 SearXNG search instance 後，agent 就能自行尋找這些內容，運作方式與 以 SearXNG 建立的 browser search skill 相同。daemon 啟動後，您執行的任一 自架 AI agent 都能共用這項服務。

FAQ

我需要使用無頭瀏覽器，才能替 AI agent 擷取頁面嗎？

大多數頁面不需要。伺服器端渲染的文件、部落格與新聞文章，通常可透過一般 HTTP 擷取，再加上 HTML 轉 Markdown 的步驟取得完整內容。Draco 在較低階方案中採用這種方式；依專案自身數據，每頁約需 300 ms，且不必啟動瀏覽器。對於在用戶端渲染的應用程式，瀏覽器才有其必要性，因為傳送的 HTML 只是空殼。Draco 的 V8 isolate 可在不啟動瀏覽器程序的情況下處理許多介於兩者之間的頁面；無法處理時，會以代碼 3 結束，並回傳 needs_browser。

在 VPS 上自行託管 Firecrawl 需要多少 RAM？

其 compose 檔案為 api container 設定 8 GB 的記憶體上限，並為 Playwright container 設定 4 GB；同一組 stack 還會啟動 Redis、RabbitMQ、PostgreSQL 與 FoundationDB。請預留 8 GB。在 2 GB 的主機上，kernel 的 out-of-memory killer 會在負載過高時終止 containers；最初的跡象通常是 docker compose ps 中出現重新啟動的 container，而應用程式 log 沒有任何有用訊息。請使用 dmesg -T | tail 確認。

Draco 是 Firecrawl API 的直接替代品嗎？

對於 v1 endpoints 而言，兩者相當接近。它提供 /v1/scrape、/v1/map、/v1/crawl、/v1/batch/scrape 與 /v1/search，並會忽略不認識的請求欄位，因此針對 Firecrawl v1 撰寫的 client 通常只需更換 base URL。它不是託管式產品：背後沒有 managed proxy pool，Firecrawl 較新的 v2 routes 也不在支援範圍內。請先使用 curl，逐一驗證 agent 發出的每個呼叫。

自行託管 scraper，是否代表我可以忽略 robots.txt？

不行。程式在哪裡執行，不會改變網站發布的內容，也不會改變網站條款允許的行為。Draco 與 Firecrawl 預設都會遵守 robots.txt；override flag 僅適用於由您擁有，或您取得書面授權可進行 crawl 的網站。無論如何，遠端服務都會執行 rate limits，因此使用低 concurrency 的禮貌性 --delay，才能讓您的 IP address 持續正常運作。只能靠繞過 challenge wall 才能運作的 stack，可能在沒有預警的情況下失效。