Cấu hình proxy cho Crawl4AI và Firecrawl: thu nạp dữ liệu RAG không bị chặn (2026)

Crawl4AI và Firecrawl đã trở thành cách mặc định để đưa dữ liệu web vào các pipeline LLM — chúng thu thập, render và trả về Markdown sạch mà mô hình của bạn thực sự dùng được. Rồi bạn hướng chúng vào một mục tiêu thật và khám phá ra điều mà mọi scraper rốt cuộc đều học được: lớp trích xuất chưa bao giờ là phần khó. Phần khó là crawler của bạn chạy từ một IP datacenter duy nhất, và web có thể nhìn thấy điều đó.

Hướng dẫn này trình bày cấu hình proxy hoạt động được cho cả hai công cụ — Crawl4AI tự host và cả hai chế độ của Firecrawl — cùng với chiến lược session giúp các tác vụ thu nạp dữ liệu RAG không chết ở trang thứ 50. Nó mở rộng hướng dẫn proxy cho AI agent và hướng dẫn browser-use của chúng tôi sang các framework thu thập dữ liệu.

Vì sao crawler LLM bị chặn nhanh hơn scraper

• Chúng tải rộng, không tải có chọn lọc. Một tác vụ thu nạp RAG kéo về hàng trăm trang trên toàn bộ một domain chỉ trong vài phút — đúng kiểu mẫu tốc độ mà các hệ thống đánh giá uy tín IP chấm điểm gắt nhất (xem giải thích về phát hiện ASN).
• Chúng chạy headless Chromium theo mặc định. Crawl4AI dùng Playwright ở bên dưới; không có cờ thiết lập, nó để lộ các dấu vết headless tiêu chuẩn.
• Chúng retry một cách ngớ ngẩn. Việc retry-on-failure mặc định trước một bức tường anti-bot chỉ càng làm uy tín của IP lún sâu hơn.

Crawl4AI: Cấu hình proxy

Crawl4AI (mã nguồn mở, tự host) nhận proxy ở cấp BrowserConfig — một proxy cho mỗi instance crawler:

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

Với các lượt crawl sâu, hãy xoay danh tính theo từng instance crawler, không phải theo từng trang — các trang trong cùng một lượt thăm một site nên dùng chung một IP exit (một con người không đổi thành phố giữa trang 3 và trang 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: Hai chế độ, hai câu trả lời

Cloud API: proxy là một tham số của request — Firecrawl định tuyến qua các pool riêng của nó. Bạn kiểm soát hạng chất lượng, không phải các 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
)

Cái bẫy: các request hạng stealth bị tính phí gấp nhiều lần credit cơ bản, và bạn không thể ghim quốc gia một cách chính xác hay giữ sticky session xuyên các lần gọi. Ổn cho vài trang lẻ tẻ; đắt đỏ và thiếu chính xác ở quy mô thu nạp dữ liệu.

Firecrawl tự host: bạn cung cấp proxy của riêng mình qua biến môi trường, với toàn quyền kiểm soát:

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

Tự host + cổng residential của riêng bạn là thiết lập hợp lý về chi phí một khi bạn thu nạp dữ liệu ở quy mô lớn: bạn trả tiền theo GB cho băng thông thay vì theo credit-trên-mỗi-trang với hệ số nhân stealth.

Chiến lược session cho các tác vụ thu nạp RAG

• Một site = một danh tính sticky. Cookie, cache và IP exit giữ nhất quán suốt cả lượt crawl một site; xoay vòng giữa các site. (Bối cảnh: sticky so với rotating.)
• Tôn trọng nhịp độ riêng của từng site. Tùy chọn semaphore_count / delay của Crawl4AI tồn tại vì lý do này — 2–4 trang đồng thời cho mỗi site là đủ; thay vào đó hãy trải song song trên nhiều site.
• Để trang thất bại, đừng để cả tác vụ thất bại. Khi gặp 403/thử thách, hãy đánh dấu URL, xoay danh tính và tiếp tục — retry mù qua cùng một exit sẽ làm hỏng điểm uy tín của nó.
• Kiểm chứng Markdown. Một trang chặn trung gian anti-bot vẫn chuyển thành Markdown ngon lành — dòng "Verifying you are human" nhúng trong vector DB của bạn là một kiểu lỗi có thật. Grep đầu ra thu nạp để tìm dấu hiệu trang thử thách trước khi index.
• Cache thật mạnh tay. Crawl lại các trang không thay đổi đốt băng thông và uy tín mà chẳng được gì — tôn trọng ETag/Last-Modified ở những nơi framework cho phép.

Kiểm tra thực tế về chi phí

Thiết lập	Bạn trả tiền cho	Tốt nhất khi
Firecrawl cloud, proxy stealth	Credit theo trang × hệ số nhân stealth	Khối lượng thấp, không cần vận hành
Firecrawl tự host + GB residential	Chỉ băng thông (~$10/GB)	Khối lượng thu nạp ổn định
Crawl4AI + GB residential	Chỉ băng thông, toàn quyền kiểm soát	Pipeline tùy chỉnh, crawl sâu

Một trang nhiều chữ điển hình tốn 100–300 KB qua proxy — tương đương khoảng 3.000–10.000 trang mỗi GB. Các vòng lặp chặn-rồi-retry mới là thứ làm cháy ngân sách, đó là thêm một lý do để khắc phục chuyện bị phát hiện trước khi tăng quy mô.

Tóm tắt

• Crawler LLM bị chặn = phát hiện IP + headless, không phải do framework; hãy sửa lớp mạng trước.
• Crawl4AI: proxy_config trong BrowserConfig; danh tính sticky cho mỗi site, xoay vòng giữa các site.
• Firecrawl cloud: tham số proxy: "stealth", đắt ở quy mô lớn; tự host: cổng riêng của bạn qua biến môi trường.
• Kiểm chứng đầu ra Markdown để tìm văn bản trang thử thách trước khi nó tới vector DB của bạn.
• Residential tính theo GB thắng credit stealth theo trang một khi việc thu nạp đã ổn định.