طرح «Firecrawl را در Docker راهاندازی کردم، به لیست دامنهها هدایت کردم، markdown برای RAG دریافت کردم» تا هزار صفحه اول به خوبی کار میکند. بعد از آن دو صورتحساب میآید. اولی — از ضد رباتها: بخشی از دامنهها به جای محتوا 403 را برمیگردانند و در پایگاه دانش حفرههایی ایجاد میشود که وقتی دستیار پاسخ میدهد «در مواد ارائه شده اطلاعاتی وجود ندارد» متوجه میشوید. صورتحساب دومی — برای ترافیک: خزنده به طور صادقانه هر تصویر و هر فونتی را که در markdown نهایی به هر حال وارد نخواهد شد، بارگیری میکند.
بیایید بررسی کنیم چگونه میتوان پروکسی را به سه خزنده LLM پرکاربرد سال 2026 — Firecrawl، Crawl4AI و Crawlee — متصل کرد و چگونه آنها را تنظیم کنیم تا پروکسی فقط در جاهایی که نیاز است کار کند و نه اینکه گیگابایتها را در هر صفحه بسوزاند.
این راهنما برای چه کسانی است
اگر شما در حال جمعآوری مجموعهای از اسناد برای RAG هستید، پایگاه دانش داخلی را پر میکنید، خط لوله داده برای آموزش مجدد میسازید یا به سادگی به طور منظم صدها دامنه را بارگیری میکنید — این مورد شماست. هر سه ابزار زیر در پیکربندی پیشفرض با IP سرور شما کار میکنند و صفحه را به طور کامل بارگذاری میکنند. هر دو این پیشفرضها باید تغییر کنند.
مقیاس مشکل با اعداد محبوبیت مشخص است: Firecrawl در زمان انتشار حدود 170 هزار ستاره در GitHub دارد (مجوز AGPL-3.0)، Crawl4AI حدود 79 هزار، و Crawlee از Apify حدود 25 هزار. این دیگر آزمایشهای نیش نیستند، بلکه ابزارهای استاندارد هستند و سیستمهای ضد ربات رفتار آنها را به خوبی شما میشناسند.
صورتحساب اول: 403 به جای محتوا
خطای کلیدی در جمعآوری مجموعه — این است که فکر کنید خزنده به درستی کار کرده است اگر سقوط نکرده باشد. Firecrawl و Crawl4AI در صفحه مسدود شده نتیجهای به جز استثنا برمیگردانند: صفحهای که ضد ربات است، صفحهای با بررسی مرورگر یا متنی کوتاه درباره رد دسترسی. به طور رسمی این markdown معتبری است، به آرامی در پایگاه وکتوری قرار میگیرد و تا اولین درخواست کاربر در آنجا زندگی میکند.
بنابراین اولین کاری که باید قبل از هر تنظیم پروکسی انجام دهید — افزودن کنترل کیفیت نتیجه است. حداقل گزینه: مستندات کوتاهتر از یک آستانه خاص را رد کنید (برای یک صفحه محتوایی معمولی منطقی است 500–800 کاراکتر متن) و به طور جداگانه نشانههای خاصی را در متن شناسایی کنید — اشاره به بررسی اتصال، JavaScript فعال، «دسترسی رد شده». چنین مستنداتی به پایگاه داده ارسال نمیشوند، بلکه به صف برای مرور مجدد — از طریق پروکسی — فرستاده میشوند.
صورتحساب دوم: گیگابایتهایی که دور میریزید
در اینجا ریاضیات کمک میکند. بر اساس دادههای Web Almanac از HTTP Archive برای سال 2025، صفحه اصلی میانه حدود 2.86 مگابایت در دسکتاپ و 2.56 مگابایت در موبایل وزن دارد. از این مقدار، حدود 1,059 کیلوبایت به تصاویر در صفحات اصلی و 911 کیلوبایت به تصاویر در صفحات داخلی اختصاص دارد، و 697 کیلوبایت و 632 کیلوبایت به JavaScript به ترتیب. یعنی تصاویر سنگینترین دسته هستند، تقریباً یک سوم وزن صفحه.
حالا به یاد بیاورید که چه کاری با نتیجه انجام میدهید. شما صفحه را به markdown تبدیل میکنید و آن را به تکههایی برای جاسازی تقسیم میکنید. تصاویر به این خط لوله اصلاً وارد نمیشوند — در بهترین حالت فقط یک خط با متن alt باقی میماند. ویدیوها، فونتها، اسکریپتهای تحلیلی، پیکسلهای تبلیغاتی — نیز دور میمانند.
اگر مرور را از طریق پروکسی مقیم با پرداخت به ازای گیگابایت انجام دهید، شما به معنای واقعی کلمه برای تحویل دادههایی که در مرحله بعد دور میریزید، هزینه میکنید. در مجموعهای با 100 هزار صفحه، تفاوت بین «بارگیری همه» و «فقط بارگیری HTML و متن» نه به درصدها، بلکه به بارها اندازهگیری میشود. صرفهجویی دقیق بستگی به موضوع سایتها دارد: رسانه و تجارت الکترونیک سنگینتر از مستندات و وبلاگها هستند.
مرحله 1. افزایش به جای «پروکسی برای همه»
اصلیترین تکنیک معماری که بیشترین صرفهجویی را به همراه دارد: اجازه ندهید تمام ترافیک از طریق پروکسی عبور کند. بخش عمدهای از دامنهها در جمعآوری پایگاه دانش — مستندات، وبلاگها، سایتهای مرجع، پورتالهای دولتی — محتوا را به طور مستقیم ارائه میدهند و کسی را مسدود نمیکنند. پروکسی برای اقلیت نیاز است.
طرح صحیح — افزایش چند سطحی: ابتدا درخواست مستقیم، در صورت نشانههای مسدود شدن — به سطح بعدی بروید. و این یک راهحل سفارشی نیست، هر دو فریمورک بزرگ به طور پیشفرض این قابلیت را دارند.
در Crawlee برای این کار tieredProxyUrls وجود دارد. سطوح از ارزان به گران فهرست میشوند و خزنده خود به خود در صورت مسدود شدن به سمت بالا میرود و سپس به طور دورهای سعی میکند به سطح پایینتر برگردد:
const proxyConfiguration = new ProxyConfiguration({
tieredProxyUrls: [
[null],
['http://user:pass@datacenter-proxy:8080'],
['http://user:pass@residential-proxy:8000'],
]
});نکته مهم از مستندات: tieredProxyUrls فقط در صورت استفاده از طریق نمونه خزنده کار میکند. فراخوانیهای مستقیم newUrl() نتیجه غیرمنتظرهای خواهند داشت.
در Crawl4AI مکانیزم مشابهی در نسخه 0.8.5 ظاهر شده و در شاخه فعلی زندگی میکند (آخرین انتشار در زمان انتشار — v0.9.2 از 15 ژوئیه 2026). این مکانیزم به نام افزایش پروکسی شناخته میشود و مستقیماً در CrawlerRunConfig تنظیم میشود: تشخیص مسدودسازی سهسطحی — فروشندگان شناخته شده ضد ربات، شاخصهای عمومی مسدودسازی و بررسی یکپارچگی ساختاری صفحه — به علاوه تلاش مجدد خودکار از طریق زنجیره پروکسی.
from crawl4ai import CrawlerRunConfig
from crawl4ai.async_configs import ProxyConfig
config = CrawlerRunConfig(
proxy_config=[ProxyConfig.DIRECT, ProxyConfig(server="http://my-proxy:8080")],
max_retries=2,
)به ProxyConfig.DIRECT به عنوان اولین عنصر توجه کنید — این همان «ابتدا بدون پروکسی امتحان کن» است.
مرحله 2. اتصال پروکسی در هر ابزار
حالا — جزئیات تنظیم. ترتیب اقدامات یکسان است: ابتدا پروکسی، سپس حذف ترافیک اضافی، سپس بررسی.
- Firecrawl (خود میزبان). پروکسی با سه متغیر محیطی تعیین میشود که به Playwright منتقل میشوند:
PROXY_SERVER،PROXY_USERNAME،PROXY_PASSWORD. اینها در.envبرایapps/apiنوشته میشوند؛ در توضیحات آنها توسعهدهندگان به وضوح مینویسند که به جای آدرس ثابت میتوان پروکسی سرویسی را که IP را در هر درخواست چرخش میدهد، مشخص کرد. - Crawl4AI. پروکسی در
BrowserConfigزندگی میکند، در فیلدproxy_config— این یک شیءProxyConfigیا دیکشنری با فیلدهایserver،username،passwordاست. یک پیکربندی مرورگر برای کل جلسه خزیدن؛ یکCrawlerRunConfigجداگانه برای هر فراخوانیarun()منتقل میشود. - Crawlee. کلاس
ProxyConfigurationبا گزینهproxyUrls— لیستی از آدرسها که کتابخانه به صورت گردشی (round-robin) از آن عبور میکند. مقدارnullدر لیست به معنای «بدون پروکسی» است. ادغام سراسری:HttpCrawler،CheerioCrawler،JSDOMCrawler،PlaywrightCrawler،PuppeteerCrawler. - قوانین نقطهای. اگر میدانید کدام دامنهها مسدود میشوند و کدامها نمیشوند، در Crawlee یک
newUrlFunctionوجود دارد — منطق انتخاب پروکسی بر اساس URL درخواست. برای دامنههای سفیدnullبرمیگردانید، برای بقیه — آدرس پروکسی. این ارزانترین گزینه است، زمانی که لیست اهداف پایدار است. - بررسی. قبل از اجرای واقعی، صفحهای که IP خارجی شما را ارائه میدهد از طریق خزنده تنظیم شده عبور دهید و مطمئن شوید که آدرس پروکسی را میبینید، نه سرور. سه خط که یک روز را در بررسیها صرفهجویی میکند.
مرحله 3. قطع کردن هر چیزی که متن نمیشود
وقتی پروکسی متصل شد، صرفهجویی در ترافیک را فعال کنید — در غیر این صورت صورتحساب گیگابایتها سریعتر از آنکه مجموعه جمعآوری شود، میآید.
در Firecrawl این کار با متغیر BLOCK_MEDIA انجام میشود. در مثال رسمی پیکربندی، یک توضیح صریح به آن اضافه شده است: آن را تنظیم کنید اگر میخواهید درخواستهای رسانهای را مسدود کنید تا پهنای باند پروکسی را صرفهجویی کنید. این سریعترین راه برای حذف هزینه اصلی است.
در Crawl4AI اهرمهای مشابهی در BrowserConfig وجود دارند: text_mode تصاویر را غیرفعال میکند و خزیدن متنی را تسریع میکند، light_mode بخشی از عملکردهای پسزمینه مرورگر را غیرفعال میکند، avoid_css بارگذاری CSS را مسدود میکند. اینها را میتوان ترکیب کرد. برای جمعآوری مجموعه برای RAG، این تقریباً همیشه مجموعه درستی است — طراحی برای شما مهم نیست، متن مهم است.
در Crawlee منطق متفاوت است: اگر محتوا به صورت HTML ارائه میشود، از CheerioCrawler یا HttpCrawler به جای خزندههای مرورگری استفاده کنید. یک درخواست HTTP معمولی به جای رندر کامل — این نه تنها صرفهجویی در ترافیک است، بلکه نوع دیگری از هزینهها است. خزندههای مرورگر (PlaywrightCrawler، PuppeteerCrawler) را فقط برای صفحاتی که بدون JavaScript جمعآوری نمیشوند، نگه دارید.
دامهای پنهان
جلسات در مقابل چرخش. تغییر IP در هر درخواست به خودی خود مشکوک به نظر میرسد و سناریوهای چند مرحلهای را مختل میکند — صفحهبندی، انتقالها در داخل یک دامنه. در Crawlee هر فراخوانی newUrl() پروکسی را با شیء Session پیوند میدهد و آنها با هم با اثر انگشتهای مرورگر و هدرها چرخش میکنند. این پیوند را به صورت دستی قطع نکنید.
رسانه غیرفعال است، اما محتوا ناپدید شده است. برخی از سایتها با بارگذاری تنبل نه تنها تصاویر، بلکه متن را نیز بارگیری میکنند. پس از فعالسازی text_mode یا BLOCK_MEDIA حتماً یک نمونه کنترل از 20–30 صفحه را اجرا کنید و حجم متن را با استاندارد مقایسه کنید.
تلاشهای مجدد بدون سقف. افزایش سطح پروکسی به این معنی است که یک صفحه سرسخت ممکن است سه بار بارگیری شود — و هر سه بار هزینهاش پرداخت میشود. max_retries را محدود کنید و لیستی از دامنهها را ایجاد کنید که پس از N تلاش ناموفق از دور خارج میشوند.
Robots.txt و چارچوب قانونی. جمعآوری دادهها برای آموزش و RAG در سال 2026 سختتر از چند سال پیش تنظیم شده است — از الزامات افشای منابع تا مکانیزمهای انصراف از text and data mining. اطمینان حاصل کنید که خط لوله شما به این سیگنالها احترام میگذارد، قبل از اینکه بر روی صدها هزار صفحه کار کند.
چه نوع پروکسی برای خط لوله RAG بگیریم
پاسخ بستگی به این دارد که شما در کدام سطح افزایش هستید.
- سطح صفر — بدون پروکسی. مستندات، پروژههای متن باز، سایتهای دولتی، بیشتر وبلاگهای شرکتی. در اینجا IP سرور به خوبی کار میکند و نیازی به پرداخت نیست.
- سطح متوسط — پروکسی دیتاسنتر. سریع و ارزان، مناسب برای محدودیت نرخ ساده و محدودیتهای منطقهای. در جمعآوری مجموعههای بزرگ، این یک اسب کار است: وقتی حجم به صدها گیگابایت میرسد، تفاوت قیمت به ازای گیگابایت عامل اصلی میشود.
- سطح بالا — پروکسیهای مقیم. برای دامنههایی با حفاظت ضد ربات جدی، جایی که زیرشبکههای دیتاسنتر در ورودی جدا میشوند. به همین دلیل نمیتوان آنها را به عنوان سطح پیشفرض قرار داد — پرداخت به ازای گیگابایت هر تصویر اضافی را به یک خط هزینه تبدیل میکند.
قبل از ساخت خط لوله، بهتر است اقتصاد را به طور صادقانه محاسبه کنید: ما هزینه کامل پارس کردن یک میلیون صفحه را با در نظر گرفتن وزن صفحات، تلاشهای مجدد و هزینههای پنهان بررسی کردیم. و سوال جداگانهای که مفید است قبل از نوشتن اولین خط کد بپرسید: آیا اصلاً خزیدن لازم است — در بررسی API رسمی در مقابل مجموعههای داده آماده و پارس کردن مشخص است که برای برخی منابع، دادههای آماده ارزانتر از خزنده خودتان است.
نتیجهگیری
پروکسی در خزنده LLM یک کلید «روشن/خاموش» نیست، بلکه یک طرح سهسطحی است. درخواست مستقیم به عنوان سطح پیشفرض، پروکسی دیتاسنتر در سطح متوسط، و پروکسیهای مقیم — فقط برای دامنههایی که به غیر از این نمیتوانند بارگیری شوند. به علاوه قطع سخت رسانه، زیرا شما در حال جمعآوری متن هستید و برای بایتها هزینه میکنید.
ترتیب کارها ساده است: ابتدا کنترل کیفیت نتیجه (در غیر این صورت نمیدانید که نیمی از مجموعه — صفحات مسدودکننده است)، سپس افزایش پروکسی با استفاده از خود فریمورک، سپس صرفهجویی در ترافیک. به این ترتیب — هم مجموعه کامل خواهد شد و هم صورتحساب قابل پیشبینی.
```