API दर सीमा निर्धारण प्रॉक्सी के साथ: अनुरोधों की सीमाओं को कैसे बायपास करें

```html

आपने पार्सर सेट किया, प्रॉक्सी जोड़ी, लेकिन API फिर भी 429 "बहुत अधिक अनुरोध" त्रुटियाँ लौटाता है या पहुँच को अवरुद्ध करता है? समस्या प्रॉक्सी में नहीं है, बल्कि उनके उपयोग की गलत रणनीति में है। दर सीमा प्रबंधन एक सुरक्षा तंत्र है जो API द्वारा एक निश्चित अवधि में एक IP पते से किए गए अनुरोधों की संख्या को सीमित करता है। इस लेख में, हम यह समझेंगे कि प्रॉक्सी के माध्यम से काम करते समय अवरोध क्यों होते हैं और सीमाओं को बायपास करने के लिए प्रणाली को सही तरीके से कैसे सेट करें।

API दर सीमा प्रबंधन क्या है और यह कैसे काम करता है

दर सीमा प्रबंधन (अनुरोधों की आवृत्ति को सीमित करना) एक सुरक्षा तंत्र है जो API को ओवरलोडिंग और दुरुपयोग से बचाता है। सेवा एक निश्चित समय सीमा में एक स्रोत से किए गए अनुरोधों की संख्या पर सीमा निर्धारित करती है। उदाहरण के लिए, लोकप्रिय API ऐसे सीमाएँ लागू करते हैं:

Twitter API: मानक पहुंच के लिए 15 मिनट में 300 अनुरोध
Instagram Graph API: प्रति ऐप प्रति घंटे 200 अनुरोध
Google Maps API: योजना पर निर्भर करता है, आमतौर पर प्रति दिन 100-1000 अनुरोध
Wildberries API: एक IP से प्रति मिनट लगभग 60 अनुरोधों की अनौपचारिक सीमाएँ
Avito API: विज्ञापनों को पार्स करने के लिए प्रति सेकंड 10 अनुरोध

अनुरोधों के स्रोत की पहचान करने के कई तरीके हैं, जिन पर दर सीमा प्रबंधन लागू होता है:

IP पता: सबसे सामान्य तरीका। API एक निश्चित समय सीमा में एक विशिष्ट IP से किए गए अनुरोधों की संख्या को गिनता है।

API कुंजी: यदि आप कुंजी के माध्यम से प्रमाणीकरण का उपयोग करते हैं, तो सीमा IP के बावजूद इसे बांधती है।

User-Agent और फिंगरप्रिंट: कुछ API ब्राउज़र के हेडर का विश्लेषण करते हैं और ग्राहक का डिजिटल फिंगरप्रिंट बनाते हैं।

सत्र (कुकीज़): सीमा उपयोगकर्ता के सत्र से कुकीज़ के माध्यम से बंधी हो सकती है।

जब सीमा पार हो जाती है, तो API HTTP स्थिति 429 "बहुत अधिक अनुरोध" लौटाता है और Retry-After हेडर, जो सीमा रीसेट होने तक का समय बताता है। कुछ सेवाएँ "रोलिंग विंडो" का उपयोग करती हैं, जहाँ सीमा धीरे-धीरे अपडेट होती है, और अन्य एक निश्चित विंडो का उपयोग करते हैं, जो एक निश्चित समय पर रीसेट होती है।

प्रॉक्सी स्वचालित रूप से दर सीमा प्रबंधन से क्यों नहीं बचाते

कई डेवलपर्स गलत तरीके से मानते हैं कि प्रॉक्सी को जोड़ना ही पर्याप्त है — और अनियंत्रित संख्या में अनुरोध भेजना संभव है। व्यावहारिक रूप से, ऐसी समस्याएँ उत्पन्न होती हैं:

सभी अनुरोधों के लिए एक ही प्रॉक्सी का उपयोग

यदि आपका स्क्रिप्ट सभी अनुरोधों के लिए एक ही प्रॉक्सी IP का उपयोग करता है, तो API इसे एक सामान्य उपयोगकर्ता के रूप में देखता है और मानक सीमाएँ लागू करता है। उदाहरण के लिए, आपने Wildberries के साथ एक निवासी प्रॉक्सी के माध्यम से कीमतों का पार्सर सेट किया। पार्सर प्रति मिनट 100 अनुरोध करता है, लेकिन सीमा 60 अनुरोध है। परिणाम: IP को 10-30 मिनट के लिए अवरुद्ध किया गया।

IP का धीमा रोटेशन

कुछ लोग 5-10 प्रॉक्सी का पूल उपयोग करते हैं और उनके बीच क्रमिक रूप से स्विच करते हैं। समस्या यह है कि प्रत्येक IP फिर भी सीमा तक पहुँचता है इससे पहले कि पूर्ण रोटेशन हो। मान लीजिए, आपके पास 10 प्रॉक्सी हैं और IP पर 100 अनुरोधों की सीमा है। यदि आप प्रति घंटे 1000 अनुरोध करते हैं, तो प्रत्येक प्रॉक्सी को 100 अनुरोध मिलेंगे — ठीक सीमा के किनारे। किसी भी असमानता के वितरण से अवरोध उत्पन्न होगा।

अन्य पहचान कारकों की अनदेखी

यहां तक कि IP की आदर्श रोटेशन के साथ भी, आपको अवरुद्ध किया जा सकता है, यदि:

सभी अनुरोध समान User-Agent के साथ आते हैं (उदाहरण के लिए, python-requests/2.28.0)
सभी अनुरोधों के लिए एक ही API कुंजी का उपयोग किया जाता है
अनुरोधों की आवृत्ति आदर्श है (हर 0.5 सेकंड) — यह बॉट की तरह दिखता है
प्रॉक्सी के IP एक ही सबनेट में हैं (उदाहरण के लिए, सभी 192.168.1.x रेंज में)

IP पतों की प्रतिष्ठा

डेटा सेंटर प्रॉक्सी अक्सर काले सूचियों में होते हैं, क्योंकि उनके IP सैकड़ों अन्य उपयोगकर्ताओं द्वारा पार्सिंग के लिए उपयोग किए जाते हैं। API ऐसे पतों पर अधिक कठोर सीमाएँ लागू कर सकता है या उन्हें तुरंत अवरुद्ध कर सकता है। उदाहरण के लिए, Instagram और Facebook डेटा केंद्रों को आक्रामक रूप से बैन करते हैं, भले ही आप आधिकारिक सीमाएँ पार न करें।

सीमाओं को बायपास करने के लिए IP रोटेशन रणनीतियाँ

प्रॉक्सी का सही रोटेशन दर सीमा प्रबंधन को बायपास करने की कुंजी है। कार्य के आधार पर प्रभावी रणनीतियाँ देखें।

प्रत्येक अनुरोध के बाद रोटेशन

सबसे आक्रामक रणनीति: प्रत्येक अनुरोध एक नए IP के माध्यम से जाता है। यह बहुत कठोर सीमाओं (1-5 अनुरोध प्रति IP) के लिए उपयुक्त है या जब लोड को अधिकतम रूप से फैलाना आवश्यक हो। इसके लिए निवासी प्रॉक्सी का उपयोग किया जाता है जो स्वचालित रोटेशन प्रदान करते हैं — वे लाखों IP का पूल प्रदान करते हैं, और प्रत्येक अनुरोध स्वचालित रूप से एक नया पता प्राप्त करता है।

उपयोग का उदाहरण: Instagram को अनौपचारिक API के माध्यम से पार्स करना, जहाँ सीमा एक IP से प्रति मिनट 5 अनुरोध है। प्रत्येक अनुरोध के बाद रोटेशन के साथ, आप 300 विभिन्न IP के माध्यम से प्रति मिनट 300 अनुरोध कर सकते हैं।

लाभ: दर सीमा प्रबंधन से अधिकतम सुरक्षा, प्रत्येक IP का न्यूनतम उपयोग।

नुकसान: उच्च लागत (निवासी प्रॉक्सी महंगे होते हैं), IP बदलने में देरी हो सकती है, सत्र बनाए रखना कठिन होता है।

समय के अनुसार रोटेशन (स्टिकी सत्र)

IP एक निश्चित समय (5-30 मिनट) के लिए उपयोग किया जाता है, फिर नए पर स्विच किया जाता है। यह रणनीति उन API के लिए उपयुक्त है जो सत्र को बनाए रखने की आवश्यकता होती है, या जब एक "उपयोगकर्ता" से कई संबंधित अनुरोध किए जाने की आवश्यकता होती है।

रोटेशन के लिए अनुकूलतम समय की गणना: यदि API की सीमा 100 अनुरोध प्रति घंटे है, और आप एक IP के माध्यम से 50 अनुरोध करने की योजना बना रहे हैं, तो 30 मिनट का स्टिकी सत्र उपयोग करें। इस समय में आप 25 अनुरोध करेंगे (समान लोड के साथ), जो सीमा से दो गुना कम है।

सीमाओं को ट्रैक करते हुए पूल के अनुसार रोटेशन

उन्नत रणनीति: आपका स्क्रिप्ट प्रत्येक IP से किए गए अनुरोधों की संख्या को ट्रैक करता है और सीमा के करीब पहुँचने पर स्वचालित रूप से नए पर स्विच करता है। उदाहरण के लिए, आपके पास 20 प्रॉक्सी का पूल है, API की सीमा 100 अनुरोध प्रति घंटे है। स्क्रिप्ट प्रत्येक IP के लिए काउंटर को ट्रैक करती है और 90 अनुरोधों तक पहुँचने पर अगले पर स्विच करती है।

यह रणनीति प्रोग्रामिंग लॉजिक की आवश्यकता होती है, लेकिन अधिकतम प्रभावशीलता देती है: आप प्रत्येक प्रॉक्सी का पूर्ण उपयोग करते हैं, सीमाओं को पार किए बिना।

भौगोलिक रोटेशन

कुछ API क्षेत्र के आधार पर विभिन्न सीमाएँ लागू करते हैं। उदाहरण के लिए, सेवा अमेरिका से अनुरोधों को यूरोप से अधिक कठोरता से सीमित कर सकती है। ऐसे मामलों में, विभिन्न देशों से प्रॉक्सी का उपयोग करें और उनके बीच लोड वितरित करें।

रोटेशन रणनीति	कब उपयोग करें	प्रॉक्सी का प्रकार
प्रत्येक अनुरोध के बाद	कठोर सीमाएँ (1-10 अनुरोध/IP), सोशल मीडिया पार्सिंग	निवासी स्वचालित रोटेशन के साथ
समय के अनुसार (5-30 मिनट)	सत्र की आवश्यकता है, मध्यम सीमाएँ (50-200 अनुरोध/घंटा)	निवासी स्टिकी या मोबाइल
सीमाओं को ध्यान में रखते हुए पूल के अनुसार	बड़ा पार्सिंग वॉल्यूम, ज्ञात API सीमाएँ	10+ IP के पूल के साथ कोई भी प्रकार
भौगोलिक	क्षेत्रीय सीमाएँ, स्थानीय सामग्री का पार्सिंग	विभिन्न देशों से निवासी

अनुरोधों के बीच विलंब सेटिंग

IP की आदर्श रोटेशन के साथ भी, अनुरोधों के बीच सही विलंब सेट करना महत्वपूर्ण है। बहुत तेज़ अनुरोध हमले के रूप में दिखाई देते हैं, भले ही वे विभिन्न IP से आ रहे हों।

न्यूनतम विलंब की गणना

सूत्र: विलंब = (सेकंड में समय विंडो / अनुरोधों की सीमा) × सुरक्षा गुणांक

उदाहरण: API प्रति घंटे 100 अनुरोधों की अनुमति देता है (3600 सेकंड)। न्यूनतम विलंब = 3600 / 100 = 36 सेकंड। सुरक्षा गुणांक 1.2 जोड़ें: 36 × 1.2 = 43 सेकंड एक IP से अनुरोधों के बीच।

यदि आप 10 प्रॉक्सी का उपयोग करते हैं और रोटेशन करते हैं, तो आप 4.3 सेकंड में अनुरोध कर सकते हैं (43 / 10), बिना किसी IP पर सीमा को पार किए।

यादृच्छिक विलंब (जिटर)

5 सेकंड के निश्चित विलंब के बजाय, यादृच्छिक अंतराल का उपयोग करें, उदाहरण के लिए, 3 से 7 सेकंड तक। यह आपके ट्रैफ़िक को वास्तविक उपयोगकर्ता की गतिविधियों के समान बनाता है। कई बॉट सुरक्षा प्रणालियाँ पैटर्न का विश्लेषण करती हैं: यदि अनुरोध ठीक हर 5.0 सेकंड में आते हैं, तो यह संदिग्ध है।

त्रुटियों के लिए एक्सपोनेंशियल विलंब

जब आप 429 त्रुटि प्राप्त करते हैं, तो तुरंत अनुरोध भेजना जारी न रखें। एक्सपोनेंशियल विलंब का उपयोग करें: पहली कोशिश 1 सेकंड में, दूसरी 2 में, तीसरी 4 में, चौथी 8 में और इसी तरह। यह एक मानक प्रथा है, जिसे API ग्राहकों से अपेक्षित करते हैं।

टिप: API प्रतिक्रिया में Retry-After हेडर की जाँच करें। यह उस समय को निर्दिष्ट करता है, जब आप अनुरोध को फिर से कर सकते हैं। इस मान को यादृच्छिक विलंब के बजाय उपयोग करें।

API के साथ काम करने के लिए किस प्रकार की प्रॉक्सी चुनें

प्रॉक्सी के प्रकार का चयन दर सीमा प्रबंधन को बायपास करने की सफलता पर महत्वपूर्ण प्रभाव डालता है। API के साथ काम करने के लिए प्रत्येक विकल्प के लाभ और हानियों पर विचार करें।

निवासी प्रॉक्सी

निवासी प्रॉक्सी वास्तविक उपयोगकर्ताओं के IP पते का उपयोग करते हैं, जो इंटरनेट सेवा प्रदाताओं द्वारा आवंटित होते हैं। API के लिए, यह सामान्य घरेलू इंटरनेट के रूप में दिखाई देता है।

API के लिए लाभ:

उच्च विश्वास: API घरेलू IP को शायद ही कभी बैन करते हैं
विशाल पूल: रोटेशन के लिए लाखों IP
भौगोलिक विविधता: विभिन्न शहरों और देशों से IP
सोशल मीडिया और कठोर API (Instagram, Facebook, TikTok) के लिए उपयुक्त

हानियाँ:

उच्च लागत: आमतौर पर ट्रैफ़िक के लिए भुगतान (1 GB के लिए $5-15 से)
परिवर्तनीय गति: अंतिम उपयोगकर्ता के इंटरनेट पर निर्भर करता है
अस्थिरता: IP किसी भी समय बंद हो सकता है

कब उपयोग करें: Instagram, Facebook, TikTok का पार्सिंग, मार्केटप्लेस API (Wildberries, Ozon) के साथ काम करना, कोई भी कार्य जहाँ IP की प्रतिष्ठा महत्वपूर्ण हो।

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

मोबाइल प्रॉक्सी मोबाइल ऑपरेटरों (4G/5G) के IP का उपयोग करते हैं। एक IP अक्सर हजारों वास्तविक उपयोगकर्ताओं द्वारा एक साथ उपयोग किया जाता है, इसलिए API उन्हें बहुत कम ही अवरुद्ध करते हैं।

API के लिए लाभ:

अधिकतम विश्वास: API मोबाइल ऑपरेटरों के IP को बैन नहीं कर सकते
मोबाइल ऐप और API (Instagram, TikTok, Snapchat) के लिए आदर्श
पुन: कनेक्ट होने पर IP का स्वचालित परिवर्तन (एयरप्लेन मोड)
एक IP अधिक अनुरोध बिना बैन के कर सकता है

हानियाँ:

बहुत उच्च लागत: एक IP के लिए $50-150 प्रति माह
छोटे पूल: सैकड़ों मोबाइल IP प्राप्त करना मुश्किल है
परिवर्तनीय गति: मोबाइल कनेक्शन की गुणवत्ता पर निर्भर करता है

कब उपयोग करें: मोबाइल API के साथ काम करना, Instagram/TikTok का बड़े पैमाने पर पार्सिंग करना, जब बैन से अधिकतम सुरक्षा की आवश्यकता हो।

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

डेटा सेंटर प्रॉक्सी सर्वरों के IP पते होते हैं, जो डेटा सेंटर में स्थित होते हैं। ये वास्तविक उपयोगकर्ताओं से जुड़े नहीं होते हैं।

API के लिए लाभ:

कम लागत: $1-5 प्रति IP प्रति माह
उच्च गति: 1-10 Gbps चैनल
स्थिरता: IP अचानक बंद नहीं होते
बड़े पूल: सैकड़ों IP प्राप्त करना आसान है

हानियाँ:

कम विश्वास: कई API डेटा सेंटरों को अवरुद्ध करते हैं
IP अक्सर अन्य उपयोगकर्ताओं के कारण काले सूचियों में होते हैं
सोशल मीडिया और कठोर सेवाओं के लिए उपयुक्त नहीं हैं

कब उपयोग करें: सार्वजनिक API का पार्सिंग करना जिसमें कठोर सुरक्षा नहीं है (जलवायु, मुद्रा दरें, समाचार), अपने API के साथ काम करना, परीक्षण और विकास।

मानदंड	निवासी	मोबाइल	डेटा सेंटर
API का विश्वास	उच्च	अधिकतम	कम
पूल का आकार	लाखों IP	सैकड़ों IP	हजारों IP
गति	मध्यम (10-50 Mbps)	मध्यम (5-100 Mbps)	उच्च (100+ Mbps)
लागत	$5-15/GB	$50-150/IP/माह	$1-5/IP/माह
सोशल मीडिया के लिए	✅ उत्कृष्ट	✅ आदर्श	❌ उपयुक्त नहीं
सार्वजनिक API के लिए	✅ अच्छा	✅ अच्छा (महंगा)	✅ उत्कृष्ट

व्यावहारिक कार्यान्वयन: Python में कोड के उदाहरण

प्रॉक्सी का उपयोग करके दर सीमा प्रबंधन को बायपास करने के विशिष्ट उदाहरणों पर विचार करें। सभी उदाहरण Python में requests पुस्तकालय के साथ हैं।

प्रॉक्सी के पूल से सरल रोटेशन

सूची से IP की चक्रीय रोटेशन के साथ मूल कार्यान्वयन:

import requests
import time
from itertools import cycle

# प्रॉक्सी की सूची (फॉर्मेट: protocol://user:pass@host:port)
PROXY_LIST = [
    'http://user1:pass1@proxy1.example.com:8080',
    'http://user2:pass2@proxy2.example.com:8080',
    'http://user3:pass3@proxy3.example.com:8080',
]

# चक्रीय इटरेटर बनाना
proxy_pool = cycle(PROXY_LIST)

def make_request(url):
    proxy = next(proxy_pool)  # पूल से अगली प्रॉक्सी लेना
    proxies = {
        'http': proxy,
        'https': proxy
    }
    
    try:
        response = requests.get(url, proxies=proxies, timeout=10)
        return response
    except requests.exceptions.RequestException as e:
        print(f"प्रॉक्सी {proxy} के साथ त्रुटि: {e}")
        return None

# उपयोग का उदाहरण
for i in range(10):
    response = make_request('https://api.example.com/data')
    if response and response.status_code == 200:
        print(f"अनुरोध {i+1}: सफलता")
    time.sleep(2)  # अनुरोधों के बीच विलंब

सीमाओं को ट्रैक करते हुए रोटेशन

एक उन्नत संस्करण, जो प्रत्येक प्रॉक्सी के लिए अनुरोधों की संख्या को गिनता है और सीमा के करीब पहुँचने पर स्विच करता है:

import requests
import time
from collections import defaultdict

class ProxyRotator:
    def __init__(self, proxy_list, max_requests_per_ip=90, time_window=3600):
        self.proxy_list = proxy_list
        self.max_requests = max_requests_per_ip  # IP पर अनुरोधों की सीमा
        self.time_window = time_window  # सेकंड में समय विंडो
        self.request_counts = defaultdict(list)  # प्रत्येक IP के लिए अनुरोधों का इतिहास
        self.current_index = 0
    
    def get_proxy(self):
        """सबसे कम अनुरोधों वाले प्रॉक्सी को लौटाता है"""
        current_time = time.time()
        
        # समय विंडो के बाहर पुराने रिकॉर्ड को साफ करना
        for proxy in self.request_counts:
            self.request_counts[proxy] = [
                t for t in self.request_counts[proxy]
                if current_time - t < self.time_window
            ]
        
        # सबसे कम अनुरोधों वाले प्रॉक्सी की खोज
        available_proxies = []
        for proxy in self.proxy_list:
            count = len(self.request_counts[proxy])
            if count < self.max_requests:
                available_proxies.append((proxy, count))
        
        if not available_proxies:
            # यदि सभी प्रॉक्सी सीमा तक पहुँच चुके हैं, तो प्रतीक्षा करें
            oldest_request = min(
                min(times) for times in self.request_counts.values() if times
            )
            wait_time = self.time_window - (current_time - oldest_request) + 1
            print(f"सभी प्रॉक्सी सीमा तक पहुँच चुके हैं। प्रतीक्षा {wait_time:.0f} सेकंड...")
            time.sleep(wait_time)
            return self.get_proxy()
        
        # सबसे कम अनुरोधों वाले प्रॉक्सी का चयन करें
        proxy = min(available_proxies, key=lambda x: x[1])[0]
        self.request_counts[proxy].append(current_time)
        return proxy
    
    def make_request(self, url, **kwargs):
        proxy = self.get_proxy()
        proxies = {'http': proxy, 'https': proxy}
        
        try:
            response = requests.get(url, proxies=proxies, timeout=10, **kwargs)
            return response
        except requests.exceptions.RequestException as e:
            print(f"प्रॉक्सी {proxy} के साथ त्रुटि: {e}")
            return None

# उपयोग का उदाहरण
PROXY_LIST = [
    'http://user:pass@proxy1.example.com:8080',
    'http://user:pass@proxy2.example.com:8080',
]

rotator = ProxyRotator(PROXY_LIST, max_requests_per_ip=100, time_window=3600)

for i in range(500):  # 500 अनुरोध करें
    response = rotator.make_request('https://api.example.com/data')
    if response and response.status_code == 200:
        print(f"अनुरोध {i+1}: सफलता")
    time.sleep(1)  # न्यूनतम विलंब

429 त्रुटियों के साथ एक्सपोनेंशियल विलंब का प्रबंधन

"बहुत अधिक अनुरोध" प्रतिक्रिया को सही तरीके से प्रबंधित करना, Retry-After हेडर को ध्यान में रखते हुए:

import requests
import time

def make_request_with_retry(url, proxies, max_retries=5):
    """429 त्रुटि पर स्वचालित पुनः प्रयास के साथ अनुरोध करता है"""
    
    for attempt in range(max_retries):
        try:
            response = requests.get(url, proxies=proxies, timeout=10)
            
            if response.status_code == 200:
                return response
            
            elif response.status_code == 429:
                # Retry-After हेडर की जाँच करें
                retry_after = response.headers.get('Retry-After')
                
                if retry_after:
                    wait_time = int(retry_after)
                    print(f"दर सीमा। प्रतीक्षा {wait_time} सेकंड (Retry-After से)")
                else:
                    # एक्सपोनेंशियल विलंब: 2^attempt सेकंड
                    wait_time = 2 ** attempt
                    print(f"दर सीमा। प्रयास {attempt+1}, प्रतीक्षा {wait_time} सेकंड")
                
                time.sleep(wait_time)
                continue
            
            else:
                print(f"HTTP त्रुटि {response.status_code}")
                return None
        
        except requests.exceptions.RequestException as e:
            print(f"संपर्क त्रुटि: {e}")
            if attempt < max_retries - 1:
                time.sleep(2 ** attempt)
                continue
            return None
    
    print(f"प्रयासों की संख्या पार हो गई ({max_retries})")
    return None

# उपयोग का उदाहरण
proxies = {
    'http': 'http://user:pass@proxy.example.com:8080',
    'https': 'http://user:pass@proxy.example.com:8080'
}

response = make_request_with_retry('https://api.example.com/data', proxies)
if response:
    print("डेटा प्राप्त किया:", response.json())

स्वचालित रोटेशन के साथ निवासी प्रॉक्सी का उपयोग

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

import requests
import random
import time

# स्वचालित रोटेशन के साथ निवासी प्रॉक्सी
# फॉर्मेट: protocol://username:password@gateway:port
ROTATING_PROXY = 'http://customer-USER:PASS@proxy.provider.com:12321'

def make_request_rotating(url):
    """रोटेटिंग प्रॉक्सी के माध्यम से अनुरोध (हर बार नया IP)"""
    proxies = {
        'http': ROTATING_PROXY,
        'https': ROTATING_PROXY
    }
    
    # अधिक गुमनामी के लिए यादृच्छिक User-Agent जोड़ें
    user_agents = [
        'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36',
        'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36',
        'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36',
    ]
    
    headers = {
        'User-Agent': random.choice(user_agents)
    }
    
    try:
        response = requests.get(url, proxies=proxies, headers=headers, timeout=15)
        return response
    except requests.exceptions.RequestException as e:
        print(f"त्रुटि: {e}")
        return None

# विभिन्न IP के माध्यम से 100 अनुरोध करें
for i in range(100):
    response = make_request_rotating('https://api.example.com/data')
    if response and response.status_code == 200:
        print(f"अनुरोध {i+1}: सफलता, IP बदल गया")
    
    # 1-3 सेकंड की यादृच्छिक विलंब
    time.sleep(random.uniform(1, 3))

सीमाओं की निगरानी और त्रुटियों का प्रबंधन

API के साथ प्रभावी काम करने के लिए सीमाओं की निरंतर निगरानी और त्रुटियों का सही प्रबंधन आवश्यक है। यहाँ कुछ प्रमुख प्रथाएँ हैं:

उत्तर हेडर का विश्लेषण

कई API उत्तर हेडर में सीमाओं के बारे में जानकारी लौटाते हैं। मानक हेडर:

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

इन हेडरों को पढ़ने का उदाहरण:

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

# सीमाओं के हेडरों की जाँच करें
limit = response.headers.get('X-RateLimit-Limit')
remaining = response.headers.get('X-RateLimit-Remaining')
reset_time = response.headers.get('X-RateLimit-Reset')

if remaining:
    remaining = int(remaining)
    if remaining < 10:
        print(f"ध्यान दें! केवल {remaining} अनुरोध बचे हैं")
        
if reset_time:
    import datetime
    reset_dt = datetime.datetime.fromtimestamp(int(reset_time))
    print(f"सीमा {reset_dt} पर रीसेट होगी")

लॉगिंग और सांख्यिकी

प्रत्येक प्रॉक्सी के लिए अनुरोधों की विस्तृत सांख्यिकी रखें। यह समस्याग्रस्त IP की पहचान करने और रोटेशन को अनुकूलित करने में मदद करेगा:

import json
from datetime import datetime

class RequestLogger:
    def __init__(self):
        self.stats = {}
    
    def log_request(self, proxy, status_code, response_time):
        if proxy not in self.stats:
            self.stats[proxy] = {
                'total': 0,
                'success': 0,
                'rate_limited': 0,
                'errors': 0,
                'avg_response_time': 0
            }
        
        self.stats[proxy]['total'] += 1
        
        if status_code == 200:
            self.stats[proxy]['success'] += 1
        elif status_code == 429:
            self.stats[proxy]['rate_limited'] += 1
        else:
            self.stats[proxy]['errors'] += 1
        
        # औसत प्रतिक्रिया समय को अपडेट करें
        current_avg = self.stats[proxy]['avg_response_time']
        total = self.stats[proxy]['total']
        self.stats[proxy]['avg_response_time'] = (
            (current_avg * (total - 1) + response_time) / total
        )
    
    def print_stats(self):
        print("\n=== प्रॉक्सी सांख्यिकी ===")
        for proxy, data in self.stats.items():
            success_rate = (data['success'] / data['total'] * 100) if data['total'] > 0 else 0
            print(f"\nप्रॉक्सी: {proxy}")
            print(f"  कुल अनुरोध: {data['total']}")
            print(f"  सफल: {data['success']} ({success_rate:.1f}%)")
            print(f"  दर सीमित: {data['rate_limited']}")
            print(f"  त्रुटियाँ: {data['errors']}")
            print(f"  औसत प्रतिक्रिया समय: {data['avg_response_time']:.2f}s")

# उपयोग
logger = RequestLogger()

start_time = time.time()
response = requests.get(url, proxies=proxies)
response_time = time.time() - start_time

logger.log_request(proxy, response.status_code, response_time)
logger.print_stats()

स्वचालित रूप से रणनीति बदलना

यदि आप लगातार 429 त्रुटियाँ प्राप्त कर रहे हैं, तो स्वचालित रूप से अनुरोधों को धीमा करें या प्रॉक्सी का पूल बढ़ाएँ:

class AdaptiveRateLimiter:
    def __init__(self, initial_delay=1.0):
        self.delay = initial_delay
        self.consecutive_429 = 0
    
    def on_success(self):
        """सफल अनुरोध - थोड़ी तेजी लाने का समय"""
        self.consecutive_429 = 0
        self.delay = max(0.5, self.delay * 0.95)  # 5% कम करें
    
    def on_rate_limit(self):
        """429 प्राप्त हुआ - धीमा होना चाहिए"""
        self.consecutive_429 += 1
        self.delay *= 1.5  # विलंब को 1.5 गुना बढ़ाएँ
        
        if self.consecutive_429 > 5:
            print("ध्यान दें: बहुत अधिक 429 त्रुटियाँ। सेटिंग्स की जाँच करें!")
    
    def wait(self):
        """अगले अनुरोध से पहले प्रतीक्षा करें"""
        time.sleep(self.delay)
        return self.delay

# उपयोग
limiter = AdaptiveRateLimiter(initial_delay=2.0)

for i in range(1000):
    response = make_request(url)
    
    if response.status_code == 200:
        limiter.on_success()
    elif response.status_code == 429:
        limiter.on_rate_limit()
    
    delay = limiter.wait()
    print(f"अनुरोध {i+1}, विलंब: {delay:.2f}s")

कैप्चा और अन्य अवरोधों का प्रबंधन

कुछ API सीमाओं को पार करने पर कैप्चा दिखाते हैं, सीधे अवरुद्ध करने के बजाय। संकेत:

"कैप्चा" या "रीकैप्चा" वाले उत्तर के साथ स्थिति कोड 403
कैप्चा पृष्ठ पर रीडायरेक्ट (स्थिति 302)
विशेष हेडर जैसे X-Captcha-Required: true

ऐसे मामलों में, आपको:

इस IP का उपयोग तुरंत बंद करें
पूल से दूसरे प्रॉक्सी पर स्विच करें
अनुरोधों के बीच विलंब बढ़ाएँ
User-Agent और अन्य हेडरों में अधिक विविधता जोड़ें

महत्वपूर्ण: यदि आप नियमित रूप से निवासी प्रॉक्सी का उपयोग करते समय कैप्चा का सामना करते हैं, तो समस्या संभवतः व्यवहार पैटर्न (समान हेडर, बहुत तेज़ अनुरोध) में है, न कि IP पतों में।

निष्कर्ष

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

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

```

प्रॉक्सी के माध्यम से पार्सिंग करते समय API रेट लिमिटिंग को कैसे बायपास करें: रोटेशन सेटअप और IP चयन

API दर सीमा प्रबंधन क्या है और यह कैसे काम करता है

प्रॉक्सी स्वचालित रूप से दर सीमा प्रबंधन से क्यों नहीं बचाते

सभी अनुरोधों के लिए एक ही प्रॉक्सी का उपयोग

IP का धीमा रोटेशन

अन्य पहचान कारकों की अनदेखी

IP पतों की प्रतिष्ठा

सीमाओं को बायपास करने के लिए IP रोटेशन रणनीतियाँ

प्रत्येक अनुरोध के बाद रोटेशन

समय के अनुसार रोटेशन (स्टिकी सत्र)

सीमाओं को ट्रैक करते हुए पूल के अनुसार रोटेशन

भौगोलिक रोटेशन

अनुरोधों के बीच विलंब सेटिंग

न्यूनतम विलंब की गणना

यादृच्छिक विलंब (जिटर)

त्रुटियों के लिए एक्सपोनेंशियल विलंब

API के साथ काम करने के लिए किस प्रकार की प्रॉक्सी चुनें

निवासी प्रॉक्सी

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

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

व्यावहारिक कार्यान्वयन: Python में कोड के उदाहरण

प्रॉक्सी के पूल से सरल रोटेशन

सीमाओं को ट्रैक करते हुए रोटेशन

429 त्रुटियों के साथ एक्सपोनेंशियल विलंब का प्रबंधन

स्वचालित रोटेशन के साथ निवासी प्रॉक्सी का उपयोग

सीमाओं की निगरानी और त्रुटियों का प्रबंधन

उत्तर हेडर का विश्लेषण

लॉगिंग और सांख्यिकी

स्वचालित रूप से रणनीति बदलना

कैप्चा और अन्य अवरोधों का प्रबंधन

निष्कर्ष