बड़े पैमाने पर वेब स्क्रैपिंग: सार्वजनिक प्रॉक्सी का उपयोग कब और क्यों करें

प्रॉक्सी रोटेशन एक सहारा है, समाधान नहीं। अधिकांश स्क्रैपिंग ऑपरेशन इसलिए विफल होते हैं क्योंकि वे आईपी पतों को एकमात्र संकेत मानते हैं जिसे एंटी-बॉट सिस्टम मापते हैं। वास्तविकता यह है कि आधुनिक बॉट मैनेजर — Akamai Bot Manager, Cloudflare Turnstile, Datadome — आपके स्रोत आईपी से कहीं अधिक फिंगरप्रिंट करते हैं। मुफ्त सार्वजनिक प्रॉक्सी का एक घूमने वाला पूल उन सिस्टमों के खिलाफ आपको लगभग कुछ नहीं देता, और अक्सर स्थिति को और खराब कर देता है।

आईपी रोटेशन का भ्रम

जब आप हर अनुरोध पर आईपी बदलते हैं, तो आप स्वयं को एक स्क्रैपर घोषित करते हैं। मानव ब्राउज़िंग पैटर्न स्टिकी सेशन दिखाते हैं — मिनटों या घंटों के लिए एक ही आईपी, सुसंगत ब्राउज़र फिंगरप्रिंट, और पूर्वानुमानित अनुरोध अंतराल। requests जैसे उपकरण, Session ऑब्जेक्ट और एक घूमने वाली प्रॉक्सी सूची के साथ, उन सभी संकेतों को तोड़ देते हैं। Akamai का X-Akamai-Device-Fingerprint हेडर और Cloudflare का cf-request-id सहसंबंध विभिन्न आईपी से अनुरोधों को जोड़ सकता है जब TLS पैरामीटर, HTTP/2 सेटिंग्स और टाइमिंग समान रहते हैं। Datadome का JavaScript चैलेंज हेडलेस ब्राउज़र आर्टिफैक्ट्स की जाँच करता है जो प्रॉक्सी बदलने पर भी बने रहते हैं। पूरे क्लाइंट फिंगरप्रिंट को बदले बिना आईपी घुमाना आपकी लाइसेंस प्लेट बदलने जैसा है लेकिन उसी कार को चलाना — टोल कैमरे अभी भी आपको फ्लैग करेंगे।

कम दर, कम मात्रा वाली स्क्रैपिंग के लिए जो केवल बुनियादी आईपी-आधारित रेट लिमिटिंग (जैसे, बिना JavaScript चैलेंज के 10 अनुरोध प्रति मिनट की थ्रॉटल) का उपयोग करने वाली साइटों के खिलाफ हो, एक एकल रेजिडेंशियल आईपी अक्सर पर्याप्त होता है। मैंने वर्षों तक सरकारी डेटा पोर्टल्स और सार्वजनिक API के खिलाफ एक स्थिर आईपी और एक विनम्र time.sleep(2) का उपयोग करके स्क्रैपर चलाए हैं। किसी प्रॉक्सी की आवश्यकता नहीं। नियम सरल है: यदि साइट 50 अनुरोधों के बाद कोई चैलेंज पेज या CAPTCHA नहीं देती, तो आपको रोटेशन की आवश्यकता नहीं है।

आईपी पते से परे: फिंगरप्रिंटिंग

एंटी-बॉट सिस्टम अब प्रति अनुरोध दर्जनों संकेत एकत्र करते हैं। User-Agent स्ट्रिंग को नकली बनाना आसान है, लेकिन Accept-Language, Sec-CH-UA, Connection, और Accept-Encoding क्रम ऐसा नहीं है। अधिक महत्वपूर्ण रूप से, TLS फिंगरप्रिंटिंग — JA3 हैश में मानकीकृत (देखें JA3) — सिफर सूट क्रम और TLS एक्सटेंशन सूची द्वारा क्लाइंट लाइब्रेरी की पहचान करता है। Python की requests लाइब्रेरी (urllib3 के माध्यम से) एक JA3 हैश उत्पन्न करती है जो Chrome 124 से भिन्न है। Cloudflare का Turnstile और Datadome दोनों JA3 की जाँच करते हैं। एक ही TLS स्टैक को बनाए रखते हुए आईपी घुमाने से हर अनुरोध उसी स्वचालित क्लाइंट की तरह दिखता है, बस एक्ज़िट नोड्स के बीच कूदता हुआ। मुफ्त प्रॉक्सी इसे और बढ़ा देते हैं क्योंकि वे अक्सर पुराने OpenSSL संस्करण चलाते हैं या बॉट-जैसे TLS कॉन्फ़िगरेशन का उपयोग करते हैं जो पहले से ब्लैकलिस्टेड हैं।

HTTP/2 फिंगरप्रिंटिंग और आगे जाती है। SETTINGS फ्रेम, विंडो अपडेट वैल्यू, और स्ट्रीम कंकरेंसी पैरामीटर एक अद्वितीय "HTTP/2 फिंगरप्रिंट" बनाते हैं जिसे Akamai का Bot Manager सेशन में ट्रैक करता है। एक घूमने वाला प्रॉक्सी पूल जो HTTP/2 इम्प्लीमेंटेशन को भी नहीं घुमाता, उसे क्लस्टर करना आसान है। इन जाँचों से बचने का एकमात्र तरीका एक वास्तविक ब्राउज़र इंजन (Puppeteer, Playwright) या सावधानीपूर्वक तैयार किया गया TLS/HTTP स्टैक का उपयोग करना है जो किसी विशिष्ट ब्राउज़र संस्करण की नकल करता है — और तब भी, आपको किसी दिए गए सेशन से अनुरोधों में समान फिंगरप्रिंट बनाए रखना होगा।

मुफ्त सार्वजनिक प्रॉक्सी पूल का अर्थशास्त्र

मेरे परीक्षण में मुफ्त सार्वजनिक प्रॉक्सी सूचियों की विफलता दर 60–80 प्रतिशत है। अधिकांश प्रॉक्सी या तो आते ही मृत होते हैं, होस्ट द्वारा थ्रॉटल किए जाते हैं, या प्रमुख बॉट मैनेजरों द्वारा पहले से फ्लैग किए जाते हैं। सार्वजनिक निर्देशिका से स्क्रैप किए गए मुफ्त SOCKS5 प्रॉक्सी का औसत जीवनकाल 15 मिनट से कम है। 500 प्रॉक्सी का एक घूमने वाला पूल बनाए रखने का मतलब है कि आप प्रति घंटे हजारों आईपी जलाते हैं, और आपके 80% अनुरोध या तो टाइम आउट होते हैं या 403 लौटाते हैं। बैंडविड्थ अविश्वसनीय है, लेटेंसी स्पाइक्स आम हैं, और कई मुफ्त प्रॉक्सी विज्ञापन इंजेक्ट करते हैं या प्रतिक्रिया निकायों को संशोधित करते हैं। भुगतान वाले रेजिडेंशियल प्रॉक्सी नेटवर्क (जैसे, Bright Data, Oxylabs) 95%+ सफलता दर और स्टिकी सेशन विकल्प प्रदान करते हैं, लेकिन $10–$20 प्रति GB की लागत पर। पैमाने के लिए, गणित रेजिडेंशियल प्रॉक्सी का पक्ष तभी लेता है जब आपको उच्च-मूल्य वाले लक्ष्यों पर आईपी-आधारित ब्लॉक को बायपास करने की आवश्यकता हो। बाकी सबके लिए, उचित अनुरोध पेसिंग वाला एक साफ आईपी एक अराजक मुफ्त पूल से बेहतर प्रदर्शन करता है।

जब रोटेशन वास्तव में काम करता है

प्रॉक्सी रोटेशन एक विशिष्ट खतरे के खिलाफ प्रभावी है: आईपी-आधारित दर सीमाएं जो प्रति आईपी रीसेट होती हैं। यदि कोई साइट एक सरल X-Forwarded-For जाँच या प्रति आईपी टोकन बकेट का उपयोग करती है, तो प्रत्येक अनुरोध के बाद घूमने से सीमा को बायपास किया जा सकता है। यह छोटी ई-कॉमर्स साइटों और लीगेसी API पर आम है जिन्होंने कभी अपनी बॉट डिटेक्शन को अपडेट नहीं किया। ऐसे मामलों में, एक मुफ्त प्रॉक्सी पूल भी काम करता है — लेकिन केवल तभी जब आप रीट्री लॉजिक लागू करते हैं जो विफल प्रॉक्सी को त्याग देता है और जल्दी से नए प्रॉक्सी के माध्यम से चक्र करता है।

यहाँ requests और रीट्री-विथ-रोटेशन लूप का उपयोग करते हुए एक न्यूनतम Python उदाहरण है। यह proxy_list में प्रॉक्सी URL की एक सूची और एक लक्ष्य url मानता है:

import requests
from itertools import cycle

proxy_pool = cycle(proxy_list)
max_retries = 5

for attempt in range(max_retries):
    proxy = next(proxy_pool)
    try:
        resp = requests.get(
            url,
            proxies={"http": proxy, "https": proxy},
            timeout=10,
            headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..."}
        )
        if resp.status_code == 200:
            break
    except (requests.ConnectionError, requests.Timeout):
        continue
else:
    raise RuntimeError("All proxies failed")

यह पैटर्न तभी काम करता है जब साइट की डिटेक्शन पूरी तरह से आईपी-आधारित हो। मानव टाइमिंग की नकल करने के लिए अनुरोधों के बीच एक time.sleep(random.uniform(1,3)) जोड़ें। Turnstile या Datadome चलाने वाली साइटों के लिए, यह कोड हर बार विफल होगा — चैलेंज पेज प्रॉक्सी की परवाह किए बिना 403 या CAPTCHA लौटाएगा। ऐसे मामलों में, आपको एक वास्तविक फिंगरप्रिंट वाले हेडलेस ब्राउज़र की आवश्यकता है, न कि घूमने वाली आईपी सूची की।

स्टिकी सेशन — संबंधित अनुरोधों के एक सेट के लिए एक ही आईपी रखना — अक्सर प्रति-अनुरोध रोटेशन से अधिक प्रभावी होते हैं। कई ई-कॉमर्स साइटें ब्राउज़िंग सेशन (जैसे, कार्ट में आइटम जोड़ना, चेकआउट करना) के लिए एक ही आईपी की अपेक्षा करती हैं। सेशन के बीच में घूमने से धोखाधड़ी के फ्लैग ट्रिगर होते हैं। प्रॉक्सी के एक पूल का उपयोग करें लेकिन प्रति अनुरोध के बजाय प्रति सेशन एक आईपी असाइन करें। मुफ्त प्रॉक्सी शायद ही कभी स्टिकी सेशन का समर्थन करते हैं क्योंकि एक ही आईपी कई उपयोगकर्ताओं द्वारा पुन: उपयोग किया जाता है; आप सेशन डेटा क्रॉस-संदूषण देखेंगे। भुगतान वाले रेजिडेंशियल प्रॉक्सी स्टिकी सेशन अवधि (5–30 मिनट) प्रदान करते हैं जो प्राकृतिक ब्राउज़िंग व्यवहार के अनुरूप होती है।

रोटेशन तभी चुनें जब आप लक्ष्य के डिटेक्शन स्टैक को समझते हों। पहले एक ही आईपी के साथ परीक्षण करें। रोटेशन तभी जोड़ें जब आप दर सीमा से टकराएं। और प्रोडक्शन के लिए कभी भी मुफ्त प्रॉक्सी पर निर्भर न हों — उनकी विफलता दर आपको इंजीनियरिंग समय और खोए हुए डेटा में एक सस्ती रेजिडेंशियल योजना से अधिक खर्च कराएगी।