Crawl4AI と Firecrawl のプロキシ設定: ブロックされない RAG 取り込み（2026）

Crawl4AI と Firecrawl は、Web データを LLM パイプラインに流し込む標準的な手段になりました。クロールし、レンダリングし、モデルが実際に使えるきれいな Markdown を返してくれます。ところが実際のターゲットに向けてみると、どんなスクレイパーもいずれ学ぶ事実に気づきます。難しいのは抽出レイヤーではなかったのです。難しいのは、あなたのクローラーが 1 つのデータセンター IP から動いていて、Web 側にはそれが見えているという点です。

本ガイドでは、両ツール（セルフホスト型の Crawl4AI と Firecrawl の両モード）で実際に動くプロキシ設定に加え、RAG 取り込みジョブが 50 ページ目で死なないようにするセッション戦略を示します。これは当社の AI エージェント向けプロキシガイド と browser-use ガイド をクロールフレームワークへ拡張した内容です。

なぜ LLM クローラーはスクレイパーより早くブロックされるのか

• 外科的にではなく、広範に取得するから。 RAG 取り込みジョブは数分でドメイン全体の数百ページを引っ張ってきます。これはまさに IP レピュテーションシステムが最も厳しく採点する速度パターンです（ASN 検出の解説 を参照）。
• デフォルトでヘッドレス Chromium を動かすから。 Crawl4AI は内部で Playwright を使っており、フラグなしでは標準的なヘッドレスの痕跡が出ます。
• 愚直にリトライするから。 アンチボットの壁に対するデフォルトの失敗時リトライは、その IP のレピュテーションをさらに深く焼くだけです。

Crawl4AI: プロキシ設定

Crawl4AI（オープンソース、セルフホスト型）は BrowserConfig レベルでプロキシを受け取ります。クローラーインスタンスごとに 1 つのプロキシです:

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])

ディープクロールでは、ページ単位ではなくクローラーインスタンス単位でアイデンティティをローテーションしてください。1 つのサイト訪問内のページは 1 つの出口 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: 2 つのモード、2 つの答え

クラウド API: プロキシはリクエストパラメータです。Firecrawl は自前のプールを経由してルーティングします。あなたが制御できるのは品質ティアであって、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 クレジットの数倍で課金され、国を厳密に固定したり、呼び出しをまたいで sticky セッションを保持したりはできません。たまにページを取る程度なら問題ありませんが、取り込みボリュームでは高コストかつ不正確です。

セルフホスト型 Firecrawl: 環境変数で自前のプロキシを供給し、完全に制御できます:

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

スケールして取り込みを行う段階では、セルフホスト型 + 自前の住宅用ゲートウェイがコスト的に合理的な構成です。stealth 倍率付きのページ単位クレジットではなく、帯域に対して GB 単位で支払うことになります。

RAG 取り込みジョブのためのセッション戦略

• 1 サイト = 1 つの sticky なアイデンティティ。 Cookie、キャッシュ、出口 IP をそのサイトのクロール全体で一貫させ、サイト間でローテーションします。（背景: sticky vs rotating。）
• サイトごとのペースを尊重する。 Crawl4AI の semaphore_count / delay オプションはこのためにあります。1 サイトあたり同時 2〜4 ページで十分です。並列性はサイト間に広げてください。
• ジョブではなくページを失敗させる。 403／チャレンジが出たら、その URL に印を付け、アイデンティティをローテーションして続行します。同じ出口を通したやみくもなリトライはそのスコアを汚染します。
• Markdown を検証する。 アンチボットの中間ページも問題なく Markdown に変換されてしまいます。「あなたが人間であることを確認しています」がベクトル DB に埋め込まれるのは現実に起こる失敗モードです。インデックス前に取り込み出力をチャレンジページのマーカーで grep してください。
• 積極的にキャッシュする。 変更のないページを再クロールするのは、無意味に帯域とレピュテーションを焼くだけです。フレームワークが許す範囲で ETag／Last-Modified を尊重しましょう。

コストの現実チェック

構成	支払う対象	適した場面
Firecrawl クラウド + stealth プロキシ	ページ単位クレジット × stealth 倍率	低ボリューム、運用ゼロ
セルフホスト型 Firecrawl + 住宅用 GB	帯域のみ（約 $10/GB）	安定した取り込みボリューム
Crawl4AI + 住宅用 GB	帯域のみ、完全制御	カスタムパイプライン、ディープクロール

テキスト中心の典型的なページはプロキシ経由で 100〜300 KB ほど、おおよそ 1 GB あたり 3,000〜10,000 ページに相当します。予算を吹き飛ばすのはブロック＆リトライのループです。これも、ボリュームを拡大する前に検出を直しておくべきもう 1 つの理由です。

まとめ

• LLM クローラーのブロック = フレームワークではなく IP + ヘッドレス検出。まずネットワークレイヤーを直す。
• Crawl4AI: BrowserConfig 内の proxy_config。サイトごとに sticky なアイデンティティ、サイト間でローテーション。
• Firecrawl クラウド: proxy: "stealth" パラメータ、ボリュームでは高コスト。セルフホスト: 環境変数で自前のゲートウェイ。
• Markdown 出力をチャレンジページのテキストについて検証してから、ベクトル DB に到達させる。
• 取り込みが安定すれば、GB 単位の住宅用がページ単位の stealth クレジットに勝る。