पार्सर स्थानीय रूप से काम करता है, लेकिन सर्वर पर बैन होता है: 7 कारण और इसे कैसे ठीक करें

क्लासिक स्थिति: Wildberries या Ozon पर कीमतों की निगरानी के लिए स्क्रिप्ट घरेलू लैपटॉप पर शानदार काम करती है, और VPS पर स्थानांतरित करने के बाद 403, कैप्चा या IP पर तात्कालिक बैन प्राप्त करना शुरू कर देती है। डेवलपर हेडर बदलता है, विलंब जोड़ता है - लेकिन परिणाम नहीं बदलता। समस्या लगभग कभी भी पार्सर के कोड में नहीं होती, बल्कि उस वातावरण में होती है जिससे यह अनुरोध करता है। हम 7 विशिष्ट कारणों का विश्लेषण करते हैं और बताते हैं कि पार्सर को सर्वर पर स्थिरता से काम करने के लिए क्या बदलना है।

क्यों स्थानीय रूप से सब कुछ काम करता है, जबकि सर्वर पर - बैन

जब आप अपने घरेलू कंप्यूटर से पार्सर चलाते हैं, तो साइट आपके प्रदाता के सामान्य आवासीय IP पते से अनुरोध देखती है, परिचित क्षेत्र से, वास्तविक ब्राउज़र वातावरण के साथ, यदि आप Selenium या Playwright का उपयोग कर रहे हैं। जैसे ही वही स्क्रिप्ट जर्मनी, नीदरलैंड या अमेरिका में VPS पर जाती है, दृश्य पूरी तरह से बदल जाता है: IP डेटा सेंटर का है, TLS-फिंगरप्रिंट लाइब्रेरी के अन्य संस्करण के कारण भिन्न हो सकता है, सर्वर का समय क्षेत्र IP की भू-स्थानिकता से मेल नहीं खाता है, और अनुरोधों की आवृत्ति अचानक बढ़ जाती है, क्योंकि सर्वर 24/7 बिना रुके काम करता है।

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

कारण 1: डेटा सेंटर का IP, आवासीय IP के बजाय

यह 80% मामलों में कारण नंबर 1 है। VPS और क्लाउड सर्वरों (AWS, DigitalOcean, Hetzner, सामान्य VDS-होस्टिंग) के IP पते डेटा सेंटर के डेटाबेस में होते हैं - इन प्रदाताओं का ASN सार्वजनिक रूप से ज्ञात है और एंटीबॉट सिस्टम द्वारा ट्रैफ़िक को तात्कालिक रूप से फ़िल्टर करने के लिए उपयोग किया जाता है। मार्केटप्लेस इन सूचियों का उपयोग पहले स्थान पर करते हैं, क्योंकि 95% स्वचालित पार्सिंग वास्तव में सर्वर के IP से आती है।

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

कारण 2: IP का रोटेशन और अनुरोधों की आवृत्ति की सीमा नहीं है

स्थानीय मशीन पर आप परीक्षण के दौरान 20-50 अनुरोध मैन्युअल रूप से करते हैं, और साइट इसे नहीं देखती। सर्वर पर स्क्रिप्ट हर 5 मिनट में क्रोन द्वारा चलती है और एक IP से लगातार हजारों उत्पाद कार्डों को संसाधित करती है। ऐसा पैटर्न एंटीबॉट सिस्टम के लिए सीधा संकेत है: वास्तविक व्यक्ति एक घंटे में बिना एक भी विराम के 3000 कैटलॉग पृष्ठ नहीं खोल सकता।

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

import requests

proxies_pool = [
    "http://user:[email protected]:9000",
    "http://user:[email protected]:9001",
    "http://user:[email protected]:9002",
]

def get_page(url, session_id):
    proxy = proxies_pool[session_id % len(proxies_pool)]
    resp = requests.get(
        url,
        proxies={"http": proxy, "https": proxy},
        headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"},
        timeout=10
    )
    return resp.text

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

कारण 3: हेडर और यूजर-एजेंट ब्राउज़र के समान नहीं हैं

कई पार्सर अनुरोधों या aiohttp पर न्यूनतम हेडर सेट के साथ या पुस्तकालय के मानक यूजर-एजेंट के साथ अनुरोध भेजते हैं, जो तुरंत स्क्रिप्ट को प्रकट करता है (उदाहरण के लिए python-requests/2.31.0)। स्थानीय मशीन पर ब्राउज़र के माध्यम से हेडर का सेट पूरा होता है: Accept, Accept-Language, Accept-Encoding, Sec-Ch-Ua, Referer और अन्य - उनका संयोजन स्वाभाविक लगता है।

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

कारण 4: TLS/JA3-फिंगरप्रिंट स्क्रिप्ट देता है

यह एक कम ज्ञात, लेकिन अत्यधिक सामान्य कारण है कि सर्वर पर बैन होता है। requests, urllib, aiohttp पुस्तकालय अपनी TLS-हैंडशेक कार्यान्वयन का उपयोग करते हैं, जो Chrome या Firefox में कार्यान्वयन से भिन्न होता है। एंटीबॉट सिस्टम JA3/JA4-TLS कनेक्शन के फिंगरप्रिंट की गणना करती हैं - और यह python-स्क्रिप्ट का फिंगरप्रिंट वास्तविक ब्राउज़र के फिंगरप्रिंट के समान नहीं होता, भले ही हेडर पूरी तरह से नकल किए गए हों।

समाधान - ऐसी पुस्तकालयों का उपयोग करना है जो ब्राउज़र के TLS-फिंगरप्रिंट की अनुकरण करते हैं (उदाहरण के लिए curl_cffi, tls-client Python में, या Playwright/Puppeteer के माध्यम से Chromium आधारित पूर्ण हेडलेस ब्राउज़र)। दूसरा विकल्प - शुद्ध HTTP-क्लाइंट के माध्यम से काम करने के बजाय, एंटी-डिटेक्ट उपकरण के साथ मिलकर प्रबंधित ब्राउज़र इंजन के माध्यम से काम करना है, जहां TLS और हेडर वास्तविक ब्राउज़र कोर द्वारा बनाए जाते हैं, न कि पुस्तकालय के अनुकरण द्वारा।

कारण 5: समय क्षेत्र, स्थानीयकरण और DNS सर्वर

यदि स्क्रिप्ट Selenium या Playwright के माध्यम से ब्राउज़र का अनुकरण करती है, तो एंटीबॉट सिस्टम सिस्टम के समय क्षेत्र, इंटरफेस की भाषा, DNS-रिज़ॉल्वर और यहां तक कि वास्तविक IP सर्वर के WebRTC लीक की जांच कर सकती है। फ्रैंकफर्ट के डेटा सेंटर में एक VPS जिसमें सिस्टम का समय क्षेत्र UTC और होस्टर का DNS प्रदाता है, जबकि यह मास्को से IP के साथ प्रॉक्सी का उपयोग करता है, भू-डेटा में स्पष्ट असंगति पैदा करता है - यह पहचान के लिए सबसे विश्वसनीय संकेतों में से एक है।

सभी पर्यावरण पैरामीटर - समय क्षेत्र, ब्राउज़र की भाषा, DNS, WebRTC द्वारा भू-स्थान - उस IP पते के क्षेत्र से मेल खाने चाहिए, जिसका उपयोग अनुरोध के लिए किया जा रहा है। इस कार्य को हल करने के लिए एंटी-डिटेक्ट ब्राउज़र बनाए गए हैं: Dolphin Anty, AdsPower, Multilogin, Octo Browser और GoLogin आपको प्रत्येक प्रॉक्सी के लिए अलग "ब्राउज़र प्रोफ़ाइल" सेट करने की अनुमति देते हैं, जहां स्वचालित रूप से समय क्षेत्र, स्थानीयकरण, स्क्रीन रिज़ॉल्यूशन और WebRTC को IP की भू-स्थान के अनुसार समायोजित किया जाता है।

कारण 6: अनुरोधों का पैटर्न बहुत "रोबोटिक" है

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

क्या बदलना है: यादृच्छिक विलंब जोड़ें (निश्चित 2 सेकंड नहीं, बल्कि 1.5 से 6 सेकंड तक का रैंडम), समय-समय पर मध्यवर्ती पृष्ठों पर जाएं (श्रेणी → कार्ड, न कि API के लिए सीधे अनुरोध), हेडलेस ब्राउज़र के माध्यम से काम करते समय स्क्रॉल और माउस की गति का अनुकरण करें। यह डेटा संग्रह के समय को बढ़ाता है, लेकिन बैन की संख्या को तेजी से कम करता है।

कारण 7: सत्र और कुकीज़ अनुरोधों के बीच नहीं बचती हैं

अक्सर सर्वर पर पार्सर प्रत्येक अनुरोध के लिए एक नई अनुरोध सत्र बनाता है - बिना कुकीज़, बिना सहेजे गए प्रमाणीकरण टोकन, बिना विज़िट इतिहास के। मार्केटप्लेस जैसे Wildberries और Ozon पहले प्रवेश पर अस्थायी कुकीज़ और टोकन जारी करते हैं, और उनके बिना आगे के अनुरोध संदिग्ध लगते हैं, जैसे कि प्रत्येक अनुरोध एक नए अज्ञात आगंतुक द्वारा किया गया हो।

सही योजना: एक सत्र (requests.Session() या ब्राउज़र का संदर्भ) - एक IP से प्रॉक्सी पूल पर, इस IP के लिए अनुरोधों की पूरी श्रृंखला के दौरान कुकीज़ को सहेजना। प्रॉक्सी बदलने पर, नए उपयोगकर्ता का अनुकरण करते हुए नए कुकीज़ के साथ एक नया सत्र शुरू करना आवश्यक है, न कि नए IP के साथ पुराने कुकीज़ का उपयोग करना - यह भी असंगति पैदा करता है और बैन को ट्रिगर करता है।

चेकलिस्ट: क्रम में क्या बदलना है

यदि पार्सर सर्वर पर स्थिरता से बैन हो जाता है, लेकिन स्थानीय रूप से काम करता है, तो इस क्रम में परिवर्तनों की जांच करें - इससे आप जल्दी से कारण खोज पाएंगे:

चरण	क्या जांचें	क्या बदलें
1	सर्वर का IP प्रकार	सीधे होस्टिंग IP के बजाय आवासीय प्रॉक्सी पर जाएं
2	अनुरोधों की आवृत्ति	IP रोटेशन और पते पर अनुरोधों की सीमा लागू करें
3	अनुरोध हेडर	वास्तविक ब्राउज़र के पूर्ण हेडर सेट की नकल करें
4	TLS-फिंगरप्रिंट	शुद्ध अनुरोध के बजाय curl_cffi / हेडलेस ब्राउज़र का उपयोग करें
5	समय क्षेत्र और स्थानीयकरण	Dolphin Anty / AdsPower में IP क्षेत्र के लिए प्रोफ़ाइल सेट करें
6	व्यवहार का पैटर्न	विलंब को यादृच्छिक बनाएं, मध्यवर्ती पृष्ठ जोड़ें
7	सत्र और कुकीज़	पूरे अनुरोध चक्र के लिए एक IP से एक सत्र को जोड़ें

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

निष्कर्ष

सर्वर पर पार्सर का बैन स्थानीय संस्करण के काम करने से लगभग हमेशा स्क्रिप्ट की लॉजिक से नहीं, बल्कि वातावरण से संबंधित होता है: IP का प्रकार, TLS-फिंगरप्रिंट, हेडर, समय क्षेत्र, अनुरोधों का पैटर्न और सत्र प्रबंधन। 7 कारणों में से प्रत्येक की जांच करके - सबसे सामान्य (डेटा सेंटर का IP) से लेकर सबसे अदृश्य (समय क्षेत्र और IP क्षेत्र का असंगति) तक - आप डेटा संग्रह के मुख्य व्यावसायिक लॉजिक को बदले बिना पार्सर के स्थिर काम को पुनर्स्थापित कर सकते हैं।

यदि आप Wildberries, Ozon या Avito पर औद्योगिक मात्रा में कीमतें और स्टॉक इकट्ठा कर रहे हैं, तो IP बदलने से शुरू करें: आवासीय प्रॉक्सी का प्रयास करें, मानक VPS पते के बजाय - अधिकांश मामलों में यह 70% से अधिक ब्लॉकों को समाप्त करता है इससे पहले कि आप हेडर और TLS-फिंगरप्रिंट सेट करना शुरू करें।