نموذج "تشغيل 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 ليس مجرد مفتاح "تشغيل/إيقاف"، بل هو مخطط ثلاثي المستويات. الطلب المباشر كمستوى افتراضي، بروكسي مركز البيانات في المستوى المتوسط، والبروكسي السكنية - فقط للنطاقات التي لا يمكن الوصول إليها بطريقة أخرى. بالإضافة إلى قطع صارم للوسائط، لأنك تجمع النص، وتدفع مقابل البايتات.
ترتيب العمل بسيط: أولاً مراقبة جودة النتيجة (وإلا لن تعرف أن نصف المجموعة هي صفحات توقف)، ثم تصعيد البروكسي باستخدام أدوات الإطار نفسه، ثم توفير حركة المرور. بهذا الترتيب - ستحصل على مجموعة كاملة، وفاتورة متوقعة.
```