← Back to Blog
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

"गलती 'बहुत अधिक अनुरोध' 429: प्रॉक्सी और आईपी रोटेशन के माध्यम से सीमाओं को कैसे बायपास करें"

हम 429 Too Many Requests त्रुटि के कारणों का विश्लेषण करते हैं और प्रॉक्सी के माध्यम से सीमाओं को बायपास करने के 5 तरीके दिखाते हैं: IP रोटेशन से लेकर User-Agent सेटिंग और अनुरोधों के बीच देरी तक।

📅December 31, 2025
```html

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

हम विभिन्न कार्यों के लिए विशिष्ट समाधान दिखाएंगे: Wildberries और Ozon की पार्सिंग, प्रतिस्पर्धियों की निगरानी, सोशल मीडिया API के साथ काम करना, डेटा का सामूहिक संग्रह। सभी सिफारिशें व्यावहारिक अनुभव पर आधारित हैं और वास्तविक परियोजनाओं में काम करती हैं।

429 बहुत अधिक अनुरोध त्रुटि क्या है और यह क्यों उत्पन्न होती है

त्रुटि 429 बहुत अधिक अनुरोध एक HTTP प्रतिक्रिया कोड है, जिसे सर्वर तब लौटाता है जब आप एक निश्चित समय अवधि में अनुमत अनुरोधों की संख्या को पार कर लेते हैं। यह वेबसाइटों का एक सुरक्षा तंत्र है जो ओवरलोडिंग और स्वचालित डेटा संग्रह से बचाता है।

सामान्य स्थितियाँ जब 429 उत्पन्न होती है:

  • मार्केटप्लेस की पार्सिंग — आप Wildberries, Ozon या Avito से कीमतें इकट्ठा कर रहे हैं, मिनट में सैकड़ों अनुरोध करते हैं। साइट एक IP से असामान्य गतिविधि देखती है और उसे ब्लॉक कर देती है।
  • प्रतिस्पर्धियों की निगरानी — उत्पादों, कीमतों, उपलब्धता की स्वचालित डेटा संग्रह। बार-बार जांच करने पर सीमा सक्रिय हो जाती है।
  • API के साथ काम करना — कई API में कठोर सीमाएँ होती हैं: उदाहरण के लिए, Instagram API प्रति घंटे 200 अनुरोधों की अनुमति देता है, Twitter — 15 मिनट में 300 अनुरोध।
  • सामूहिक पंजीकरण या क्रियाएँ — खाते बनाना, संदेश भेजना, लाइक करना। प्लेटफार्म जल्दी से स्वचालन का पता लगाते हैं और IP को ब्लॉक कर देते हैं।

यह समझना महत्वपूर्ण है: त्रुटि 429 केवल एक तकनीकी सीमा नहीं है। यह संकेत है कि साइट ने आपकी गतिविधि को संदिग्ध के रूप में पहचाना है। यदि आप उसी IP से हमले को जारी रखते हैं, तो आपको स्थायी प्रतिबंध मिल सकता है।

महत्वपूर्ण: कुछ साइटें 429 के बजाय 403 निषिद्ध लौटाती हैं या बस कैप्चा दिखाती हैं। सार वही है — आपने सीमाएँ पार की हैं और आपको ब्लॉक कर दिया गया है।

साइटें संदिग्ध गतिविधि को कैसे पहचानती हैं

प्रभावी ढंग से ब्लॉक को बायपास करने के लिए, यह समझना आवश्यक है कि साइटें आपको कैसे पहचानती हैं। आधुनिक सुरक्षा प्रणालियाँ कई पैरामीटर का विश्लेषण करती हैं:

1. IP पता और अनुरोधों की आवृत्ति

सबसे स्पष्ट पैरामीटर। यदि एक IP से प्रति मिनट 100 अनुरोध आते हैं, जबकि एक सामान्य उपयोगकर्ता 5-10 करता है — यह स्पष्ट स्वचालन है। साइटें सीमाएँ निर्धारित करती हैं:

  • Wildberries: एक IP से प्रति मिनट लगभग 60 अनुरोध
  • Ozon: प्रति मिनट लगभग 30-40 अनुरोध
  • Avito: कठोर सीमाएँ, विशेष रूप से खोज अनुरोधों के लिए
  • Instagram API: प्रति ऐप 200 अनुरोध प्रति घंटा

2. User-Agent और ब्राउज़र हेडर

यदि आप स्क्रिप्ट के माध्यम से सही User-Agent के बिना अनुरोध भेजते हैं, तो साइट तुरंत समझ जाती है कि यह असली ब्राउज़र नहीं है। हेडर का भी विश्लेषण किया जाता है: Accept, Accept-Language, Referer। इन हेडरों की अनुपस्थिति या असामान्य मान — लाल झंडा है।

3. व्यवहार पैटर्न

असली उपयोगकर्ता हर 2 सेकंड में आदर्श आवृत्ति के साथ अनुरोध नहीं करता। वह स्क्रॉल करता है, क्लिक करता है, विराम लेता है। यदि आपका पार्सर मेट्रोनोम की तरह काम करता है — यह संदिग्ध है।

4. IP पते का प्रकार

कई प्लेटफार्म डेटा केंद्रों के IP को काले सूची में डालते हैं। यदि आप AWS या Google Cloud के सस्ते प्रॉक्सी का उपयोग करते हैं, तो ब्लॉक होने की संभावना अधिक होती है। वास्तविक प्रदाताओं से आवासीय IP कम संदेह उत्पन्न करते हैं।

प्रॉक्सी रोटेशन: सीमाओं को बायपास करने का मुख्य तरीका

समस्या 429 का मुख्य समाधान है IP पते का रोटेशन। एक IP से सभी अनुरोध करने के बजाय, आप कई पते के बीच लोड को वितरित करते हैं। प्रत्येक IP थोड़े से अनुरोध करता है और सीमाएँ नहीं पार करता है।

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

रोटेशन का प्रकार यह कैसे काम करता है कब उपयोग करें
अनुरोध के अनुसार रोटेशन प्रत्येक अनुरोध एक नए IP से आता है। प्रॉक्सी प्रदाता स्वचालित रूप से पता बदलता है। जब आपको तेजी से बहुत सारे डेटा इकट्ठा करने की आवश्यकता हो
टाइमर के अनुसार रोटेशन IP हर 5-30 मिनट में बदलता है। आप अनुरोधों की एक श्रृंखला के लिए एक पता का उपयोग करते हैं। ऐसी साइटों के साथ काम करना जो सत्र की आवश्यकता होती हैं (कार्ट, प्रमाणीकरण)
स्थिर प्रॉक्सी का पूल आपके पास 100-1000 IP की सूची है। स्क्रिप्ट प्रत्येक अनुरोध के लिए एक यादृच्छिक पता चुनती है। जब रोटेशन और लोड वितरण पर पूर्ण नियंत्रण की आवश्यकता हो

व्यावहारिक उदाहरण: Wildberries की पार्सिंग

मान लीजिए, आपको 10,000 उत्पादों की कीमतें पार्स करनी हैं। Wildberries एक IP से प्रति मिनट 60 अनुरोधों के बाद ब्लॉक कर देता है। इसे हल करने के लिए:

  1. अनुरोध के अनुसार रोटेशन का उपयोग करें — प्रत्येक अनुरोध एक नए IP से आता है। आपको लगभग 167 विभिन्न IP की आवश्यकता है (10,000 अनुरोध / 60 प्रति मिनट = 167 मिनट एक IP पर, लेकिन रोटेशन के साथ आप इसे 10-15 मिनट में करते हैं)।
  2. विलंब सेट करें — रोटेशन के साथ भी 1000 अनुरोध प्रति सेकंड करना उचित नहीं है। आदर्श: विभिन्न IP के साथ प्रति सेकंड 5-10 अनुरोध।
  3. यादृच्छिकता जोड़ें — विलंब यादृच्छिक होना चाहिए: अनुरोधों के बीच 0.5 से 2 सेकंड।

ऐसी कार्यों के लिए आवासीय प्रॉक्सी सबसे उपयुक्त हैं जिनमें स्वचालित रोटेशन होता है — इनमें लाखों IP का पूल होता है और वे आपके बिना प्रत्येक अनुरोध पर पते बदलते हैं।

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

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

विलंब सेटिंग के नियम

मूल नियम: असली उपयोगकर्ता की नकल करें

  • न्यूनतम विलंब: अनुरोधों के बीच 0.5-1 सेकंड
  • अनुशंसित: 1-3 सेकंड यादृच्छिक भिन्नता के साथ
  • जटिल साइटों के लिए (मार्केटप्लेस, सोशल मीडिया): 2-5 सेकंड
  • त्रुटियों पर एक्सपोनेंशियल विलंब का उपयोग करें

एक्सपोनेंशियल विलंब (exponential backoff)

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

  • पहली कोशिश असफल → 1 सेकंड प्रतीक्षा करें
  • दूसरी कोशिश असफल → 2 सेकंड प्रतीक्षा करें
  • तीसरी कोशिश असफल → 4 सेकंड प्रतीक्षा करें
  • चौथी कोशिश असफल → 8 सेकंड प्रतीक्षा करें
  • और इसी तरह, अधिकतम तक (उदाहरण के लिए, 60 सेकंड)

यह रणनीति सर्वर को "ठंडा" होने का समय देती है और स्थायी प्रतिबंध की संभावना को कम करती है। कई API (Google, Twitter) अपनी दस्तावेज़ीकरण में इस दृष्टिकोण की सिफारिश करते हैं।

विभिन्न कार्यों के लिए सेटिंग का उदाहरण

कार्य अनुरोधों के बीच विलंब टिप्पणी
Wildberries की पार्सिंग 1-3 सेकंड प्रॉक्सी के रोटेशन के साथ 0.5-1 सेकंड तक तेज किया जा सकता है
Ozon की पार्सिंग 2-4 सेकंड Ozon स्वचालन के प्रति अधिक संवेदनशील है
Instagram API 18 सेकंड सीमा 200 अनुरोध/घंटा = हर 18 सेकंड में 1 अनुरोध
Google खोज की पार्सिंग 5-10 सेकंड Google जल्दी से बैन करता है, लंबे विराम की आवश्यकता होती है
Avito की निगरानी 3-6 सेकंड कठोर सुरक्षा, विशेष रूप से खोज के लिए

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

प्रॉक्सी का रोटेशन और विलंब अनुरोधों की आवृत्ति की समस्या को हल करते हैं, लेकिन यह पर्याप्त नहीं है। साइटें यह विश्लेषण करती हैं कि आप अनुरोध कैसे भेजते हैं। यदि हेडर संदिग्ध दिखते हैं — तो ब्लॉक होना अनिवार्य है।

ब्राउज़र की नकल के लिए अनिवार्य हेडर

प्रत्येक अनुरोध में होना चाहिए न्यूनतम हेडर सेट: 

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/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
Sec-Fetch-User: ?1
Cache-Control: max-age=0

User-Agent का रोटेशन

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

  • Chrome (Windows, macOS, Linux)
  • Firefox (विभिन्न संस्करण)
  • Safari (macOS, iOS)
  • Edge (Windows)

आम गलती: पुरानी User-Agent का उपयोग करना (उदाहरण के लिए, 2024 में Chrome 90) या डेस्कटॉप साइटों के लिए मोबाइल User-Agent। यह तुरंत स्वचालन का पता लगाता है।

Referer और Origin

कई साइटें यह जांचती हैं कि अनुरोध कहाँ से आया। यदि आप उत्पाद पृष्ठ की पार्सिंग कर रहे हैं, तो Referer हेडर में कैटलॉग या खोज का लिंक होना चाहिए। यदि API की पार्सिंग कर रहे हैं — तो सही Origin होना चाहिए।

Wildberries की पार्सिंग के लिए उदाहरण: 

Referer: https://www.wildberries.ru/catalog/0/search.aspx?search=नोटबुक
Origin: https://www.wildberries.ru

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

प्रॉक्सी के प्रकार का चयन महत्वपूर्ण है। सस्ते डेटा सेंटर प्रॉक्सी अक्सर पहले से ही काले सूचियों में होते हैं, और आप कम अनुरोध आवृत्ति पर भी 429 प्राप्त करेंगे।

सीमाओं को बायपास करने के लिए प्रॉक्सी के प्रकारों की तुलना

प्रॉक्सी का प्रकार फायदे नुकसान किस कार्यों के लिए
डेटा सेंटर उच्च गति, कम कीमत अक्सर बैन होते हैं, आसानी से पहचाने जाते हैं सरल साइटें जिनमें सुरक्षा नहीं है
आवासीय वास्तविक प्रदाताओं के IP, पहचानना कठिन, बड़े पते का पूल महंगे, कभी-कभी धीमे मार्केटप्लेस, सोशल मीडिया, जटिल साइटें
मोबाइल मोबाइल ऑपरेटरों के IP, अधिकतम विश्वास महंगे, सीमित पूल Instagram, TikTok, Facebook Ads

चुनाव के लिए सिफारिशें

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

सोशल मीडिया API के साथ काम करने के लिए: मोबाइल प्रॉक्सी सबसे अच्छा विकल्प हैं। Instagram और TikTok मोबाइल ऑपरेटरों के IP पर अधिक विश्वास करते हैं। एक मोबाइल IP बिना किसी समस्या के 5-10 खातों को संभाल सकता है।

प्रतिस्पर्धियों की कीमतों की निगरानी के लिए: टाइमर के अनुसार रोटेशन के साथ आवासीय प्रॉक्सी (हर 10-15 मिनट में)। यह एक IP से अनुरोधों की श्रृंखला करने की अनुमति देता है, सत्र को बनाए रखते हुए, लेकिन सीमाओं को पार नहीं करता।

सरल कार्यों (समाचार, ब्लॉग की पार्सिंग) के लिए: डेटा सेंटर प्रॉक्सी उपयुक्त हो सकते हैं यदि साइट में कोई गंभीर सुरक्षा नहीं है। लेकिन नियमित रूप से ब्लॉकों के लिए तैयार रहें।

वास्तविक मामले: मार्केटप्लेस और API की पार्सिंग

मामला 1: Wildberries पर कीमतों की निगरानी (10,000 उत्पाद दैनिक)

कार्य: मार्केटप्लेस का विक्रेता 10,000 वस्तुओं पर प्रतिस्पर्धियों की कीमतों की निगरानी करता है। डेटा को दिन में 2 बार इकट्ठा करना आवश्यक है।

समस्या: एक IP का उपयोग करने पर 50-60 अनुरोधों के बाद बैन मिल जाता था। 10,000 उत्पादों की पार्सिंग में कई घंटे लगते थे, लगातार ब्लॉकों के साथ।

समाधान:

  1. 50,000 IP के पूल और अनुरोध के अनुसार रोटेशन के साथ आवासीय प्रॉक्सी जोड़ी
  2. अनुरोधों के बीच 0.5 से 2 सेकंड के यादृच्छिक विलंब सेट करें
  3. User-Agent का रोटेशन जोड़ा (Chrome और Firefox के 20 विकल्प)
  4. सही Referer और Accept हेडर सेट करें

परिणाम: 10,000 उत्पादों की पार्सिंग 15-20 मिनट में बिना किसी ब्लॉक के होती है। प्रत्येक IP अधिकतम 1-2 अनुरोध करता है, जिसे स्वचालन के रूप में पहचानना असंभव है।

मामला 2: Instagram का स्वचालन (50 ग्राहक खाते)

कार्य: SMM एजेंसी Instagram में 50 ग्राहक खातों का प्रबंधन करती है। सामग्री प्रकाशित करना, टिप्पणियों का उत्तर देना, सांख्यिकी एकत्र करना आवश्यक है।

समस्या: Instagram API प्रति ऐप 200 अनुरोधों की सीमा है। 50 खातों के साथ काम करते समय सीमाएँ 10 मिनट में समाप्त हो जाती हैं।

समाधान:

  1. Instagram API के 10 विभिन्न ऐप बनाए (प्रत्येक ऐप पर 5 खाते)
  2. प्रत्येक ऐप एक अलग मोबाइल प्रॉक्सी का उपयोग करता है
  3. अनुरोधों के बीच 18 सेकंड का विलंब सेट करें (200 अनुरोध/घंटा = हर 18 सेकंड में 1 अनुरोध)
  4. 429 प्राप्त करने पर एक्सपोनेंशियल विलंब जोड़ा

परिणाम: सभी 50 खाते स्थिरता से काम करते हैं। 429 त्रुटियाँ बहुत कम होती हैं (सप्ताह में 1-2 बार) और स्वचालित रूप से पुनः प्रयासों के माध्यम से संसाधित की जाती हैं।

मामला 3: Avito की पार्सिंग (रूस भर में विज्ञापन)

कार्य: रियल एस्टेट एग्रीगेटर Avito से सभी शहरों में विज्ञापनों को अपने डेटाबेस के लिए इकट्ठा करता है।

समस्या: Avito के पास रूसी साइटों में से सबसे कठोर सुरक्षा है। विभिन्न IP डेटा केंद्रों से 10-15 अनुरोधों के बाद ब्लॉक शुरू हो जाते हैं।

समाधान:

  1. भौगोलिक रूप से संबद्ध आवासीय प्रॉक्सी पर स्विच करें (पार्सिंग के समान शहर से IP)
  2. अनुरोधों के बीच विलंब 3-5 सेकंड तक बढ़ाएँ
  3. सरल HTTP अनुरोधों के बजाय हेडलेस ब्राउज़र (Puppeteer) का उपयोग करें
  4. उपयोगकर्ता के कार्यों की नकल करें: स्क्रॉलिंग, क्लिक, माउस मूवमेंट

परिणाम: 50,000+ विज्ञापनों की सफल पार्सिंग प्रतिदिन। ब्लॉकों में 95% की कमी आई। शेष 5% नए IP के साथ पुनः प्रयासों के माध्यम से संसाधित होते हैं।

मामला 4: प्रतिस्पर्धियों के API की निगरानी (ई-कॉमर्स)

कार्य: ई-कॉमर्स स्टोर 20 प्रतिस्पर्धियों के API के माध्यम से उत्पादों की उपलब्धता और कीमतों की निगरानी करता है।

समस्या: अधिकांश प्रतिस्पर्धियों के API में सार्वजनिक सीमाएँ होती हैं (100-500 अनुरोध प्रति घंटा)। सीमा को पार करने पर 429 लौटता है।

समाधान:

  1. अनुरोधों की प्राथमिकता के साथ एक कतार बनाना (सबसे महत्वपूर्ण उत्पादों की अधिक बार जांच की जाती है)
  2. उत्तर हेडर (X-RateLimit-Remaining) के माध्यम से सीमाओं की निगरानी करना
  3. सीमा के 80% तक पहुँचने पर स्वचालित विराम
  4. प्रत्येक प्रतिस्पर्धी के लिए कई API कुंजी का उपयोग करना (जहाँ संभव हो)

परिणाम: प्रणाली स्वचालित रूप से अनुरोधों को इस तरह से वितरित करती है कि कभी भी सीमाएँ पार न हों। डेटा बिना ब्लॉकों के अधिकतम संभव आवृत्ति के साथ अपडेट होते हैं।

सभी मामलों से सामान्य सबक:

त्रुटि 429 का समाधान समग्र रूप से किया जाता है: प्रॉक्सी का रोटेशन + सही विलंब + वास्तविक व्यवहार की नकल। केवल एक विधि पर भरोसा नहीं करना चाहिए। यहां तक कि एक मिलियन IP के साथ भी, यदि आप संदिग्ध हेडरों के साथ प्रति सेकंड 1000 अनुरोध करते हैं, तो आपको ब्लॉक किया जाएगा।

निष्कर्ष

त्रुटि 429 बहुत अधिक अनुरोध — यह साइटों का एक सुरक्षा तंत्र है, जिसे सही दृष्टिकोण से बायपास किया जा सकता है। समस्या को हल करने के मुख्य सिद्धांत:

  • IP पते का रोटेशन — कई प्रॉक्सी के बीच लोड वितरित करें, ताकि प्रत्येक पता न्यूनतम अनुरोध करे
  • सही विलंब — यादृच्छिक विराम के साथ वास्तविक उपयोगकर्ता की नकल करें, 1 से 5 सेकंड के बीच
  • सही हेडर — प्रासंगिक User-Agent और ब्राउज़र के पूर्ण हेडर सेट का उपयोग करें
  • प्रॉक्सी के प्रकार का चयन — जटिल साइटों (मार्केटप्लेस, सोशल मीडिया) के लिए आवासीय या मोबाइल प्रॉक्सी का उपयोग करें
  • त्रुटियों को संसाधित करना — 429 प्राप्त करने पर एक्सपोनेंशियल विलंब लागू करें, साइट पर पुनः हमले न करें

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

यदि आप मार्केटप्लेस की पार्सिंग, प्रतिस्पर्धियों की निगरानी या सोशल मीडिया में स्वचालन के साथ काम करने की योजना बना रहे हैं, तो हम आवासीय प्रॉक्सी का प्रयास करने की सिफारिश करते हैं — वे IP पते का बड़ा पूल, स्वचालित रोटेशन और ब्लॉकों का न्यूनतम जोखिम प्रदान करते हैं। Instagram, TikTok और अन्य मोबाइल प्लेटफार्मों के साथ काम करने के लिए मोबाइल प्रॉक्सी सबसे उपयुक्त हैं, जो वास्तविक संचार ऑपरेटरों के IP के साथ होते हैं।

```