Firecrawl, Crawl4AI और Crawlee के लिए प्रॉक्सी: गाइड 2026

```html

स्कीमा "Firecrawl को Docker में चलाया, डोमेन की सूची पर लगाया, RAG के लिए markdown प्राप्त किया" पहले हजार पृष्ठों तक काम करती है। इसके बाद दो बिल आते हैं। पहला - एंटी-बॉट्स से: कुछ डोमेन सामग्री के बजाय 403 लौटाना शुरू कर देते हैं, और ज्ञान के आधार में छिद्र उत्पन्न होते हैं, जिनके बारे में आप तब जानते हैं जब सहायक "प्रदान किए गए सामग्रियों में कोई जानकारी नहीं है" का उत्तर देता है। दूसरा बिल - ट्रैफ़िक के लिए: क्रॉलर ईमानदारी से हर छवि और हर फ़ॉन्ट को खींचता है, जो अंततः markdown में नहीं आएगा।

आइए देखें कि 2026 के तीन सबसे लोकप्रिय LLM-क्रॉलर - Firecrawl, Crawl4AI और Crawlee - के साथ प्रॉक्सी को कैसे कनेक्ट करें और उन्हें इस तरह से सेट करें कि प्रॉक्सी केवल वहां काम करे जहां इसकी आवश्यकता है, न कि हर पृष्ठ पर गीगाबाइट्स जलाए।

यह गाइड किसके लिए है

यदि आप RAG के लिए दस्तावेजों का संग्रह कर रहे हैं, आंतरिक ज्ञान के आधार को भर रहे हैं, पुनः प्रशिक्षण के लिए डेटा पाइपलाइन बना रहे हैं या बस नियमित रूप से सैकड़ों डोमेन डाउनलोड कर रहे हैं - तो यह आपके लिए है। नीचे दिए गए तीन उपकरण डिफ़ॉल्ट कॉन्फ़िगरेशन में आपके सर्वर के आईपी के साथ चलते हैं और पृष्ठ को पूरी तरह से लोड करते हैं। इन दोनों डिफ़ॉल्ट सेटिंग्स को बदलना आवश्यक है।

समस्या के पैमाने को लोकप्रियता के आंकड़ों से समझा जा सकता है: Firecrawl के पास प्रकाशन के समय लगभग 170,000 सितारे GitHub पर (AGPL-3.0 लाइसेंस), Crawl4AI के पास लगभग 79,000, और Apify के Crawlee के पास लगभग 25,000 हैं। ये अब निचे के प्रयोग नहीं हैं, बल्कि मानक उपकरण हैं, और एंटी-बॉट सिस्टम उनके व्यवहार को आपसे बेहतर जानते हैं।

पहला बिल: सामग्री के बजाय 403

संग्रह के दौरान मुख्य गलती यह मानना है कि क्रॉलर सफलतापूर्वक काम कर रहा है यदि वह गिर नहीं गया। Firecrawl और Crawl4AI एक ब्लॉक किए गए पृष्ठ पर अपवाद नहीं लौटाते, बल्कि परिणाम लौटाते हैं: एंटी-बॉट का स्टॉप पृष्ठ, ब्राउज़र की जांच वाला पृष्ठ या पहुंच से इनकार करने वाला संक्षिप्त पाठ। औपचारिक रूप से यह एक मान्य markdown है, यह आसानी से वेक्टर डेटाबेस में जा सकता है और पहले उपयोगकर्ता के अनुरोध तक वहां रहता है।

इसलिए प्रॉक्सी की किसी भी सेटिंग से पहले, परिणाम की गुणवत्ता की जांच करना आवश्यक है। न्यूनतम विकल्प: कुछ सीमा से छोटे दस्तावेजों को छांटना (एक सामान्य सामग्री पृष्ठ के लिए 500-800 वर्णों का पाठ उचित है) और पाठ में विशिष्ट संकेतकों को अलग से पकड़ना - कनेक्शन की जांच, सक्रिय JavaScript, "Access denied" का उल्लेख। ऐसे दस्तावेज़ डेटाबेस में नहीं जाते, बल्कि पुनः स्कैन के लिए कतार में जाते हैं - पहले से ही प्रॉक्सी के माध्यम से।

दूसरा बिल: गीगाबाइट्स जो आप फेंक रहे हैं

यहां अंकगणित मदद करता है। HTTP Archive के Web Almanac के 2025 के आंकड़ों के अनुसार, औसत मुख्य पृष्ठ का वजन लगभग 2.86 MB डेस्कटॉप पर और 2.56 MB मोबाइल पर है। इनमें से छवियों का हिस्सा मुख्य पृष्ठों पर लगभग 1,059 KB और आंतरिक पृष्ठों पर 911 KB है, JavaScript पर - क्रमशः 697 KB और 632 KB। यानी छवियां सबसे भारी श्रेणी हैं, लगभग एक तिहाई पृष्ठ का वजन।

अब याद करें कि आप परिणाम के साथ क्या करते हैं। आप पृष्ठ को markdown में परिवर्तित करते हैं और एम्बेडिंग के लिए चंक्स में काटते हैं। छवियां इस पाइपलाइन में बिल्कुल नहीं आतीं - सबसे अच्छे मामले में उनके पास एक लाइन होती है जिसमें alt-टेक्स्ट होता है। वीडियो, फ़ॉन्ट, विश्लेषणात्मक स्क्रिप्ट, विज्ञापन पिक्सेल - भी बाहर।

यदि आप रेजिडेंशियल प्रॉक्सी के माध्यम से स्कैन चलाते हैं जिसमें गीगाबाइट के लिए भुगतान होता है, तो आप वास्तव में उन डेटा की डिलीवरी के लिए भुगतान कर रहे हैं जिन्हें आप अगले पाइपलाइन चरण में फेंक देते हैं। 100,000 पृष्ठों के संग्रह में "सब कुछ खींचना" और "केवल 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 में आया और वर्तमान शाखा में है (प्रकाशन के समय अंतिम रिलीज - 15 जुलाई 2026 को v0.9.2)। इसे प्रॉक्सी वृद्धि कहा जाता है और इसे 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 के साथ एक शब्दकोश है। एक ब्राउज़र कॉन्फ़िगरेशन पूरे क्रॉलिंग सत्र के लिए; प्रत्येक arun() कॉल पर एक अलग CrawlerRunConfig पास किया जाता है।
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 और कानूनी ढांचा। 2026 में प्रशिक्षण और RAG के लिए डेटा संग्रह पहले की तुलना में अधिक सख्त है - स्रोतों के प्रकटीकरण की आवश्यकताओं से लेकर टेक्स्ट और डेटा माइनिंग से इनकार करने के तंत्रों तक। सुनिश्चित करें कि आपकी पाइपलाइन इन संकेतों का सम्मान करती है, इससे पहले कि यह सौ हजार पृष्ठों पर काम करे।

RAG-पाइपलाइन के लिए किस प्रकार की प्रॉक्सी लेनी चाहिए

उत्तर इस बात पर निर्भर करता है कि आप किस स्तर की वृद्धि पर हैं।

शून्य स्तर - बिना प्रॉक्सी। दस्तावेज़ीकरण, ओपन-सोर्स प्रोजेक्ट, सरकारी साइटें, अधिकांश कॉर्पोरेट ब्लॉग। यहां सर्वर का IP ठीक से काम करता है, और भुगतान करने के लिए कुछ नहीं है।
मध्यम स्तर - डेटा सेंटर प्रॉक्सी. तेज और सस्ते, साधारण दर सीमित करने और क्षेत्रीय प्रतिबंधों के खिलाफ काम करते हैं। बड़े संग्रह के लिए यह एक कार्य घोड़ा है: जब मात्रा सैकड़ों गीगाबाइट में मापी जाती है, तो गीगाबाइट के लिए मूल्य का अंतर मुख्य कारक बन जाता है।
ऊपरी स्तर - रिज़िडेंशियल प्रॉक्सी. गंभीर एंटी-बॉट सुरक्षा वाले डोमेन के लिए, जहां डेटा सेंटर सबनेट्स प्रवेश पर छांट दिए जाते हैं। इसलिए इन्हें डिफ़ॉल्ट स्तर पर नहीं रखा जा सकता - गीगाबाइट के लिए भुगतान हर अतिरिक्त छवि को खर्च की एक पंक्ति में बदल देता है।

पाइपलाइन बनाने से पहले, अर्थशास्त्र को ईमानदारी से गिनना उचित है: हमने एक मिलियन पृष्ठों के पार्सिंग की कुल लागत का विश्लेषण किया है जिसमें पृष्ठों का वजन, रिट्राई और छिपी हुई लागतें शामिल हैं। और एक अलग प्रश्न, जो पहले कोड की पहली पंक्ति लिखने से पहले पूछना उपयोगी है: क्या स्कैन की वास्तव में आवश्यकता है - आधिकारिक API बनाम तैयार डेटासेट और पार्सिंग के विश्लेषण में यह स्पष्ट है कि कुछ स्रोतों के लिए तैयार डेटा अपने स्वयं के क्रॉलर की तुलना में सस्ता है।

निष्कर्ष

LLM-क्रॉलर में प्रॉक्सी एक "ऑन/ऑफ" स्विच नहीं है, बल्कि एक तीन-स्तरीय योजना है। डिफ़ॉल्ट स्तर के रूप में सीधा अनुरोध, मध्य स्तर पर डेटा सेंटर प्रॉक्सी, रेजिडेंशियल केवल उन डोमेन के लिए जो अन्यथा नहीं लिए जा सकते। साथ ही मीडिया को सख्ती से काटना, क्योंकि आप पाठ एकत्र कर रहे हैं, और बाइट्स के लिए भुगतान कर रहे हैं।

कार्य का क्रम सरल है: पहले परिणाम की गुणवत्ता की जांच (अन्यथा आप नहीं जानेंगे कि आधा संग्रह स्टॉप पृष्ठ है), फिर ढांचे के माध्यम से प्रॉक्सी की वृद्धि, फिर ट्रैफ़िक की बचत। इस क्रम में - और संग्रह पूरा होगा, और बिल पूर्वानुमानित होगा।