Crawl4AI और Firecrawl के लिए प्रॉक्सी सेटअप: बिना ब्लॉक हुए RAG इंजेस्ट (2026)

Crawl4AI और Firecrawl LLM पाइपलाइनों में वेब डेटा फ़ीड करने का डिफ़ॉल्ट तरीका बन गए हैं — वे क्रॉल करते हैं, रेंडर करते हैं, और साफ़ Markdown वापस सौंपते हैं जिसे आपका मॉडल वास्तव में इस्तेमाल कर सके। फिर आप उन्हें एक असली target पर इंगित करते हैं और वही खोजते हैं जो हर स्क्रेपर आख़िरकार सीखता है: एक्सट्रैक्शन लेयर कभी मुश्किल हिस्सा नहीं था। मुश्किल हिस्सा यह है कि आपका क्रॉलर एक डेटासेंटर IP से चलता है, और वेब इसे देख सकता है।

यह गाइड दोनों टूल्स के लिए काम करने वाला प्रॉक्सी कॉन्फ़िगरेशन दिखाती है — self-hosted Crawl4AI और दोनों Firecrawl मोड — साथ ही वह session रणनीति जो RAG ingestion जॉब को पेज 50 पर मरने से रोकती है। यह हमारी AI एजेंट प्रॉक्सी गाइड और browser-use गाइड को क्रॉलिंग फ़्रेमवर्क तक विस्तारित करती है।

LLM क्रॉलर स्क्रेपर से ज़्यादा तेज़ी से ब्लॉक क्यों होते हैं

• वे व्यापक रूप से फ़ेच करते हैं, शल्यचिकित्सक की तरह नहीं। एक RAG ingestion जॉब मिनटों में एक पूरे डोमेन में सैकड़ों पेज खींचता है — ठीक वही वेग पैटर्न जिसे IP प्रतिष्ठा सिस्टम सबसे कठोरता से स्कोर करते हैं (देखें ASN डिटेक्शन समझाया गया)।
• वे डिफ़ॉल्ट रूप से headless Chromium चलाते हैं। Crawl4AI अंदरूनी तौर पर Playwright का उपयोग करता है; फ़्लैग के बिना, यह मानक headless आर्टिफ़ैक्ट दिखाता है।
• वे बेवक़ूफ़ी से retry करते हैं। एक एंटी-बॉट दीवार के विरुद्ध डिफ़ॉल्ट retry-on-failure बस IP की प्रतिष्ठा को और गहरा जला देता है।

Crawl4AI: प्रॉक्सी कॉन्फ़िगरेशन

Crawl4AI (ओपन-सोर्स, self-hosted) प्रॉक्सी को 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])

गहरे क्रॉल के लिए, प्रति क्रॉलर इंस्टेंस पहचान रोटेट करें, प्रति पेज नहीं — एक साइट विज़िट के भीतर के पेज एक exit IP साझा करने चाहिए (एक इंसान पेज 3 और पेज 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: दो मोड, दो उत्तर

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 क्रेडिट के एक गुणक पर बिल होते हैं, और आप देशों को सटीक रूप से पिन नहीं कर सकते या कॉल के बीच sticky sessions नहीं पकड़ सकते। कभी-कभार के पेजों के लिए ठीक; ingestion मात्रा पर महँगा और अनिश्चित।

Self-hosted Firecrawl: आप environment variables के ज़रिए अपना स्वयं का प्रॉक्सी आपूर्ति करते हैं, पूर्ण नियंत्रण के साथ:

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

Self-hosted + आपका अपना रेज़िडेंशियल गेटवे एक बार जब आप पैमाने पर ingest कर रहे हों तो लागत-तर्कसंगत सेटअप है: आप प्रति-पेज क्रेडिट के बजाय बैंडविड्थ के लिए प्रति-GB भुगतान करते हैं।

RAG Ingestion जॉब के लिए Session रणनीति

• एक साइट = एक sticky पहचान। Cookies, cache, और exit IP पूरे साइट क्रॉल के लिए संगत रहते हैं; साइटों के बीच रोटेट करें। (पृष्ठभूमि: sticky बनाम रोटेटिंग।)
• प्रति-साइट गति का सम्मान करें। Crawl4AI के semaphore_count / विलंब विकल्प इसी के लिए मौजूद हैं — प्रति साइट 2–4 समवर्ती पेज पर्याप्त हैं; इसके बजाय साइटों में समानांतरता फैलाएँ।
• पेज को विफल करें, जॉब को नहीं। एक 403/challenge पर, URL को चिह्नित करें, पहचान रोटेट करें, और जारी रखें — उसी exit से अंधे retries उसके स्कोर को ज़हरीला कर देते हैं।
• Markdown को सत्यापित करें। एक एंटी-बॉट interstitial Markdown में बिल्कुल ठीक बदल जाता है — आपके vector DB में embedded "Verifying you are human" एक असली विफलता मोड है। indexing से पहले ingestion आउटपुट में challenge-पेज मार्कर के लिए grep करें।
• आक्रामक रूप से cache करें। अपरिवर्तित पेजों को फिर से क्रॉल करना व्यर्थ में बैंडविड्थ और प्रतिष्ठा जलाता है — जहाँ फ़्रेमवर्क अनुमति दे वहाँ ETag/Last-Modified का सम्मान करें।

लागत वास्तविकता जाँच

सेटअप	आप किसके लिए भुगतान करते हैं	सबसे अच्छा जब
Firecrawl cloud, stealth प्रॉक्सी	प्रति-पेज क्रेडिट × stealth गुणक	कम मात्रा, शून्य ops
Self-hosted Firecrawl + रेज़िडेंशियल GB	केवल बैंडविड्थ (~$10/GB)	स्थिर ingestion मात्रा
Crawl4AI + रेज़िडेंशियल GB	केवल बैंडविड्थ, पूर्ण नियंत्रण	कस्टम पाइपलाइन, गहरे क्रॉल

एक सामान्य टेक्स्ट-भारी पेज प्रॉक्सी के ज़रिए 100–300 KB लागत आता है — मोटे तौर पर प्रति GB 3,000–10,000 पेज। Block-and-retry लूप ही बजट उड़ाते हैं, जो मात्रा बढ़ाने से पहले डिटेक्शन ठीक करने का एक और कारण है।

सारांश

• LLM क्रॉलर का ब्लॉक होना = IP + headless डिटेक्शन, फ़्रेमवर्क नहीं; पहले नेटवर्क लेयर ठीक करें।
• Crawl4AI: BrowserConfig में proxy_config; प्रति साइट sticky पहचान, साइटों के बीच रोटेट करें।
• Firecrawl cloud: proxy: "stealth" पैरामीटर, मात्रा पर महँगा; self-hosted: env vars के ज़रिए आपका अपना गेटवे।
• Markdown आउटपुट को आपके vector DB तक पहुँचने से पहले challenge-पेज टेक्स्ट के लिए सत्यापित करें।
• एक बार ingestion स्थिर हो जाने पर प्रति-GB रेज़िडेंशियल प्रति-पेज stealth क्रेडिट को मात देता है।