Back to Blog

प्रॉक्सी के माध्यम से रेट लिमिटिंग को बायपास करने के तरीके: आर्किटेक्चर, आईपी रोटेशन और डेवलपर्स के लिए कोड के उदाहरण

क्या आपकी पार्सर या API-क्लाइंट को दर सीमा रोकता है? हम प्रॉक्सी के माध्यम से अनुरोधों की संख्या पर सीमाओं को कैसे बायपास करें, इस पर चर्चा करते हैं - कोड के उदाहरणों और आर्किटेक्चरल समाधानों के साथ।

📅May 12, 2026
```html

दर सीमाएं - पार्सर के क्रैश होने, API एकीकरण के टूटने और स्वचालित स्क्रिप्टों को 429 Too Many Requests स्थिति प्राप्त करने का एक सबसे सामान्य कारण हैं। सर्वर एक IP से बहुत सारे अनुरोध देखता है - और बस जवाब देना बंद कर देता है। इस लेख में, हम प्रॉक्सी पर बुनियादी ढांचे को सही तरीके से स्थापित करने के तरीके पर चर्चा करेंगे ताकि बिना बैन और विफलताओं के अनुरोधों की सीमाओं को बायपास किया जा सके - Python और Node.js पर वास्तविक कोड के उदाहरणों के साथ।

दर सीमाएं क्या हैं और सामान्य विलंब क्यों मदद नहीं करते

दर सीमाएं (rate limiting) - यह सर्वर की सुरक्षा तंत्र है, जो एक स्रोत से एक निश्चित समय अवधि में अनुरोधों की संख्या को सीमित करता है। स्रोत आमतौर पर IP पता होता है, लेकिन उन्नत सिस्टम प्रमाणीकरण टोकन, User-Agent, कुकीज़ और यहां तक कि व्यवहार पैटर्न को भी ध्यान में रखते हैं।

जब आपका स्क्रिप्ट सीमा को पार करता है, तो सर्वर निम्नलिखित में से एक उत्तर लौटाता है:

  • 429 Too Many Requests — दर सीमाओं के लिए मानक HTTP स्थिति
  • 503 Service Unavailable — कभी-कभी 429 के बजाय उपयोग किया जाता है
  • 403 Forbidden — यदि IP पहले से ही ब्लॉक लिस्ट में है
  • खाली उत्तर या टाइमआउट — आक्रामक ब्लॉकिंग के दौरान

अधिकांश डेवलपर्स का पहला विचार है कि time.sleep(1) को अनुरोधों के बीच जोड़ना है। यह केवल बहुत नरम सीमाओं (जैसे, प्रति मिनट 60 अनुरोध) के लिए काम करता है। लेकिन वास्तविक परिदृश्य अधिक जटिल होते हैं:

लोकप्रिय प्लेटफार्मों की वास्तविक सीमाएं:

  • Twitter/X API (फ्री): प्रति माह 500,000 ट्वीट, लेकिन हर 15 मिनट में 15 अनुरोधों से अधिक नहीं
  • Google Search: बिना प्रमाणीकरण के प्रति IP ~100 अनुरोध प्रति दिन
  • Wildberries, Ozon: आक्रामक दर सीमाएं — प्रति मिनट 30-50 अनुरोधों के बाद ब्लॉक
  • GitHub API: बिना टोकन के 60 अनुरोध/घंटा, टोकन के साथ 5000/घंटा
  • Cloudflare-सुरक्षित साइटें: प्रति मिनट 10-20 अनुरोधों के बाद ब्लॉक कर सकती हैं

यदि आपको मार्केटप्लेस से 100,000 उत्पाद कार्ड इकट्ठा करने या वास्तविक समय में कीमतों की निगरानी करने की आवश्यकता है - विलंब बस मदद नहीं करेगा। एक अलग आर्किटेक्चर की आवश्यकता है। और यहीं प्रॉक्सी एक विकल्प नहीं, बल्कि एक आवश्यकता बन जाती हैं।

यह समझना महत्वपूर्ण है: दर सीमाएं IP पते से जुड़ी होती हैं। यदि आपके पास 100 अलग-अलग IP हैं - तो आपके पास वास्तव में 100 स्वतंत्र "कोटा" हैं। यही प्रॉक्सी के माध्यम से सीमाओं को बायपास करने का मुख्य सिद्धांत है।

प्रॉक्सी कैसे अनुरोधों की सीमाओं की समस्या को हल करते हैं

तंत्र सरल है: लक्ष्य सर्वर के लिए प्रत्येक अनुरोध एक अलग IP पते से जाता है। सर्वर के दृष्टिकोण से - ये विभिन्न उपयोगकर्ता हैं। इनमें से प्रत्येक की कोटा लगभग खर्च नहीं होती है, इसलिए ब्लॉकिंग नहीं होती है।

चलिए बिना प्रॉक्सी और प्रॉक्सी पूल के साथ काम करने के बीच के अंतर को एक विशिष्ट उदाहरण के साथ देखते हैं। मान लीजिए, सर्वर एक IP से प्रति मिनट 10 अनुरोधों की अनुमति देता है:

परिदृश्य प्रति मिनट अनुरोध ब्लॉकिंग 10,000 अनुरोधों के लिए समय
एक IP, बिना प्रॉक्सी 10 हाँ, 10 अनुरोधों के बाद ~16 घंटे
10 प्रॉक्सी, रोटेशन 100 नहीं ~1.7 घंटे
100 प्रॉक्सी, रोटेशन 1000 नहीं ~10 मिनट

बैंडविड्थ को स्केल करने के अलावा, प्रॉक्सी दर सीमाओं के साथ काम करते समय कई अन्य लाभ भी प्रदान करते हैं:

  • सत्रों का पृथक्करण — यदि एक IP बैन हो जाता है, तो अन्य काम करना जारी रखते हैं
  • भौगोलिक वितरण — अनुरोध विभिन्न क्षेत्रों से आते हैं, जिससे संदेह कम होता है
  • स्टिकी सत्र — कई चरणों के परिदृश्यों (प्रमाणीकरण + क्रिया) के लिए एक IP से "चिपकने" की क्षमता
  • लोड नियंत्रण — प्रत्येक IP पर अनुरोधों को सटीक रूप से मापना संभव है, बिना सीमा को पार किए

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

सभी प्रॉक्सी दर सीमाओं के खिलाफ समान रूप से प्रभावी नहीं होते। प्रकार का चयन लक्ष्य साइट, अनुरोधों की मात्रा और बजट पर निर्भर करता है। हम तीन मुख्य प्रकारों पर चर्चा करेंगे:

रिसिडेंशियल प्रॉक्सी

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

मोबाइल प्रॉक्सी

मोबाइल ऑपरेटरों (3G/4G/5G) के IP पते। उनकी विशेषता यह है कि एक IP हजारों वास्तविक उपयोगकर्ताओं द्वारा एक साथ उपयोग किया जा सकता है, इसलिए ऐसे पते को साइटें ब्लॉक करना नहीं चाहतीं। मोबाइल प्रॉक्सी उन जगहों पर सबसे अच्छे परिणाम दिखाते हैं जहां रिसिडेंशियल पहले से ही ब्लॉक होने लगते हैं - जैसे कि Instagram के उच्च-आवृत्ति पार्सिंग या उन API प्लेटफार्मों के साथ काम करना जो कनेक्शन के प्रकार का विश्लेषण करते हैं।

डेटा सेंटर प्रॉक्सी

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

प्रॉक्सी प्रकार गुमनामी गति कीमत सर्वश्रेष्ठ परिदृश्य
रिसिडेंशियल बहुत उच्च मध्यम $$ मार्केटप्लेस, सामाजिक नेटवर्क, Cloudflare
मोबाइल अधिकतम मध्यम $$$ Instagram API, उच्च-आवृत्ति पार्सिंग
डेटा सेंटर मध्यम उच्च $ ओपन API, सार्वजनिक डेटा

IP रोटेशन रणनीतियाँ: प्रति अनुरोध, स्टिकी सत्र, राउंड-रॉबिन

प्रॉक्सी का होना समस्या को हल नहीं करता है - उन्हें सही तरीके से प्रबंधित करना महत्वपूर्ण है। कई रोटेशन रणनीतियाँ हैं, प्रत्येक अपने परिदृश्यों के लिए उपयुक्त है।

प्रति अनुरोध रोटेशन (प्रत्येक अनुरोध पर नया IP)

प्रत्येक HTTP अनुरोध एक नए IP पते के माध्यम से जाता है। यह दर सीमाओं को बायपास करने की सबसे आक्रामक रणनीति है - सर्वर भौतिक रूप से एक IP के लिए काउंटर को जमा करने में असमर्थ है। यह निम्नलिखित के लिए उपयुक्त है:

  • उत्पाद कार्डों का पार्सिंग (प्रत्येक कार्ड - एक अलग अनुरोध)
  • खोज इंजनों से डेटा इकट्ठा करना
  • किसी भी stateless अनुरोध, जो सत्र की आवश्यकता नहीं होती

स्टिकी सत्र (सत्र के लिए निश्चित IP)

एक IP पूरे सत्र के दौरान (आमतौर पर 1-30 मिनट) उपयोग किया जाता है। यह उन परिदृश्यों के लिए महत्वपूर्ण है जहां प्रमाणीकरण की आवश्यकता होती है: खाते में प्रवेश करना, क्रिया करना, बाहर निकलना। यदि IP चरणों के बीच बदलता है - सर्वर सत्र को संदिग्ध के रूप में ब्लॉक कर सकता है।

राउंड-रॉबिन IP पर अनुरोधों की सीमा के साथ

सबसे सटीक रणनीति। आप सर्वर की सीमा जानते हैं (जैसे, प्रति मिनट 10 अनुरोध) और अनुरोधों को प्रॉक्सी पूल में इस तरह से वितरित करते हैं कि प्रत्येक IP कभी भी इस सीमा को पार न करे। प्रत्येक IP के लिए अंतिम अनुरोध के समय को ध्यान में रखते हुए एक कतार को लागू करने की आवश्यकता होती है।

आवश्यक प्रॉक्सी की संख्या की गणना करने का सूत्र:

N प्रॉक्सी = (लक्ष्य अनुरोधों की गति/मिनट) ÷ (IP पर सर्वर की सीमा/मिनट)
उदाहरण: 500 अनुरोध/मिनट की आवश्यकता है, सर्वर की सीमा - 10/मिनट → न्यूनतम 50 प्रॉक्सी की आवश्यकता है। ब्लॉकों के मामले में 20% अतिरिक्त जोड़ें: कुल 60 प्रॉक्सी।

Python में कोड के उदाहरण: requests, aiohttp, Scrapy

चलिए प्रैक्टिकल पर चलते हैं। नीचे तीन सबसे लोकप्रिय Python उपकरणों के लिए तैयार टेम्पलेट हैं।

1. requests + प्रॉक्सी का मैन्युअल रोटेशन

सबसे सरल विकल्प - प्रॉक्सी की सूची और प्रत्येक अनुरोध पर यादृच्छिक चयन:

import requests
import random
import time

PROXIES = [
    "http://user:[email protected]:8080",
    "http://user:[email protected]:8080",
    "http://user:[email protected]:8080",
    # ... आवश्यक संख्या जोड़ें
]

def get_random_proxy():
    proxy = random.choice(PROXIES)
    return {"http": proxy, "https": proxy}

def fetch_with_retry(url, max_retries=3):
    for attempt in range(max_retries):
        proxy = get_random_proxy()
        try:
            response = requests.get(
                url,
                proxies=proxy,
                timeout=10,
                headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"}
            )
            if response.status_code == 429:
                print(f"{proxy} पर दर सीमित, स्विच कर रहे हैं...")
                time.sleep(1)
                continue
            return response
        except requests.RequestException as e:
            print(f"प्रयास {attempt+1} विफल: {e}")
            time.sleep(2)
    return None

# उपयोग
urls = ["https://example.com/item/1", "https://example.com/item/2"]
for url in urls:
    result = fetch_with_retry(url)
    if result:
        print(f"ठीक है: {url} — {len(result.text)} बाइट्स")

2. दर सीमा को ध्यान में रखते हुए स्मार्ट प्रॉक्सी पूल

एक अधिक उन्नत विकल्प - ProxyPool वर्ग, जो प्रत्येक IP के अंतिम उपयोग के समय को ट्रैक करता है और निर्धारित सीमा को पार नहीं करता:

import requests
import time
from collections import defaultdict
from threading import Lock

class ProxyPool:
    def __init__(self, proxies, rate_limit=10, window=60):
        """
        proxies: 'http://user:pass@host:port' प्रारूप की स्ट्रिंग की सूची
        rate_limit: एक IP से विंडो सेकंड में अधिकतम अनुरोध
        window: सेकंड में समय खिड़की
        """
        self.proxies = proxies
        self.rate_limit = rate_limit
        self.window = window
        self.usage = defaultdict(list)  # proxy -> [timestamps]
        self.lock = Lock()

    def get_available_proxy(self):
        now = time.time()
        with self.lock:
            for proxy in self.proxies:
                # पुरानी टाइमस्टैम्प को साफ करें
                self.usage[proxy] = [
                    t for t in self.usage[proxy]
                    if now - t < self.window
                ]
                if len(self.usage[proxy]) < self.rate_limit:
                    self.usage[proxy].append(now)
                    return {"http": proxy, "https": proxy}
        return None  # सभी प्रॉक्सी सीमा समाप्त हो गई

    def fetch(self, url, **kwargs):
        proxy = self.get_available_proxy()
        if proxy is None:
            print("सभी प्रॉक्सी दर सीमित हैं, प्रतीक्षा कर रहे हैं...")
            time.sleep(5)
            return self.fetch(url, **kwargs)
        
        try:
            response = requests.get(url, proxies=proxy, timeout=10, **kwargs)
            return response
        except requests.RequestException as e:
            print(f"अनुरोध विफल: {e}")
            return None

# उपयोग
pool = ProxyPool(
    proxies=[
        "http://user:[email protected]:8080",
        "http://user:[email protected]:8080",
    ],
    rate_limit=10,  # प्रति IP 10 अनुरोध प्रति मिनट
    window=60
)

for i in range(100):
    r = pool.fetch(f"https://example.com/page/{i}")
    if r:
        print(f"पृष्ठ {i}: {r.status_code}")

3. aiohttp के लिए असिंक्रोनस पार्सिंग

असिंक्रोनस दृष्टिकोण कई प्रॉक्सी का समानांतर उपयोग करने की अनुमति देता है बिना थ्रेड्स को ब्लॉक किए:

import asyncio
import aiohttp
import itertools

PROXIES = [
    "http://user:[email protected]:8080",
    "http://user:[email protected]:8080",
    "http://user:[email protected]:8080",
]

proxy_cycle = itertools.cycle(PROXIES)

async def fetch(session, url, proxy):
    try:
        async with session.get(
            url,
            proxy=proxy,
            timeout=aiohttp.ClientTimeout(total=10)
        ) as response:
            if response.status == 429:
                await asyncio.sleep(2)
                return None
            return await response.text()
    except Exception as e:
        print(f"त्रुटि: {e}")
        return None

async def main(urls):
    connector = aiohttp.TCPConnector(limit=50)
    async with aiohttp.ClientSession(connector=connector) as session:
        tasks = [
            fetch(session, url, next(proxy_cycle))
            for url in urls
        ]
        results = await asyncio.gather(*tasks)
        return results

urls = [f"https://example.com/item/{i}" for i in range(200)]
results = asyncio.run(main(urls))
print(f"एकत्रित: {sum(1 for r in results if r is not None)} पृष्ठ")

4. Scrapy के लिए मिडलवेयर के माध्यम से रोटेशन

Scrapy के लिए एक तैयार समाधान है - scrapy-rotating-proxies। लेकिन आप अपना खुद का मिडलवेयर लिख सकते हैं:

# middlewares.py
import random

class RotatingProxyMiddleware:
    def __init__(self, proxies):
        self.proxies = proxies

    @classmethod
    def from_crawler(cls, crawler):
        return cls(proxies=crawler.settings.getlist("PROXY_LIST"))

    def process_request(self, request, spider):
        proxy = random.choice(self.proxies)
        request.meta["proxy"] = proxy

    def process_response(self, request, response, spider):
        if response.status == 429:
            spider.logger.warning(f"दर सीमित, प्रॉक्सी: {request.meta.get('proxy')}")
            # समस्या वाले प्रॉक्सी को छोड़ने की लॉजिक जोड़ सकते हैं
        return response

# settings.py
PROXY_LIST = [
    "http://user:[email protected]:8080",
    "http://user:[email protected]:8080",
]
DOWNLOADER_MIDDLEWARES = {
    "myproject.middlewares.RotatingProxyMiddleware": 350,
}
AUTOTHROTTLE_ENABLED = True
AUTOTHROTTLE_TARGET_CONCURRENCY = 10

Node.js में कोड के उदाहरण: axios, got, Puppeteer

Node.js - ब्राउज़रों को स्वचालित करने और API के साथ काम करने के लिए एक लोकप्रिय विकल्प है। यहाँ प्रॉक्सी के साथ काम करने के लिए तैयार पैटर्न हैं।

1. axios के साथ प्रॉक्सी का रोटेशन

const axios = require('axios');
const { HttpsProxyAgent } = require('https-proxy-agent');

const proxies = [
  'http://user:[email protected]:8080',
  'http://user:[email protected]:8080',
  'http://user:[email protected]:8080',
];

let proxyIndex = 0;

function getNextProxy() {
  const proxy = proxies[proxyIndex % proxies.length];
  proxyIndex++;
  return proxy;
}

async function fetchWithProxy(url, retries = 3) {
  for (let i = 0; i < retries; i++) {
    const proxyUrl = getNextProxy();
    const agent = new HttpsProxyAgent(proxyUrl);
    
    try {
      const response = await axios.get(url, {
        httpsAgent: agent,
        httpAgent: agent,
        timeout: 10000,
        headers: {
          'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64)',
        },
      });
      return response.data;
    } catch (error) {
      if (error.response?.status === 429) {
        console.log(`दर सीमित, प्रॉक्सी बदल रहे हैं...`);
        await new Promise(r => setTimeout(r, 1000));
        continue;
      }
      console.error(`प्रयास ${i + 1} विफल:`, error.message);
    }
  }
  return null;
}

// उपयोग
(async () => {
  const urls = Array.from({length: 50}, (_, i) => `https://example.com/item/${i}`);
  
  const results = await Promise.allSettled(
    urls.map(url => fetchWithProxy(url))
  );
  
  const successful = results.filter(r => r.status === 'fulfilled' && r.value).length;
  console.log(`सफलता: ${successful}/${urls.length}`);
})();

2. Puppeteer के साथ प्रॉक्सी और दर सीमाओं को बायपास करना

JavaScript रेंडरिंग और Cloudflare सुरक्षा वाली साइटों के लिए एक हेडलेस ब्राउज़र की आवश्यकता होती है:

const puppeteer = require('puppeteer');

const proxies = [
  'proxy1.example.com:8080',
  'proxy2.example.com:8080',
];

async function scrapeWithProxy(url, proxyHost) {
  const browser = await puppeteer.launch({
    args: [
      `--proxy-server=${proxyHost}`,
      '--no-sandbox',
      '--disable-setuid-sandbox',
    ],
    headless: true,
  });

  const page = await browser.newPage();
  
  // प्रॉक्सी प्रमाणीकरण
  await page.authenticate({
    username: 'user',
    password: 'pass',
  });

  // यथार्थवादी User-Agent सेट करें
  await page.setUserAgent(
    'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36'
  );

  try {
    await page.goto(url, { waitUntil: 'networkidle2', timeout: 30000 });
    
    // दर सीमा की जांच करें
    const status = await page.evaluate(() => document.title);
    if (status.includes('429') || status.includes('Too Many')) {
      console.log('दर सीमित, प्रॉक्सी बदलने की आवश्यकता है');
      return null;
    }
    
    const data = await page.evaluate(() => {
      return document.querySelector('.price')?.textContent || null;
    });
    
    return data;
  } finally {
    await browser.close();
  }
}

// कार्यों के अनुसार रोटेशन
(async () => {
  const urls = ['https://example.com/product/1', 'https://example.com/product/2'];
  
  for (let i = 0; i < urls.length; i++) {
    const proxy = proxies[i % proxies.length];
    const result = await scrapeWithProxy(urls[i], proxy);
    console.log(`${urls[i]}: ${result}`);
    await new Promise(r => setTimeout(r, 500)); // थोड़ी देर प्रतीक्षा करें
  }
})();

उन्नत तकनीकें: हेडर, फिंगरप्रिंट, Cloudflare को बायपास करना

IP बदलना आवश्यक है, लेकिन हमेशा पर्याप्त नहीं होता। आधुनिक सुरक्षा प्रणालियाँ अनुरोध के दर्जनों मापदंडों का विश्लेषण करती हैं। चलिए देखते हैं कि और क्या ध्यान में रखना आवश्यक है।

HTTP हेडर: न्यूनतम आवश्यक सेट

सामान्य हेडर के बिना अनुरोध बॉट की तरह दिखता है, भले ही IP बदल जाए। हमेशा जोड़ें:

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,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",
    "Connection": "keep-alive",
    "Upgrade-Insecure-Requests": "1",
    "Sec-Fetch-Dest": "document",
    "Sec-Fetch-Mode": "navigate",
    "Sec-Fetch-Site": "none",
    "Cache-Control": "max-age=0",
}

Retry-After हेडर को संभालना

429 के उत्तर में, सर्वर अक्सर बताता है कि कितनी देर प्रतीक्षा करनी चाहिए। इस हेडर को सही तरीके से संभालना अनावश्यक अनुरोधों को बर्बाद करने से रोकता है:

def handle_rate_limit(response):
    if response.status_code == 429:
        retry_after = response.headers.get("Retry-After")
        if retry_after:
            wait_time = int(retry_after)
            print(f"दर सीमित। {wait_time} सेकंड प्रतीक्षा कर रहे हैं...")
            time.sleep(wait_time + 1)  # +1 सेकंड बफर
        else:
            # यदि हेडर नहीं है तो एक्सपोनेंशियल विलंब
            time.sleep(min(2 ** attempt, 60))
        return True
    return False

TLS फिंगरप्रिंटिंग और इसे बायपास करने का तरीका

उन्नत प्रणालियाँ (Cloudflare, Akamai, PerimeterX) TLS फिंगरप्रिंट का विश्लेषण करती हैं - आपके TLS कनेक्शन का अद्वितीय "फिंगरप्रिंट"। मानक requests पुस्तकालय का एक आसानी से पहचाने जाने वाला फिंगरप्रिंट होता है। समाधान:

  • curl_cffi (Python) - TLS स्तर पर Chrome/Firefox के फिंगरप्रिंट की नकल करता है
  • tls-client (Go/Python) - विभिन्न ब्राउज़र प्रोफाइल का समर्थन करने वाला समान उपकरण
  • Playwright/Puppeteer - वास्तविक ब्राउज़र, डिफ़ॉल्ट रूप से आदर्श फिंगरप्रिंट
# pip install curl-cffi
from curl_cffi import requests as cffi_requests

response = cffi_requests.get(
    "https://cloudflare-protected-site.com/api/data",
    impersonate="chrome120",  # Chrome 120 की नकल करें
    proxies={"https": "http://user:[email protected]:8080"}
)
print(response.json())

कुकीज़ और सत्रों का प्रबंधन

यदि साइट सत्रों को ट्रैक करने के लिए कुकीज़ का उपयोग करती है, तो IP बदलना बिना कुकीज़ के बदलने का कोई मतलब नहीं है। प्रॉक्सी बदलते समय हमेशा एक नया सत्र बनाएं:

import requests

def create_fresh_session(proxy_url):
    """प्रत्येक प्रॉक्सी के लिए साफ कुकीज़ के साथ एक नया सत्र बनाएं"""
    session = requests.Session()
    session.proxies = {"http": proxy_url, "https": proxy_url}
    session.headers.update({
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
    })
    # पिछले सत्र से कुकीज़ नहीं ले जाई जातीं
    return session

# प्रत्येक नए IP के लिए - नया सत्र
for proxy in proxies:
    session = create_fresh_session(proxy)
    response = session.get("https://example.com/protected-page")
    # उत्तर को संभालें...

प्रॉक्सी और दर सीमाओं के साथ काम करते समय सामान्य गलतियाँ

सही तरीके से सेटअप की गई प्रॉक्सी के साथ भी, डेवलपर्स नियमित रूप से एक ही गड़बड़ियों पर गिरते हैं। यहाँ सबसे सामान्य गलतियाँ और उन्हें कैसे टाला जाए।

चेक-लिस्ट: पार्सर शुरू करने से पहले क्या जांचें

  • ☐ यथार्थवादी HTTP हेडर जोड़े गए हैं (User-Agent, Accept, Accept-Language)
  • ☐ प्रॉक्सी बदलने पर एक नया सत्र बनाया जाता है (नई कुकीज़)
  • ☐ 429, 503, 403 स्थितियों को पुनः प्रयास करने की लॉजिक के साथ संभाला जाता है
  • ☐ अनुरोधों के बीच विलंब लागू किया गया है (कम से कम 100-500 मिलीसेकंड)
  • ☐ प्रॉक्सी की संख्या लक्ष्य अनुरोधों की गति के अनुरूप है
  • ☐ प्रारंभ करने से पहले प्रॉक्सी का कार्य परीक्षण किया गया (health check)
  • ☐ प्रत्येक प्रॉक्सी के लिए त्रुटियों और सांख्यिकी को लॉग किया गया है
  • ☐ अनुरोधों के लिए टाइमआउट सेट किया गया है (15-30 सेकंड से अधिक नहीं)

गलती 1: "मृत" प्रॉक्सी का उपयोग

हमेशा प्रॉक्सी को पूल में जोड़ने से पहले जांचें और काम करते समय समय-समय पर जांचें। एक गैर-कार्यशील प्रॉक्सी के साथ चक्र - यह खोए हुए अनुरोध और टाइमआउट है:

def check_proxy(proxy_url, test_url="https://httpbin.org/ip", timeout=5):
    try:
        r = requests.get(
            test_url,
            proxies={"http": proxy_url, "https": proxy_url},
            timeout=timeout
        )
        return r.status_code == 200
    except:
        return False

# प्रारंभ करने से पहले कार्यशील प्रॉक्सी को फ़िल्टर करें
working_proxies = [p for p in PROXIES if check_proxy(p)]
print(f"कार्यशील प्रॉक्सी: {len(working_proxies)}/{len(PROXIES)}")

गलती 2: प्रोटोकॉल के प्रकार की अनदेखी

HTTP प्रॉक्सी सीधे HTTPS ट्रैफ़िक को प्रॉक्सी नहीं कर सकते (केवल CONNECT के माध्यम से)। SOCKS5 प्रॉक्सी परिवहन स्तर पर काम करते हैं और किसी भी प्रोटोकॉल का समर्थन करते हैं। अधिकांश आधुनिक साइटों के लिए SOCKS5 या HTTPS प्रॉक्सी का उपयोग करें:

# requests में SOCKS5 प्रॉक्सी (pip install requests[socks] की आवश्यकता है)
proxies = {
    "http": "socks5://user:[email protected]:1080",
    "https": "socks5://user:[email protected]:1080",
}

# HTTPS प्रॉक्सी
proxies = {
    "http": "https://user:[email protected]:8080",
    "https": "https://user:[email protected]:8080",
}

गलती 3: एक्सपोनेंशियल बैकऑफ का अभाव

यदि 429 के बाद आप तुरंत अनुरोध दोहराते हैं - तो आप केवल स्थिति को और बिगाड़ते हैं। सही रणनीति - एक्सपोनेंशियल विलंब के साथ जिटर (यादृच्छिक विचलन):

import random

def exponential_backoff(attempt, base=1, max_wait=60):
    """
    attempt: प्रयास संख्या (0 से शुरू)
    base: सेकंड में आधार विलंब
    max_wait: अधिकतम विलंब
    """
    wait = min(base * (2 ** attempt), max_wait)
    # जिटर ±25% थंडरिंग हर्ड से बचने के लिए
    jitter = wait * 0.25 * random.uniform(-1, 1)
    return wait + jitter

# पुनः प्रयास करने की लॉजिक में उपयोग
for attempt in range(5):
    response = requests.get(url, proxies=proxy)
    if response.status_code == 429:
        wait = exponential_backoff(attempt)
        print(f"दर सीमित। {wait:.1f}s प्रतीक्षा कर रहे हैं (प्रयास {attempt+1})")
        time.sleep(wait)
    else:
        break

गलती 4: सभी प्रॉक्सी के लिए एक थ्रेड

यदि आपके पास 50 प्रॉक्सी हैं, लेकिन एक निष्पादन थ्रेड है - तो आप एक समय में अधिकतम 1 प्रॉक्सी का उपयोग कर रहे हैं। ThreadPoolExecutor या समानांतर उपयोग के लिए असिंक्रोनस दृष्टिकोण का उपयोग करें:

from concurrent.futures import ThreadPoolExecutor, as_completed

def fetch_url(args):
    url, proxy = args
    try:
        r = requests.get(url, proxies={"https": proxy}, timeout=10)
        return url, r.status_code, len(r.text)
    except Exception as e:
        return url, None, str(e)

# सभी प्रॉक्सी का समानांतर उपयोग करें
tasks = [(url, proxies[i % len(proxies)]) for i, url in enumerate(urls)]

with ThreadPoolExecutor(max_workers=len(proxies)) as executor:
    futures = {executor.submit(fetch_url, task): task for task in tasks}
    for future in as_completed(futures):
        url, status, size = future.result()
        print(f"{url}: {status} ({size})")

निष्कर्ष और सिफारिशें

दर सीमाएं - एक हल की जाने वाली समस्या हैं, यदि आप इसे प्रणालीगत दृष्टिकोण से देखें। इस मार्गदर्शिका से मुख्य निष्कर्ष:

  • प्रॉक्सी पूल, न कि एक प्रॉक्सी - गंभीर कार्य के लिए न्यूनतम इकाई। प्रॉक्सी की संख्या सूत्र द्वारा निर्धारित की जाती है: लक्ष्य गति ÷ IP पर सर्वर की सीमा।
  • रोटेशन रणनीति महत्वपूर्ण है - stateless अनुरोधों के लिए प्रति अनुरोध, प्रमाणित परिदृश्यों के लिए स्टिकी सत्र।
  • IP - एकमात्र मापदंड नहीं है - हेडर, कुकीज़, TLS फिंगरप्रिंट और व्यवहार पैटर्न भी सुरक्षा प्रणालियों द्वारा विश्लेषित होते हैं।
  • 429 को सही तरीके से संभालें - एक्सपोनेंशियल बैकऑफ, Retry-After हेडर, ब्लॉक होने पर प्रॉक्सी बदलना।
  • प्रॉक्सी का प्रकार लक्ष्य पर निर्भर करता है - ओपन API के लिए डेटा सेंटर, मार्केटप्लेस के लिए रिसिडेंशियल, अधिकतम सुरक्षा के लिए मोबाइल।

यदि आप मार्केटप्लेस (Wildberries, Ozon) के पार्सिंग, सुरक्षित API से डेटा संग्रहण या उच्च गति पर स्वचालन के साथ काम कर रहे हैं - हम रिसिडेंशियल प्रॉक्सी से शुरू करने की सिफारिश करते हैं: ये गुमनामी और गति के बीच का आदर्श संतुलन प्रदान करते हैं, और उनके IP पते लगभग कभी ब्लॉक नहीं होते। उन कार्यों के लिए जहां उच्च अनुरोध आवृत्ति पर ब्लॉकों के लिए अधिकतम स्थिरता की आवश्यकता होती है, मोबाइल प्रॉक्सी पर विचार करना उचित है - उनके IP हजारों वास्तविक उपयोगकर्ताओं द्वारा साझा किए जाते हैं, जिससे किसी भी साइट के लिए ब्लॉक करना अत्यधिक अवांछनीय हो जाता है।

```