Crawl4AI 與 Firecrawl 的 Proxy 設定：不被封的 RAG 匯入（2026）

Crawl4AI 與 Firecrawl 已成為把網頁資料餵進 LLM 流水線的預設方式 — 它們爬取、渲染，然後回傳你的模型真正能用的乾淨 Markdown。接著你把它們指向一個真實目標，就會發現每個抓取者最終都會學到的事：萃取層從來不是難的部分。難的是你的爬蟲跑在一個資料中心 IP 上，而整個網路看得見它。

本指南會示範這兩個工具的可用 proxy 設定 — 自架的 Crawl4AI 與 Firecrawl 的兩種模式 — 外加能阻止 RAG 匯入工作在第 50 頁就掛掉的工作階段策略。它把我們的 AI 代理人 proxy 指南與 browser-use 指南延伸到爬取框架。

為什麼 LLM 爬蟲比抓取器更快被擋

• 它們是廣泛抓取，而非精準抓取。一個 RAG 匯入工作會在幾分鐘內把整個網域的數百個頁面拉下來 — 正是 IP 信譽系統評分最嚴厲的那種速度模式（參見 ASN 偵測詳解）。
• 它們預設跑無頭 Chromium。Crawl4AI 底層用 Playwright；沒有加旗標的話，它會露出標準的無頭瀏覽器痕跡。
• 它們重試得很蠢。對著反機器人牆做預設的失敗重試，只會把那個 IP 的信譽燒得更深。

Crawl4AI：proxy 設定

Crawl4AI（開源、自架）在 BrowserConfig 這一層接收 proxy — 每個爬蟲實例一個 proxy：

from crawl4ai import AsyncWebCrawler, BrowserConfig, CrawlerRunConfig

browser_cfg = BrowserConfig(
    headless=True,
    proxy_config={
        "server": "us.jibaoproxy.com:913",
        "username": "USERNAME",
        "password": "PASSWORD",
    },
)

async with AsyncWebCrawler(config=browser_cfg) as crawler:
    result = await crawler.arun(
        url="https://example.com/docs",
        config=CrawlerRunConfig(),
    )
    print(result.markdown[:500])

對於深度爬取，要按爬蟲實例輪換身分，而不是按頁面 — 一次站台造訪內的各個頁面應該共用同一個出口 IP（一個人不會在第 3 頁和第 4 頁之間換城市）：

def crawler_for(site_id: str) -> BrowserConfig:
    # Sticky session per site: cookies + IP move together
    return BrowserConfig(
        headless=True,
        proxy_config={
            "server": "us.jibaoproxy.com:913",
            "username": f"USERNAME-session-{site_id}",
            "password": "PASSWORD",
        },
    )

# site A crawled through exit A, site B through exit B, in parallel

Firecrawl：兩種模式，兩種答案

雲端 API：proxy 是一個請求參數 — Firecrawl 透過它自己的 IP 池來路由。你能控制的是品質層級，而不是那些 IP：

from firecrawl import FirecrawlApp

app = FirecrawlApp(api_key="fc-YOUR-KEY")
result = app.scrape_url(
    "https://example.com/pricing",
    params={"proxy": "stealth"},   # basic | stealth | auto
)

陷阱是：stealth 層級的請求會以 basic 額度的數倍計費，而且你無法精確地綁定國家，也無法跨多次呼叫維持黏性工作階段。偶爾抓幾頁沒問題；到了匯入量級就既昂貴又不精確。

自架 Firecrawl：你透過環境變數提供自己的 proxy，擁有完整控制權：

# .env for self-hosted Firecrawl
PROXY_SERVER=http://us.jibaoproxy.com:1000
PROXY_USERNAME=USERNAME
PROXY_PASSWORD=PASSWORD

一旦你的匯入達到規模，自架 + 你自己的住宅閘道就是符合成本理性的設定：你按 GB 支付頻寬費用，而不是按頁計算還帶 stealth 倍數的額度。

RAG 匯入工作的工作階段策略

• 一個站台 = 一個黏性身分。整個站台爬取期間，cookie、快取與出口 IP 保持一致；站台之間才輪換。（背景：黏性 vs 輪換。）
• 尊重每個站台的節奏。Crawl4AI 的 semaphore_count / delay 選項就是為此而存在 — 每個站台 2–4 個並行頁面就很夠了；要把並行度分散到不同站台之間。
• 讓頁面失敗，而不是讓整個工作失敗。碰到 403/挑戰時，標記該 URL、輪換身分，然後繼續 — 透過同一個出口做盲目重試會毒害它的分數。
• 驗證 Markdown。一個反機器人插頁也能好好地轉成 Markdown — 把「正在驗證你是真人」嵌進你的向量資料庫是一種真實的失敗模式。在建立索引之前，先 grep 匯入輸出裡有沒有挑戰頁面的標記。
• 積極快取。重新爬取沒有變動的頁面是白白燒掉頻寬與信譽 — 在框架允許之處尊重 ETag/Last-Modified。

成本現實核對

設定	你付的是	最適合何時
Firecrawl 雲端、stealth proxy	按頁額度 × stealth 倍數	低流量、零維運
自架 Firecrawl + 住宅 GB	只算頻寬（約 $10/GB）	穩定的匯入量
Crawl4AI + 住宅 GB	只算頻寬，完整控制	客製化流水線、深度爬取

一個典型的文字密集頁面透過 proxy 大約耗 100–300 KB — 大致是每 GB 3,000–10,000 頁。把預算吹爆的是封鎖後重試的迴圈，這也是為什麼要在擴大流量之前先修好偵測問題的另一個理由。

總結

• LLM 爬蟲被擋 = IP + 無頭偵測，而不是框架；先修網路層。
• Crawl4AI：BrowserConfig 裡的 proxy_config；每個站台黏性身分，站台之間才輪換。
• Firecrawl 雲端：proxy: "stealth" 參數，量大時昂貴；自架：透過環境變數用你自己的閘道。
• 在 Markdown 輸出抵達你的向量資料庫之前，先驗證裡面有沒有挑戰頁面的文字。
• 一旦匯入趨於穩定，按 GB 計價的住宅就勝過按頁計算的 stealth 額度。