Crawl4AI 与 Firecrawl 代理配置：RAG 数据采集不被封（2026）

Crawl4AI 和 Firecrawl 已经成了把网页数据喂进 LLM 流水线的默认方式——它们负责抓取、渲染，然后把模型真正能用的干净 Markdown 交回来。可一旦你把它们对准一个真实目标，就会发现每个爬虫人迟早都会明白的道理：抽取这一层从来不是难点。难点在于你的爬虫跑在一个数据中心 IP 上，而整个互联网都看得见。

本文给出两个工具都能用的代理配置——自托管的 Crawl4AI、以及 Firecrawl 的两种模式——外加那套能让 RAG 入库任务不在第 50 页就猝死的会话策略。它是我们 AI agent 代理指南 和 browser-use 指南 在爬取框架上的延伸。

为什么 LLM 爬虫比普通爬虫被封得更快

• 它们是广撒网，而不是精准取。一个 RAG 入库任务会在几分钟内横扫整个域名拉取上百个页面——这恰恰是 IP 信誉系统评分最狠的那种速率模式（参见 ASN 检测详解）。
• 它们默认跑无头 Chromium。Crawl4AI 底层用的是 Playwright；不加参数的话，它会暴露标准的无头痕迹。
• 它们重试得很蠢。撞上反爬墙后默认的失败重试，只会把这个 IP 的信誉烧得更深。

Crawl4AI：代理配置

Crawl4AI（开源、自托管）在 BrowserConfig 这一层接收代理——每个爬虫实例一个代理：

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 会话：cookie 和 IP 一起移动
    return BrowserConfig(
        headless=True,
        proxy_config={
            "server": "us.jibaoproxy.com:913",
            "username": f"USERNAME-session-{site_id}",
            "password": "PASSWORD",
        },
    )

# 站点 A 走出口 A，站点 B 走出口 B，并行进行

Firecrawl：两种模式，两种答案

云端 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：你通过环境变量提供自己的代理，掌握完全控制权：

# 自托管 Firecrawl 的 .env
PROXY_SERVER=http://us.jibaoproxy.com:1000
PROXY_USERNAME=USERNAME
PROXY_PASSWORD=PASSWORD

一旦你做到规模化入库，自托管 + 自己的住宅网关就是成本上更理性的搭配：你按 GB 为带宽付费，而不是按页付带 stealth 倍率的额度。

RAG 入库任务的会话策略

• 一个站点 = 一个 sticky 身份。整个站点爬取期间，cookie、缓存和出口 IP 保持一致；站点之间再轮换。（背景知识：sticky vs 轮换。）
• 尊重每个站点的节奏。Crawl4AI 的 semaphore_count / 延迟选项就是为此而设——每个站点 2–4 个并发页面足矣；把并行度分散到不同站点上去。
• 让页面失败，而不是让任务失败。遇到 403/挑战时，标记这个 URL、轮换身份、继续——透过同一出口盲目重试只会毒化它的分数。
• 校验 Markdown。反爬拦截页也能好好地转成 Markdown——"正在验证你是人类"被嵌进你的向量库，是一种实实在在的失败模式。在索引之前，先在入库输出里 grep 挑战页的标志性文字。
• 积极使用缓存。重爬没变过的页面是白白烧带宽和信誉——在框架允许的地方尊重 ETag/Last-Modified。

成本现实核对

方案	你为什么付费	何时最合适
Firecrawl 云端 + stealth 代理	按页额度 × stealth 倍率	低量、零运维
自托管 Firecrawl + 住宅 GB	仅带宽（约 $2/GB）	稳定的入库量
Crawl4AI + 住宅 GB	仅带宽，完全控制	定制流水线、深度爬取

一个文字为主的典型页面透过代理大约消耗 100–300 KB——也就是每 GB 大约 3,000–10,000 页。真正把预算炸掉的是"封禁—重试"的循环，这也是上量之前先把检测问题修好的又一个理由。

小结

• LLM 爬虫被封 = IP + 无头检测，不是框架的锅；先修网络层。
• Crawl4AI：在 BrowserConfig 里设 proxy_config；每站点一个 sticky 身份，站点之间轮换。
• Firecrawl 云端：proxy: "stealth" 参数，上量后很贵；自托管：通过环境变量用自己的网关。
• 在 Markdown 输出进入你的向量库之前，先校验里面有没有挑战页文字。
• 一旦入库稳定，按 GB 计的住宅带宽就胜过按页计的 stealth 额度。