راهاندازی پروکسی برای Crawl4AI و Firecrawl: دریافت داده RAG بدون بلاک (۲۰۲۶)

Crawl4AI و Firecrawl به روش پیشفرض تغذیهٔ دادهٔ وب به پایپلاینهای LLM تبدیل شدهاند — کرال میکنند، رندر میکنند و Markdown تمیزی به شما برمیگردانند که مدلتان واقعاً بتواند از آن استفاده کند. بعد آنها را به یک هدف واقعی نشانه میروید و چیزی را کشف میکنید که هر اسکرپری بالاخره یاد میگیرد: لایهٔ استخراج هیچوقت بخش سخت ماجرا نبود. بخش سخت این است که کرالر شما از یک IP دیتاسنتر اجرا میشود و وب میتواند آن را ببیند.

این راهنما پیکربندی کاربردی پروکسی برای هر دو ابزار را نشان میدهد — Crawl4AI سلفهاست و هر دو حالت Firecrawl — به علاوهٔ استراتژی سشنی که جلوی مردن کارهای دریافت داده برای RAG در صفحهٔ ۵۰ را میگیرد. این راهنما راهنمای پروکسی ایجنت هوش مصنوعی و راهنمای browser-use را به فریمورکهای کرال گسترش میدهد.

چرا کرالرهای LLM سریعتر از اسکرپرها بلاک میشوند

• گسترده دریافت میکنند، نه هدفمند. یک کار دریافت داده برای RAG در چند دقیقه صدها صفحه را در سراسر یک دامنه میکشد — دقیقاً همان الگوی سرعتی که سیستمهای اعتبار IP سختترین امتیاز را به آن میدهند (به توضیح تشخیص ASN نگاه کنید).
• بهطور پیشفرض Chromium headless اجرا میکنند. Crawl4AI زیر کاپوت از Playwright استفاده میکند؛ بدون فلگ، آرتیفکتهای استاندارد headless را نشان میدهد.
• احمقانه تلاش مجدد میکنند. تلاش مجدد پیشفرض هنگام شکست علیه یک دیوار ضدبات فقط اعتبار 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 خروجی مشترک داشته باشند (یک انسان بین صفحهٔ ۳ و صفحهٔ ۴ شهرش را عوض نمیکند):

def crawler_for(site_id: str) -> BrowserConfig:
    # سشن استیکی به ازای هر سایت: کوکیها + 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: دو حالت، دو پاسخ

Cloud 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 محاسبه میشوند، و نمیتوانید کشورها را دقیق پین کنید یا سشنهای استیکی را در طول فراخوانیها نگه دارید. برای صفحات گاهبهگاه مناسب است؛ در حجم دریافت داده گران و نادقیق.

Firecrawl سلفهاست: پروکسی خودتان را از طریق متغیرهای محیطی تأمین میکنید، با کنترل کامل:

# فایل .env برای Firecrawl سلفهاست
PROXY_SERVER=http://us.jibaoproxy.com:1000
PROXY_USERNAME=USERNAME
PROXY_PASSWORD=PASSWORD

سلفهاست + گیتوی مسکونی خودتان وقتی در مقیاس دریافت داده میکنید راهکار منطقی از نظر هزینه است: به جای اعتبار به ازای هر صفحه با ضریب stealth، برای پهنای باند به ازای هر گیگابایت پول میدهید.

استراتژی سشن برای کارهای دریافت داده RAG

• یک سایت = یک هویت استیکی. کوکیها، کش و IP خروجی برای کل کرال سایت ثابت میمانند؛ بین سایتها بچرخانید. (زمینه: استیکی در برابر چرخشی.)
• آهنگ به ازای هر سایت را رعایت کنید. گزینههای semaphore_count / تأخیر Crawl4AI برای همین وجود دارند — ۲ تا ۴ صفحهٔ همزمان به ازای هر سایت کافی است؛ به جایش موازیسازی را در میان سایتها پخش کنید.
• صفحه را شکست بدهید، نه کار را. در یک 403/چالش، URL را علامتگذاری کنید، هویت را بچرخانید و ادامه دهید — تلاش مجدد کورکورانه از همان خروجی امتیازش را مسموم میکند.
• Markdown را اعتبارسنجی کنید. یک صفحهٔ میانی ضدبات هم بهخوبی به Markdown تبدیل میشود — «در حال تأیید اینکه انسان هستید» جاسازیشده در دیتابیس برداری شما یک حالت شکست واقعی است. قبل از ایندکس کردن، خروجی دریافت داده را برای نشانگرهای صفحهٔ چالش grep کنید.
• تهاجمی کش کنید. کرال مجدد صفحات بدون تغییر، پهنای باند و اعتبار را بیدلیل میسوزاند — هرجا فریمورک اجازه میدهد ETag/Last-Modified را رعایت کنید.

بررسی واقعیت هزینه

راهکار	برای چه چیزی پول میدهید	بهترین زمان
Firecrawl ابری، پروکسی stealth	اعتبار به ازای هر صفحه × ضریب stealth	حجم پایین، بدون عملیات
Firecrawl سلفهاست + گیگابایت مسکونی	فقط پهنای باند (~۱۰ دلار/گیگابایت)	حجم دریافت داده پایدار
Crawl4AI + گیگابایت مسکونی	فقط پهنای باند، کنترل کامل	پایپلاینهای سفارشی، کرالهای عمیق

یک صفحهٔ معمولی پرمتن از طریق پروکسی ۱۰۰ تا ۳۰۰ کیلوبایت هزینه دارد — تقریباً ۳٬۰۰۰ تا ۱۰٬۰۰۰ صفحه به ازای هر گیگابایت. حلقههای بلاک-و-تلاش-مجدد آن چیزی هستند که بودجه را میترکانند، که دلیل دیگری است برای اینکه تشخیص را قبل از مقیاسدهی حجم رفع کنید.

جمعبندی

• کرالرهای LLM بلاکشده = تشخیص IP + headless، نه فریمورک؛ اول لایهٔ شبکه را رفع کنید.
• Crawl4AI: proxy_config در BrowserConfig؛ هویت استیکی به ازای هر سایت، بین سایتها بچرخانید.
• Firecrawl ابری: پارامتر proxy: "stealth"، در حجم بالا پرهزینه؛ سلفهاست: گیتوی خودتان از طریق متغیرهای محیطی.
• خروجی Markdown را قبل از رسیدن به دیتابیس برداری برای متن صفحهٔ چالش اعتبارسنجی کنید.
• وقتی دریافت داده پایدار شد، مسکونی به ازای هر گیگابایت از اعتبارهای stealth به ازای هر صفحه بهتر است.