त्रुटि 429 पार्सिंग में: प्रॉक्सी के अलावा 6 कारण

आप प्रॉक्सी बदलते हैं, नए IP पते का पूल खरीदते हैं, लेकिन पार्सर फिर भी त्रुटि 429 Too Many Requests के साथ गिर जाता है? यह एक क्लासिक स्थिति है: 70% ब्लॉकिंग मामलों का संबंध IP पते से नहीं है, बल्कि यह इस बात से है कि अनुरोध कैसा दिखता है। हम छह वास्तविक कारणों पर चर्चा करते हैं, जिनके कारण साइट आपको प्रॉक्सी बदलने के बाद भी बैन करती रहती है — और प्रत्येक मामले में क्या करना है।

त्रुटि 429 का क्या अर्थ है और प्रॉक्सी क्यों नहीं है एक万能解決策

HTTP कोड 429 Too Many Requests का औपचारिक अर्थ है "अनुरोधों की सीमा पार हो गई"। लेकिन व्यावहारिक रूप से, साइटें — विशेष रूप से वाइल्डबेरीज़, ओज़ोन, अविटो, यांडेक्स.मार्केट — इस कोड का उपयोग एक सामान्य संकेत के रूप में करती हैं "हम मानते हैं कि आप एक बॉट हैं"। कारण अनुरोधों की आवृत्ति में हो सकता है, लेकिन उतनी ही संभावना है — हेडर, ब्राउज़र का फ़िंगरप्रिंट, कुकी सत्र की अनुपस्थिति या सीमाएँ, जो IP से नहीं, बल्कि आपके खाते से जुड़ी हैं।

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

महत्वपूर्ण: प्रॉक्सी एक आवश्यक उपकरण बने रहते हैं — लेकिन केवल सिस्टम का एक हिस्सा के रूप में, न कि एकमात्र समाधान के रूप में। रेजिडेंट और मोबाइल IP IP की प्रतिष्ठा के कारण ब्लैकलिस्ट में आने की संभावना को कम करते हैं, लेकिन व्यवहार या हेडर के कारण ब्लॉकिंग से नहीं बचाते।

कारण 1: बहुत अधिक अनुरोधों की आवृत्ति

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

यदि आपका पार्सर एक ही श्रेणी में प्रति सेकंड 50-100 अनुरोध करता है, तो सिस्टम ट्रैफ़िक में असामान्य वृद्धि देखता है, चाहे आप कितने विभिन्न IP का उपयोग करें। समाधान — प्रॉक्सी बदलना नहीं, बल्कि अनुरोधों के बीच कृत्रिम विलंब (थ्रॉटलिंग) को लागू करना है: 1-3 सेकंड की यादृच्छिक विलंबता के बजाय निश्चित अंतराल, और 429 प्राप्त करने पर एक्सपोनेंशियल बैकऑफ (हर ब्लॉक के बाद विराम को दोगुना करना)।

import time, random

def safe_request(session, url):
    for attempt in range(5):
        response = session.get(url)
        if response.status_code == 429:
            wait = (2 ** attempt) + random.uniform(0, 1)
            time.sleep(wait)
            continue
        return response
    return None

यदि आप बिना कोड के तैयार पार्सर का उपयोग कर रहे हैं (उदाहरण के लिए, क्लाउड सेवा मूल्य निगरानी के लिए), तो अनुरोधों के बीच के अंतराल की सेटिंग्स की जांच करें — अधिकांश ऐसे उपकरणों में "स्कैनिंग गति" का स्लाइडर होता है। गति को 30-40% कम करने से अक्सर 429 पूरी तरह से हटा दी जाती है, यहां तक कि प्रॉक्सी को बदले बिना।

कारण 2: गलत या अनुपस्थित हेडर

कई पार्सर न्यूनतम हेडर सेट के साथ अनुरोध भेजते हैं या डिफ़ॉल्ट रूप से यूजर-एजेंट लाइब्रेरी का उपयोग करते हैं (उदाहरण के लिए, "python-requests/2.28.1")। ऐसा हेडर तुरंत बॉट को प्रकट करता है — वास्तविक ब्राउज़र दर्जनों हेडर भेजता है: Accept, Accept-Language, Accept-Encoding, Sec-Fetch-*, Referer और अन्य एक निश्चित क्रम में।

वाइल्डबेरीज़ और ओज़ोन हेडर सेट की तुलना वास्तविक ब्राउज़र क्रोम या सफारी के अपेक्षित "फ़िंगरप्रिंट" से करते हैं। यदि हेडर बहुत कम हैं, वे सही क्रम में नहीं हैं या यूजर-एजेंट अन्य पैरामीटर से मेल नहीं खाता (उदाहरण के लिए, विंडोज पर क्रोम घोषित किया गया है, जबकि TLS फ़िंगरप्रिंट पायथन के समान है) — अनुरोध 429 पर ब्लॉक किया जाता है, चाहे IP कुछ भी हो।

हेडर	सामान्य गलती	समाधान
यूजर-एजेंट	पुरानी संस्करण या स्पष्ट रूप से लाइब्रेरी स्ट्रिंग	वास्तविक क्रोम/सफारी का अद्यतन UA, पूल से घुमाव
Accept-Language	अनुपस्थित या IP की भू-स्थान के साथ मेल नहीं खाता	रू-आरयू रूसी मार्केटप्लेस के लिए
Referer	खाली, जबकि वास्तविक संक्रमण हमेशा Referer के साथ होता है	पिछले श्रेणी पृष्ठ को निर्दिष्ट करें
Sec-Fetch-*	पूर्ण रूप से अनुपस्थित (ब्राउज़र क्लाइंट नहीं)	वास्तविक ब्राउज़र के DevTools से पूर्ण सेट की नकल करें

सबसे सरल तरीका है कि वास्तविक ब्राउज़र के DevTools में नेटवर्क टैब से पूर्ण हेडर सेट की नकल करें, आवश्यक पृष्ठ को मैन्युअल रूप से खोलें, और पार्सर में इसी सेट का उपयोग करें — यदि लाइब्रेरी इसकी अनुमति देती है तो हेडरों के अनुक्रम का ध्यान रखते हुए (उदाहरण के लिए, curl_cffi या httpx के साथ स्पष्ट क्रम)।

कारण 3: सत्र और कुकीज़ का घुमाव नहीं होना

एक गलती, जिसे अक्सर अनदेखा किया जाता है: पार्सर हर अनुरोध पर IP बदलता है, लेकिन एक ही कुकी सत्र का उपयोग करता है या कुकीज़ को बिल्कुल भी नहीं बचाता है। वास्तविक उपयोगकर्ता पहले दौरे पर कुकीज़ का एक सेट प्राप्त करता है (सत्र टोकन, डिवाइस पहचानकर्ता, क्लाउडफ्लेयर __cf_bm या ओज़ोन/WB के समान एंटीबॉट सुरक्षा के लेबल) और उन्हें सभी बाद के अनुरोधों में सत्र के भीतर उपयोग करता है।

यदि आप बिना कुकीज़ के अनुरोध भेजते हैं, जो "गर्म" पृष्ठ पर प्राप्त की गई हैं, तो एंटीबॉट सिस्टम "शून्य" सत्र देखता है — और यह तुरंत संदिग्ध है, विशेष रूप से API एंडपॉइंट्स को सीधे संबोधित करते समय, मुख्य पृष्ठ को बायपास करते हुए। समाधान — पूर्ण परिदृश्य का अनुकरण करना: पहले मुख्य पृष्ठ या श्रेणी पृष्ठ को लोड करें, कुकीज़ प्राप्त करें, 1-2 सेकंड प्रतीक्षा करें, और केवल फिर आवश्यक API या उत्पाद कार्ड को संबोधित करें, अनुरोधों की श्रृंखला के दौरान उसी सत्र में कुकीज़ को बनाए रखते हुए।

import requests

session = requests.Session()
session.headers.update({
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
    "Accept-Language": "ru-RU,ru;q=0.9"
})

# सत्र को गर्म करना
session.get("https://www.wildberries.ru/catalog/0/search.aspx")
time.sleep(1.5)

# अब कुकीज़ के साथ मुख्य अनुरोध
response = session.get(target_url)

यदि आप डॉल्फिन एंटी या एड्सपावर जैसे एंटी-डिटेक्ट ब्राउज़र का उपयोग कर रहे हैं ताकि मैन्युअल रूप से या अंतर्निहित स्वचालन के माध्यम से उत्पाद कार्ड की निगरानी करें, तो सुनिश्चित करें कि प्रोफ़ाइल सत्रों के बीच कुकीज़ को बचाती है और हर बार "साफ पृष्ठ" से शुरू नहीं होती है — यह भी सिस्टम का संदेह ट्रिगर करता है।

कारण 4: बॉट जैसी गतिविधि

यहां तक कि आदर्श हेडर और कुकीज़ के साथ भी, पार्सर अपने व्यवहार पैटर्न के कारण खुद को प्रकट कर सकता है: उत्पादों के लिए सख्त रैखिक क्रम (ID में वृद्धि के अनुसार), अनुरोधों के बीच समान अंतराल मिलीसेकंड तक, स्थैतिक पर "बकवास" अनुरोधों की अनुपस्थिति (चित्र, CSS, JS), जिन्हें सामान्य ब्राउज़र स्वचालित रूप से लोड करता है।

वाइल्डबेरीज़ और ओज़ोन की उन्नत सुरक्षा प्रणालियाँ केवल HTTP अनुरोधों का विश्लेषण नहीं करती हैं, बल्कि यह भी कि क्या पृष्ठ पर जावास्क्रिप्ट निष्पादित किया गया था (हेडलेस-डिटेक्शन के माध्यम से), क्या "माउस" चला था, क्या स्क्रॉल किया गया था। यदि आप बिना JS रेंडरिंग के शुद्ध HTTP अनुरोध करते हैं, और साइट टोकन प्राप्त करने के लिए स्क्रिप्ट के निष्पादन की अपेक्षा करती है (उदाहरण के लिए, एंटीबॉट-जावास्क्रिप्ट-चुनौती), तो इस स्क्रिप्ट के बिना अनुरोध स्वचालित रूप से 429 या 403 प्राप्त करता है।

समाधान पैमाने पर निर्भर करता है: छोटे वॉल्यूम के लिए, माउस की गति और यादृच्छिक विलंबता के अनुकरण के साथ हेडलेस ब्राउज़र (प्लेव्राइट, पपेटियर) का उपयोग करना उपयुक्त है। औद्योगिक पार्सिंग के लिए — उत्पादों के भ्रमण के क्रम को यादृच्छिक बनाना, प्राथमिक संसाधनों पर "शोर" अनुरोध जोड़ना, सामान्य वितरण के अनुसार समय के अंतराल में विविधता, न कि निश्चित चरण के अनुसार।

कारण 5: TLS/JA3 फ़िंगरप्रिंट और HTTP/2

यह सबसे "अदृश्य" तकनीकी कारण है, जिसके बारे में 90% लोग नहीं जानते हैं, जो बिना गहरे तकनीकी प्रशिक्षण के पार्सिंग कर रहे हैं। प्रत्येक TLS क्लाइंट (requests लाइब्रेरी, curl, urllib) HTTPS कनेक्शन स्थापित करते समय एक अद्वितीय फ़िंगरप्रिंट छोड़ता है — समर्थित एन्क्रिप्शन, प्रोटोकॉल के संस्करण, TLS एक्सटेंशन का सेट। इस फ़िंगरप्रिंट को JA3/JA4 फ़िंगरप्रिंट कहा जाता है।

एंटीबॉट सिस्टम स्तर के क्लाउडफ्लेयर, अकामाई और बड़े मार्केटप्लेस के अपने स्वयं के समाधान JA3 फ़िंगरप्रिंट की तुलना ज्ञात बॉट्स और लाइब्रेरी के डेटाबेस से करते हैं। मानक पायथन अनुरोध या नोड.जेएस HTTPS मॉड्यूल का फ़िंगरप्रिंट आसानी से पता लगाया जा सकता है, जो वास्तविक क्रोम के फ़िंगरप्रिंट से पूरी तरह भिन्न है। यहां तक कि आदर्श हेडर और कुकीज़ के साथ, अनुरोध वास्तव में TLS-हैंडशेक के स्तर पर ब्लॉक किया जाता है, इससे पहले कि सर्वर HTTP हेडर को देखे।

इसके अतिरिक्त, कई मार्केटप्लेस HTTP/2 की आवश्यकता होती है, जिसमें विशिष्ट पैरामीटर होते हैं (फ्रेम्स सेटिंग्स का क्रम, स्ट्रीम की प्राथमिकता) — HTTP/1.1 आधारित लाइब्रेरी इस पृष्ठभूमि में स्वचालित रूप से बाहर निकल जाती हैं। समाधान — लाइब्रेरी का उपयोग करना, जो वास्तविक ब्राउज़र के फ़िंगरप्रिंट का अनुकरण करती हैं: curl_cffi (क्रोम TLS फ़िंगरप्रिंट का अनुकरण करता है), tls-client, या पूर्ण हेडलेस ब्राउज़र जो क्रोमियम पर आधारित हैं, जो स्वाभाविक रूप से "वास्तविक" फ़िंगरप्रिंट प्रदान करते हैं।

pip install curl_cffi

उदाहरण: curl_cffi.requests.get(url, impersonate="chrome120") — लाइब्रेरी स्वचालित रूप से TLS फ़िंगरप्रिंट को वास्तविक क्रोम 120 के समान डालती है।

कारण 6: खाता या API कुंजी स्तर पर सीमा

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

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

इसे जांचना सरल है: यदि 429 तब भी जारी है जब आप एक नए IP से बिना किसी कुकी के अनुरोध करते हैं और पिछले सत्रों से कोई भी कुकी नहीं है, लेकिन आप एक सटे टैब में व्यक्तिगत खाते में लॉगिन कर चुके हैं — तो संभावना है कि सीमा वास्तव में खाते की है।

वास्तविक कारण का निदान कैसे करें

अवसंरचना को बदलने से पहले, निम्नलिखित एल्गोरिदम के अनुसार निदान करें। पहले सामान्य ब्राउज़र में पृष्ठ को मैन्युअल रूप से खोलें और सुनिश्चित करें कि 429 जीवित व्यवहार में उत्पन्न नहीं होती है — यह पुष्टि करेगा कि समस्या पार्सर की ओर है, न कि क्षेत्रीय वैश्विक ब्लॉक।

फिर अपने पार्सर के हेडर की तुलना वास्तविक ब्राउज़र के हेडर से करें DevTools के माध्यम से (नेटवर्क टैब → cURL के रूप में कॉपी करें)। यदि अंतर न्यूनतम है, तो TLS फ़िंगरप्रिंट की जांच करें tls.peet.ws जैसी सेवाओं के माध्यम से — अपनी लाइब्रेरी के माध्यम से अनुरोध भेजें और JA3 हैश को मानक ब्राउज़र के साथ तुलना करें। यदि अनुरोध TLS-हैंडशेक के चरण पर गिरता है (कनेक्शन HTTP उत्तर प्राप्त करने से पहले टूट जाता है) — तो कारण फ़िंगरप्रिंट में है, न कि आवृत्ति या हेडर में।

इसके बाद जांचें कि क्या सीमा IP या खाते से जुड़ी है: बिना प्रमाणीकरण के नए साफ IP से अनुरोध करें। यदि 429 गायब हो गया — समस्या पिछले IP की प्रतिष्ठा या उस पते से आवृत्ति में थी। यदि 429 बनी रही — तो हेडर, TLS या व्यवहार में कारण खोजें, न कि प्रॉक्सी में।

प्रॉक्सी बदले बिना 429 को ठीक करने की चेकलिस्ट

अनुरोधों के बीच 1-4 सेकंड की यादृच्छिक विलंबता जोड़ें, निश्चित अंतराल के बजाय।
वास्तविक ब्राउज़र के पूर्ण हेडर सेट की नकल करें, जिसमें Sec-Fetch-* और Accept-Language शामिल हैं।
एक ही सत्र के भीतर कुकीज़ को सहेजें और पास करें, मुख्य पृष्ठ को गर्म करने से शुरू करें।
अपनी लाइब्रेरी के TLS फ़िंगरप्रिंट की जांच करें — शुद्ध HTTP क्लाइंट के बजाय curl_cffi या हेडलेस ब्राउज़र का उपयोग करें।
पृष्ठों के भ्रमण के क्रम को यादृच्छिक बनाएं और स्थैतिक संसाधनों पर "शोर" अनुरोध जोड़ें।
API खाते और अनाम मूल्य निगरानी के लिए लोड को अलग करें।
429 प्राप्त करने पर एक्सपोनेंशियल बैकऑफ लागू करें, न कि अनुरोध का तात्कालिक पुनरावृत्ति।
ऊपर दिए गए सभी बिंदुओं की जांच करने के बाद ही — प्रॉक्सी बदलें या IP पूल का विस्तार करें।

कब प्रॉक्सी की आवश्यकता होती है और कौन सी चुनें

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

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

यदि कार्य मोबाइल साइट के संस्करण की जांच, मार्केटप्लेस ऐप के माध्यम से काम करना या TikTok Ads और Facebook Ads में शहर तक भूगोल की सटीकता के साथ विज्ञापन का परीक्षण करना है, तो मोबाइल प्रॉक्सी प्रासंगिक हैं — इनमें अधिकांश सुरक्षा प्रणालियों के लिए अधिकतम स्तर की विश्वसनीयता होती है, क्योंकि IP वास्तविक मोबाइल ऑपरेटरों के होते हैं।

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

प्रॉक्सी का प्रकार	कब 429 को हल करता है	कब मदद नहीं करेगा
रेसिडेंशियल	IP पहले से ही प्रतिष्ठा के कारण ब्लैकलिस्ट में है	TLS फ़िंगरप्रिंट या हेडर के कारण ब्लॉकिंग
मोबाइल	संवेदनशील परिदृश्यों के लिए IP की अधिकतम विश्वसनीयता की आवश्यकता है	सीमा खाते से जुड़ी है, IP से नहीं
डेटा सेंटर	बिना प्रमाणीकरण के खुले पृष्ठों की सरल पार्सिंग	कड़ी एंटीबॉट सिस्टम जो रेंज की प्रतिष्ठा की जांच करती हैं

निष्कर्ष

पार्सिंग में त्रुटि 429 को कभी भी "प्रॉक्सी बदलें" बटन के एक क्लिक से हल नहीं किया जा सकता। अधिकांश मामलों में, समस्या अनुरोधों की आवृत्ति, अधूरे हेडर, कुकी सत्र की अनुपस्थिति, पहचाने जाने योग्य TLS फ़िंगरप्रिंट, व्यवहार पैटर्न या सीमाओं में होती है, जो IP पते से नहीं, बल्कि खाते से जुड़ी होती हैं। इस लेख में दिए गए छह बिंदुओं के प्रत्येक पर निदान करें, इससे पहले कि आप प्रॉक्सी पूल का विस्तार करने के लिए बजट खर्च करें।

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