वेब स्क्रैपिंग के दौरान बैन दर को 5% तक कैसे कम करें: 12 सिद्ध सुरक्षा विधियाँ

यदि आप मार्केटप्लेस की पार्सिंग, प्रतिस्पर्धियों की कीमतों की निगरानी या वेबसाइटों से डेटा संग्रह करते हैं, तो आप समस्या जानते हैं: वेबसाइटें IP पते ब्लॉक करती हैं, कैप्चा मांगती हैं या खाली पेज लौटाती हैं। Ban rate (ब्लॉक किए गए अनुरोधों का प्रतिशत) 70-90% तक पहुंच सकता है, जो पार्सिंग को असंभव बना देता है। इस लेख में हम विशिष्ट विधियों का विश्लेषण करेंगे जो ban rate को 5-10% तक कम करने और स्थिर रूप से डेटा एकत्र करने में मदद करेंगी।

हम तकनीकी समाधानों (प्रॉक्सी रोटेशन, HTTP हेडर, fingerprinting) और व्यवहारिक पैटर्न (विलंब, उपयोगकर्ता क्रियाओं की नकल) दोनों पर विचार करेंगे। सभी विधियां Wildberries, Ozon, Avito और विदेशी प्लेटफॉर्म की पार्सिंग में व्यावहारिक रूप से परीक्षित हैं।

वेबसाइटें पार्सर को क्यों ब्लॉक करती हैं: मुख्य ट्रिगर

सुरक्षा विधियों का विश्लेषण करने से पहले, यह समझना महत्वपूर्ण है कि वेबसाइटें स्वचालित ट्रैफ़िक को कैसे पहचानती हैं। आधुनिक एंटी-बॉट सिस्टम (Cloudflare, Akamai, DataDome, Imperva) प्रत्येक अनुरोध के दर्जनों पैरामीटर का विश्लेषण करते हैं। यहां मुख्य ब्लॉकिंग ट्रिगर हैं:

उदाहरण के लिए, Wildberries की पार्सिंग करते समय विशिष्ट गलती — एक IP से हर 0.5 सेकंड में अनुरोध भेजना। Cloudflare एंटी-बॉट सिस्टम तुरंत पैटर्न की पहचान करेगा और IP को 24 घंटे के लिए ब्लॉक कर देगा। वास्तविक उपयोगकर्ता उत्पाद कार्ड देखने में 5-15 सेकंड बिताता है, पृष्ठ स्क्रॉल करता है, छवियों पर क्लिक करता है।

प्रॉक्सी रोटेशन: IP पते सही तरीके से कैसे बदलें

प्रॉक्सी का उपयोग ban rate कम करने की बुनियादी विधि है। लेकिन केवल प्रॉक्सी खरीदना ही नहीं, बल्कि रोटेशन को सही तरीके से कॉन्फ़िगर करना महत्वपूर्ण है। यहां सिद्ध रणनीतियां हैं:

पार्सिंग के लिए प्रॉक्सी प्रकार का चयन

मार्केटप्लेस (Wildberries, Ozon, Avito) की पार्सिंग के लिए रेजिडेंशियल प्रॉक्सी की सिफारिश की जाती है — उनके पास वास्तविक घरेलू उपयोगकर्ताओं के IP होते हैं, जिन्हें सामान्य ट्रैफ़िक से अलग करना मुश्किल है। डेटासेंटर प्रॉक्सी कम सुरक्षित साइटों के लिए या जब बड़ी मात्रा में डेटा के साथ अधिकतम गति की आवश्यकता हो, उपयुक्त होंगे।

IP पतों के रोटेशन की रणनीतियां

प्रॉक्सी पूल का आकार

पूल का न्यूनतम आकार पार्सिंग की तीव्रता पर निर्भर करता है:

• निम्न तीव्रता (प्रति दिन 10,000 अनुरोध तक): 10-20 प्रॉक्सी
• मध्यम तीव्रता (प्रति दिन 10,000 - 100,000 अनुरोध): 50-100 प्रॉक्सी
• उच्च तीव्रता (प्रति दिन 100,000 से अधिक अनुरोध): 200+ प्रॉक्सी या स्वचालित रोटेशन के साथ रेजिडेंशियल

प्रत्येक अनुरोध पर रोटेशन के साथ रेजिडेंशियल प्रॉक्सी (rotating proxies) के लिए पूल का आकार छोटा हो सकता है, क्योंकि प्रदाता स्वचालित रूप से लाखों पतों के अपने पूल से नया IP प्रतिस्थापित करता है।

User-Agent और HTTP हेडर: वास्तविक ब्राउज़र की नकल

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

सही User-Agent

सभी अनुरोधों के लिए एक ही User-Agent का उपयोग न करें। लोकप्रिय ब्राउज़रों की एक सूची बनाएं और उसमें से यादृच्छिक रूप से चुनें:

user_agents = [
    # Windows पर Chrome
    "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
    # macOS पर Chrome
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
    # Windows पर Firefox
    "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0",
    # macOS पर Safari
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.1 Safari/605.1.15",
    # Windows पर Edge
    "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 Edg/120.0.0.0"
]

HTTP हेडर का पूरा सेट

आधुनिक ब्राउज़र 15-20 हेडर भेजते हैं। Chrome की नकल के लिए न्यूनतम आवश्यक सेट यहां है:

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0.0.0",
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
    "Accept-Language": "ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7",
    "Accept-Encoding": "gzip, deflate, br",
    "DNT": "1",
    "Connection": "keep-alive",
    "Upgrade-Insecure-Requests": "1",
    "Sec-Fetch-Dest": "document",
    "Sec-Fetch-Mode": "navigate",
    "Sec-Fetch-Site": "none",
    "Sec-Fetch-User": "?1",
    "Cache-Control": "max-age=0",
    "sec-ch-ua": '"Not_A Brand";v="8", "Chromium";v="120", "Google Chrome";v="120"',
    "sec-ch-ua-mobile": "?0",
    "sec-ch-ua-platform": '"Windows"'
}

Sec-Fetch-* और sec-ch-ua-* हेडर पर ध्यान दें — वे Chrome के नए संस्करणों में दिखाई दिए और उनकी अनुपस्थिति स्वचालन को उजागर कर सकती है।

हेडर का क्रम महत्वपूर्ण है

ब्राउज़र एक निश्चित क्रम में हेडर भेजते हैं। उदाहरण के लिए, Chrome हमेशा Host को पहले रखता है, फिर Connection, User-Agent और इसी तरह। यदि आप Python लाइब्रेरी requests का उपयोग करते हैं, तो क्रम वर्णानुक्रमिक हो सकता है, जो स्वचालन को उजागर करेगा।

समाधान: ऐसी लाइब्रेरी का उपयोग करें जो सही तरीके से हेडर बनाती हैं (Python के लिए curl_cffi, Node.js के लिए got) या headless ब्राउज़र (Puppeteer, Playwright, Selenium), जो वास्तविक ब्राउज़र की तरह हेडर उत्पन्न करते हैं।

अनुरोधों के बीच विलंब: इष्टतम अंतराल

Ban rate कम करने के सबसे सरल लेकिन प्रभावी तरीकों में से एक — अनुरोधों के बीच सही विलंब। वास्तविक उपयोगकर्ता प्रति सेकंड 10 पृष्ठ नहीं खोल सकता, इसलिए बहुत तेज़ अनुरोध तुरंत ब्लॉकिंग का कारण बनते हैं।

निश्चित के बजाय यादृच्छिक विलंब

निश्चित विलंब का उपयोग न करें (उदाहरण के लिए, अनुरोधों के बीच बिल्कुल 2 सेकंड)। एंटी-बॉट सिस्टम आसानी से ऐसे पैटर्न की पहचान करते हैं। यादृच्छिक अंतराल का उपयोग करें:

import random
import time

# निश्चित विलंब के बजाय
time.sleep(2)  # ❌ खराब

# यादृच्छिक अंतराल का उपयोग करें
delay = random.uniform(2.5, 5.5)  # ✅ अच्छा
time.sleep(delay)

विभिन्न साइटों के लिए अनुशंसित अंतराल

सर्वर प्रतिक्रियाओं के आधार पर अनुकूली विलंब

उन्नत दृष्टिकोण — सर्वर प्रतिक्रियाओं के आधार पर विलंब को गतिशील रूप से बदलना:

base_delay = 3.0  # आधार विलंब
delay_multiplier = 1.0

response = requests.get(url, headers=headers, proxies=proxies)

# यदि कैप्चा या 429 मिला — विलंब बढ़ाएं
if response.status_code == 429 or 'captcha' in response.text.lower():
    delay_multiplier *= 1.5
    print(f"सुरक्षा का पता चला, विलंब बढ़ाकर {base_delay * delay_multiplier}s")

# यदि सब कुछ ठीक है — थोड़ा तेज़ कर सकते हैं
elif response.status_code == 200:
    delay_multiplier = max(1.0, delay_multiplier * 0.95)

time.sleep(random.uniform(base_delay * delay_multiplier, base_delay * delay_multiplier * 1.5))

यह दृष्टिकोण सुरक्षा का पता लगने पर स्वचालित रूप से धीमा होने और जब साइट आक्रामकता नहीं दिखाती तो तेज़ होने की अनुमति देता है।

Fingerprinting से सुरक्षा: Canvas, WebGL, फ़ॉन्ट

यदि साइट सत्यापन के लिए JavaScript का उपयोग करती है, तो साधारण HTTP हेडर पर्याप्त नहीं हैं। आधुनिक एंटी-बॉट सिस्टम दर्जनों पैरामीटर के आधार पर ब्राउज़र का "फ़िंगरप्रिंट" बनाते हैं: Canvas, WebGL, इंस्टॉल किए गए फ़ॉन्ट, समय क्षेत्र, स्क्रीन रिज़ॉल्यूशन और अन्य।

Fingerprinting के मुख्य पैरामीटर

Fingerprinting को बायपास करने के लिए टूल

Fingerprinting को बायपास करने के लिए विशेष टूल का उपयोग करें:

• Undetected ChromeDriver (Python) — Selenium का संशोधित संस्करण जो स्वचालन के संकेतों को छुपाता है
• Puppeteer Stealth (Node.js) — Puppeteer के लिए प्लगइन, fingerprint पैरामीटर को प्रतिस्थापित करता है
• Playwright with stealth — Puppeteer के समान, लेकिन विभिन्न ब्राउज़रों के बेहतर समर्थन के साथ
• एंटी-डिटेक्ट ब्राउज़र (Dolphin Anty, AdsPower, Multilogin) — उन लोगों के लिए जो कोड नहीं लिखना चाहते, ये ब्राउज़र स्वचालित रूप से fingerprint को प्रतिस्थापित करते हैं

Python में undetected-chromedriver का उपयोग करने का उदाहरण:

import undetected_chromedriver as uc

# डिटेक्शन से सुरक्षा के साथ ब्राउज़र बनाएं
options = uc.ChromeOptions()
options.add_argument('--disable-blink-features=AutomationControlled')

driver = uc.Chrome(options=options)
driver.get('https://example.com')

# जांचें कि navigator.webdriver === undefined
webdriver_status = driver.execute_script("return navigator.webdriver")
print(f"navigator.webdriver: {webdriver_status}")  # None/undefined होना चाहिए

Cookies और सत्रों का प्रबंधन

कई साइटें उपयोगकर्ता व्यवहार को ट्रैक करने के लिए cookies का उपयोग करती हैं। Cookies का सही प्रबंधन ब्लॉकिंग से बचने और वास्तविक उपयोगकर्ता की तरह दिखने में मदद करता है।

Cookies को सहेजना और पुन: उपयोग करना

प्रत्येक अनुरोध पर नया सत्र बनाने के बजाय, cookies को सहेजें और उन्हें फिर से उपयोग करें। यह वास्तविक उपयोगकर्ता के व्यवहार की नकल करता है जो साइट पर वापस आता है:

import requests
import pickle

session = requests.Session()

# पहली विज़िट — cookies प्राप्त करें
response = session.get('https://example.com')

# Cookies को फ़ाइल में सहेजें
with open('cookies.pkl', 'wb') as f:
    pickle.dump(session.cookies, f)

# बाद में cookies लोड करें
with open('cookies.pkl', 'rb') as f:
    session.cookies.update(pickle.load(f))

# अब अनुरोध लौटे हुए उपयोगकर्ता से दिखते हैं
response = session.get('https://example.com/catalog')

पार्सिंग से पहले सत्र को गर्म करना

लक्ष्य पृष्ठों से तुरंत पार्सिंग शुरू न करें। वास्तविक उपयोगकर्ता के व्यवहार की नकल करें:

1. साइट का मुख्य पृष्ठ खोलें
2. 2-5 सेकंड प्रतीक्षा करें
3. श्रेणी या अनुभाग पृष्ठ खोलें
4. 3-7 सेकंड प्रतीक्षा करें
5. उसके बाद ही लक्ष्य पृष्ठों को पार्स करना शुरू करें

यह cookies में गतिविधि का इतिहास बनाता है और ब्लॉकिंग की संभावना को कम करता है।

Session cookies और टोकन को संभालना

कुछ साइटें पहली विज़िट पर अद्वितीय टोकन उत्पन्न करती हैं और बाद के अनुरोधों में उनकी जांच करती हैं। उदाहरण के लिए, Wildberries x-requested-with हेडर में टोकन का उपयोग करता है। हमेशा पहली प्रतिक्रिया से ऐसे टोकन सहेजें और उन्हें बाद के अनुरोधों में भेजें।

JavaScript रेंडरिंग: कब आवश्यक है

कई आधुनिक साइटें JavaScript के माध्यम से सामग्री लोड करती हैं। यदि आप साधारण HTTP क्लाइंट (Python में requests, Node.js में axios) का उपयोग करते हैं, तो आपको खाली पृष्ठ या स्टब मिलेगा। ऐसे मामलों में JavaScript रेंडरिंग आवश्यक है।

JavaScript रेंडरिंग कब आवश्यक है

• साइट React, Vue, Angular का उपयोग करती है — सामग्री प्रारंभिक पृष्ठ लोड के बाद लोड होती है
• डेटा AJAX/Fetch अनुरोधों के माध्यम से लोड किया जाता है
• साइट को टोकन या cookies उत्पन्न करने के लिए JavaScript निष्पादन की आवश्यकता है
• बॉट से सुरक्षा मौजूद है जिसके लिए JS कोड निष्पादन की आवश्यकता है (उदाहरण के लिए, Cloudflare Challenge)

JavaScript रेंडरिंग के लिए टूल

अधिकांश कार्यों के लिए Playwright की सिफारिश की जाती है — यह Selenium से तेज़ है, सुरक्षा को बेहतर तरीके से बायपास करता है और अधिक सुविधाजनक API है।

विकल्प: API अनुरोधों को इंटरसेप्ट करना

अक्सर JavaScript रेंडरिंग से बचा जा सकता है यदि आप API अनुरोधों को ढूंढ लें जो साइट डेटा लोड करने के लिए उपयोग करती है। DevTools (F12) → Network टैब → XHR/Fetch फ़िल्टर खोलें और देखें कि साइट कौन से अनुरोध भेजती है। फिर HTTP क्लाइंट के माध्यम से सीधे इन अनुरोधों को दोहराएं।

उदाहरण: Wildberries API https://catalog.wb.ru/catalog/... के माध्यम से उत्पाद डेटा लोड करता है। पूरे पृष्ठ को रेंडर करने के बजाय, आप सीधे इस API का अनुरोध कर सकते हैं, जो 10-20 गुना तेज़ है।

कैप्चा बायपास: स्वचालित समाधान

सही प्रॉक्सी और हेडर के साथ भी आप कैप्चा का सामना कर सकते हैं। इसे हल करने के लिए कई दृष्टिकोण हैं:

कैप्चा के प्रकार और समाधान विधियां

कैप्चा पहचान सेवा का एकीकरण

Python में 2Captcha एकीकरण का उदाहरण:

from twocaptcha import TwoCaptcha

solver = TwoCaptcha('YOUR_API_KEY')

try:
    # reCAPTCHA v2 हल करें
    result = solver.recaptcha(
        sitekey='6Le-wvkSAAAAAPBMRTvw0Q4Muexq9bi0DJwx_mJ-',
        url='https://example.com'
    )
    
    # समाधान टोकन प्राप्त करें
    captcha_token = result['code']
    
    # टोकन के साथ फॉर्म सबमिट करें
    response = requests.post('https://example.com/submit', data={
        'g-recaptcha-response': captcha_token
    })
    
except Exception as e:
    print(f"कैप्चा समाधान त्रुटि: {e}")

Rate limiting: साइट की सीमा कैसे न पार करें

कई साइटों में अनुरोधों की संख्या पर स्पष्ट या निहित सीमाएं होती हैं। इन सीमाओं को पार करने से IP का अस्थायी या स्थायी ब्लॉक होता है।

साइट की सीमाओं का निर्धारण

सर्वर प्रतिक्रियाओं में HTTP हेडर पर ध्यान दें:

• X-RateLimit-Limit — अवधि में अधिकतम अनुरोध संख्या
• X-RateLimit-Remaining — कितने अनुरोध शेष हैं
• X-RateLimit-Reset — सीमा कब रीसेट होगी (Unix timestamp)
• Retry-After — कितने सेकंड बाद अनुरोध दोहराया जा सकता है

यदि आपको स्टेटस कोड 429 (Too Many Requests) मिला, तो इसका मतलब है सीमा पार हो गई। Retry-After हेडर पढ़ें और अगले अनुरोध से पहले निर्दिष्ट समय प्रतीक्षा करें।

Rate limiter का कार्यान्वयन

अनुरोध गति नियंत्रण तंत्र बनाएं: