विक्रेता रात में प्रतिस्पर्धियों की कीमतों के लिए पार्सर शुरू करता है, और सुबह उसे सूचना मिलती है: ट्रैफ़िक समाप्त हो गया है, पैकेज 90% समाप्त हो गया है। क्या यह एक परिचित स्थिति है? अक्सर समस्या पार्सर में नहीं होती, बल्कि प्रॉक्सी और स्क्रिप्ट के स्तर पर सीमाओं की अनुपस्थिति होती है। इस लेख में हम समझेंगे कि ट्रैफ़िक कैसे "बह जाता है", और सुरक्षा कैसे स्थापित करें ताकि महीने का निवासी या मोबाइल प्रॉक्सी पैकेज गणना की गई अवधि के अंत तक पर्याप्त हो।
ट्रैफ़िक रात में क्यों समाप्त होता है
Wildberries, Ozon या Avito की पार्सिंग एक सरल कार्य की तरह लगती है: एक अनुरोध भेजा — कीमत के साथ JSON प्राप्त किया। लेकिन व्यवहार में, ट्रैफ़िक केवल उपयोगी डेटा पर खर्च नहीं होता। अधिकतर ओवरस्पेंडिंग के स्रोत:
- छवियों और मीडिया का लोड होना। यदि पार्सर ब्राउज़र के माध्यम से उत्पाद पृष्ठ को पूरी तरह से खोलता है (और API को सीधे अनुरोध नहीं करता), तो यह स्वचालित रूप से चित्र, वीडियो, बैनर लोड करता है — यह एक कार्ड के लिए दर्जनों मेगाबाइट है।
- कैप्चा और ब्लॉकों के कारण पुनरावृत्त अनुरोध। मार्केटप्लेस बॉट को पहचानता है, कैप्चा या IP का अस्थायी बैन देता है, स्क्रिप्ट पुनरावृत्त अनुरोध करती है — ट्रैफ़िक व्यर्थ में खर्च होता है, और डेटा नहीं आता।
- अनुरोधों का कैशिंग का अभाव। बिना "इस घंटे में पहले से पार्स किया गया है — दोहराना नहीं" की लॉजिक के, स्क्रिप्ट एक ही कार्ड को रात में कई बार पूछ सकती है।
- बिना सीमा के समानांतर धाराएँ। 50-100 धाराओं को एक साथ चलाना काम को तेज़ करने जैसा लगता है, लेकिन इस दौरान ट्रैफ़िक अपेक्षा से कई गुना तेजी से खर्च होता है, और कुछ अनुरोध बस ब्लॉक हो जाते हैं।
- प्रॉक्सी के प्रकार का गलत चयन। निवासी और मोबाइल प्रॉक्सी आमतौर पर ट्रैफ़िक के मात्रा (GB) के अनुसार चार्ज किए जाते हैं, जबकि डेटा सेंटर प्रॉक्सी में अक्सर IP की संख्या या किराए के समय के लिए भुगतान होता है। यदि पार्सर बिना नियंत्रण के निवासी पूल पर सेट है — सीमा जल्दी समाप्त हो जाती है।
इन कारकों का संयोजन इस बात की ओर ले जाता है कि एक महीने के काम के लिए निर्धारित स्क्रिप्ट एक रात की पार्सिंग सत्र में 10-20 हजार उत्पाद कार्ड का ट्रैफ़िक खर्च कर देती है।
विभिन्न प्रकार की प्रॉक्सी में ट्रैफ़िक कैसे गिना जाता है
सीमाएँ निर्धारित करने से पहले, यह समझना महत्वपूर्ण है कि आप वास्तव में किस चीज़ के लिए भुगतान कर रहे हैं। विभिन्न प्रकार की प्रॉक्सी विभिन्न तरीकों से खपत को गिनती हैं, और यह सीधे बचत की रणनीति को प्रभावित करता है।
| प्रॉक्सी का प्रकार | टैरिफ़ | ओवरस्पेंडिंग का जोखिम | कब लागू करें |
|---|---|---|---|
| निवासी प्रॉक्सी | ट्रैफ़िक के मात्रा (GB) के अनुसार | सीमाओं के बिना उच्च | मार्केटप्लेस की एंटी-बॉट सुरक्षा को बायपास करते हुए पार्सिंग |
| मोबाइल प्रॉक्सी | ट्रैफ़िक के मात्रा या समय के अनुसार | उच्च, ट्रैफ़िक महंगा है | साइटों के मोबाइल संस्करणों की पार्सिंग, कठोर ब्लॉकों को बायपास करना |
| डेटा सेंटर प्रॉक्सी | IP की संख्या / किराए के समय के अनुसार | कम, ट्रैफ़िक आमतौर पर बिना सीमा के होता है | कठोर एंटी-बॉट सुरक्षा के बिना बड़े पैमाने पर पार्सिंग |
यदि आप Wildberries या Ozon की पार्सिंग कर रहे हैं, जहाँ बॉट सुरक्षा सक्रिय है, तो निवासी या मोबाइल IP लगभग हमेशा आवश्यक होते हैं — डेटा सेंटर के पते जल्दी ब्लॉक हो जाते हैं। लेकिन यहाँ ट्रैफ़िक के अनुसार टैरिफ़ के कारण, पहले से सीमाएँ निर्धारित करना विशेष रूप से महत्वपूर्ण है।
पार्सिंग के लिए वास्तव में कितना ट्रैफ़िक आवश्यक है
उचित सीमा निर्धारित करने के लिए, वास्तविक आंकड़ों से शुरू करना आवश्यक है, न कि भावनाओं से। व्यावहारिक रूप से अनुमानित खर्च:
- उत्पाद कार्ड के लिए API अनुरोध (JSON, बिना चित्र): 5-30 KB प्रति कार्ड। 10,000 कार्ड पर — लगभग 50-300 MB।
- छवियों के साथ हेडलेस ब्राउज़र के माध्यम से उत्पाद पृष्ठ का लोड होना: 1-3 MB प्रति कार्ड। उन 10,000 कार्डों पर — 10-30 GB।
- 1000 SKU के लिए प्रति घंटे मूल्य की निगरानी: हल्के अनुरोधों पर — प्रति दिन लगभग 1-5 GB, पूर्ण पृष्ठ लोड होने पर — प्रति दिन 50-100 GB।
"हल्के" और "भारी" पार्सिंग के बीच का अंतर कई गुना है। इसलिए ट्रैफ़िक की बचत का पहला कदम है जहाँ संभव हो, छवियों, वीडियो और बाहरी स्क्रिप्टों का लोड बंद करना, और मार्केटप्लेस के API या मोबाइल संस्करण के साथ सीधे काम करना, जो डेस्कटॉप की तुलना में कम वजन करता है।
एंटी-डिटेक्ट ब्राउज़रों और प्रॉक्सी प्रबंधकों में सीमाएँ
उन लोगों के लिए जो एंटी-डिटेक्ट ब्राउज़र (जैसे, Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) या अपने स्वयं के प्रॉक्सी प्रबंधक के माध्यम से पार्सिंग कर रहे हैं, खपत को सीमित करने का सबसे सरल तरीका है प्रॉक्सी प्रदाता के प्रोफ़ाइल और खाता स्तर पर सीमाएँ सेट करना।
- प्रॉक्सी प्रदाता के व्यक्तिगत खाते में लॉग इन करें और ट्रैफ़िक या उप-उपयोगकर्ताओं/पोर्ट्स के लिए सीमाओं के प्रबंधन अनुभाग को खोजें।
- पार्सिंग के लिए एक अलग उप-खाता या पोर्ट बनाएं — Instagram या TikTok में खाता फार्मिंग के लिए उपयोग किए जाने वाले प्रॉक्सी पूल का उपयोग न करें। कार्यों के अनुसार विभाजन तुरंत दिखाता है कि ट्रैफ़िक कहाँ जा रहा है।
- इस उप-खाते पर ट्रैफ़िक के लिए दैनिक या घंटे की सीमा निर्धारित करें — उदाहरण के लिए, एक सत्र में पूरे महीने के पैकेज के बजाय प्रति दिन 5 GB।
- एंटी-डिटेक्ट ब्राउज़र में उन प्रोफाइलों के लिए छवियों का ऑटो-लोड बंद करें, जो केवल डेटा संग्रह के लिए उपयोग किए जाते हैं, न कि पृष्ठों के दृश्य अवलोकन के लिए।
- प्रोफाइल के लॉन्च का कार्यक्रम सेट करें ताकि पार्सिंग एक लंबे सत्र में न हो, बल्कि छोटे अंतराल में विराम के साथ हो — यह ब्लॉक होने के जोखिम को कम करता है और लॉन्च के बीच ट्रैफ़िक की खपत को ट्रैक करने का समय देता है।
यह दृष्टिकोण विशेष रूप से उन एजेंसियों और फ्रीलांसरों के लिए महत्वपूर्ण है, जो एक साथ कई मार्केटप्लेस की पार्सिंग कर रहे हैं: उप-खातों के बिना यह समझना मुश्किल है कि कौन सा प्रोजेक्ट "ट्रैफ़िक खा रहा है"।
स्क्रिप्ट और API के स्तर पर ट्रैफ़िक की सीमा
यदि पार्सर स्वयं Python या Node.js पर लिखा गया है, तो सीमाएँ सीधे कोड में शामिल की जा सकती हैं — यह प्रॉक्सी प्रदाता के इंटरफ़ेस की सेटिंग्स की तुलना में अधिक सटीक नियंत्रण देता है।
requests का उपयोग करते हुए Python में ट्रैफ़िक की एक सरल काउंटर का उदाहरण:
import requests
MAX_BYTES_PER_DAY = 5 * 1024 * 1024 * 1024 # दैनिक सीमा 5 GB
used_bytes = 0
proxies = {
"http": "http://user:pass@proxy_host:port",
"https": "http://user:pass@proxy_host:port",
}
def safe_get(url):
global used_bytes
if used_bytes >= MAX_BYTES_PER_DAY:
raise RuntimeError("दैनिक ट्रैफ़िक सीमा समाप्त हो गई है, पार्सिंग रोक दी गई है")
response = requests.get(url, proxies=proxies, timeout=10)
used_bytes += len(response.content)
return response
# कॉल का उदाहरण
resp = safe_get("https://card.wb.ru/cards/detail?nm=123456")
print("उपयोग किया गया ट्रैफ़िक:", round(used_bytes / 1024 / 1024, 2), "MB")
लॉजिक सरल है: स्क्रिप्ट प्रत्येक उत्तर के आकार को बाइट्स में गिनती है और जब निर्धारित सीमा तक पहुँच जाती है, तो रुक जाती है। यह उस स्थिति से बचाता है, जब एक लूप या अनंत पुनरावृत्ति के कारण स्क्रिप्ट "एक महीने का ट्रैफ़िक पैकेज" कुछ घंटों में समाप्त कर देती है।
इसके अलावा, यह जोड़ने के लिए उचित है:
- त्रुटियों पर एक्सपोनेंशियल डिले (retry with backoff) — कैप्चा या बैन पर अनुरोध को तुरंत पुनरावृत्त करने के बजाय, स्क्रिप्ट एक बढ़ते अंतराल (5 सेकंड, 15 सेकंड, 60 सेकंड) का इंतजार करती है, जो बेकार अनुरोधों की संख्या को कम करता है।
- समानांतर धाराओं की संख्या को सीमित करना — उदाहरण के लिए, प्रॉक्सी पूल के माध्यम से 10-20 समवर्ती कनेक्शनों से अधिक नहीं, ताकि ब्लॉकों को उत्तेजित न करें और व्यर्थ में ट्रैफ़िक खर्च न करें।
- हेडलेस ब्राउज़र में संसाधनों का लोड बंद करना — यदि पार्सिंग Selenium या Puppeteer के माध्यम से हो रही है, तो ब्राउज़र की सेटिंग्स में चित्रों, फ़ॉन्टों और CSS के लोड को अवरुद्ध किया जा सकता है, केवल HTML/JSON उत्तर छोड़कर।
वास्तविक समय में खपत की निगरानी
बिना निगरानी के सीमा कम प्रभावी होती है, क्योंकि आप समस्या के बारे में केवल स्क्रिप्ट के रुकने के बाद ही जानते हैं। खपत को तुरंत नियंत्रित करने के लिए:
- प्रॉक्सी प्रदाता के व्यक्तिगत खाते में 50%, 80% और 100% महीने के ट्रैफ़िक पैकेज की उपलब्धता के लिए सूचनाएँ चालू करें — अधिकांश सेवाएँ ईमेल या Telegram पर ऐसे अलर्ट का समर्थन करती हैं।
- स्क्रिप्ट में एक सरल लॉग रखें: फ़ाइल या डेटाबेस में प्रति घंटे ट्रैफ़िक की मात्रा रिकॉर्ड करें, ताकि आप खपत के पीक देख सकें और समस्या के स्रोत को जल्दी से खोज सकें।
- उप-खातों या लेबलों के माध्यम से कार्यों के अनुसार ट्रैफ़िक को विभाजित करें — Wildberries के लिए अलग, Ozon के लिए अलग, Avito के लिए अलग। यह विश्लेषण को सरल बनाता है, कि कौन सा प्रोजेक्ट सबसे अधिक खर्च कर रहा है।
- उम्मीदित डेटा की मात्रा के साथ खपत की तुलना करें: यदि 10,000 कार्डों पर 20 GB खर्च हुए हैं, जबकि गणना की गई 300 MB है, तो इसका मतलब है कि कहीं अतिरिक्त संसाधन लोड हो रहे हैं या पुनरावृत्त अनुरोध हो रहे हैं।
ट्रैफ़िक बजट की निगरानी के लिए चेकलिस्ट
- पार्सिंग के लिए प्रोफाइल पर छवियों और वीडियो का ऑटो-लोड बंद है
- जहाँ संभव हो, पृष्ठ के पूर्ण लोड के बजाय मार्केटप्लेस के API के लिए सीधे अनुरोध का उपयोग किया जाता है
- प्रॉक्सी के उप-खाते पर दैनिक या घंटे की ट्रैफ़िक सीमा निर्धारित की गई है
- पार्सिंग को प्रोजेक्ट्स (Wildberries, Ozon, Avito) के लिए अलग-अलग प्रॉक्सी पूल में विभाजित किया गया है
- स्क्रिप्ट में ट्रैफ़िक काउंटर लागू किया गया है जो सीमा तक पहुँचने पर रुक जाता है
- कैप्चा या ब्लॉक पर तुरंत पुनरावृत्ति के बजाय डिले और बैकऑफ सेट किया गया है
- पार्सिंग के समानांतर धाराओं की संख्या सीमित है
- प्रॉक्सी प्रदाता से ट्रैफ़िक खपत के लिए सूचनाएँ चालू की गई हैं
- विश्लेषण के लिए खपत के लॉग को प्रति घंटे रखा गया है
नवागंतुकों की सामान्य गलतियाँ
व्यवहार में, अधिकांश "खत्म" ट्रैफ़िक पैकेज कुछ सामान्य गलतियों के कारण होते हैं:
- सीमाओं के बिना "निगरानी के बिना रात में पार्सिंग शुरू करना।" स्क्रिप्ट 8-10 घंटे बिना रुके काम करती है, और यदि कहीं पुनरावृत्ति के अनुरोध का लूप उत्पन्न होता है, तो ट्रैफ़िक सुबह तक निरंतर खर्च होता है।
- सभी कार्यों के लिए एक सामान्य प्रॉक्सी पूल। Instagram में खाता फार्मिंग, Facebook Ads में विज्ञापन परीक्षण और Ozon की पार्सिंग एक ही ट्रैफ़िक का उपयोग करते हैं — यह समझना असंभव है कि वास्तव में क्या खर्च हो रहा है।
- कैप्चा की अनदेखी। कैप्चा के पहले संकेतों पर अनुरोधों की आवृत्ति को कम करने के बजाय, स्क्रिप्ट उसी तीव्रता से साइट पर हमला करना जारी रखती है, बेकार उत्तरों पर ट्रैफ़िक खर्च करती है।
- जहाँ डेटा सेंटर प्रॉक्सी पर्याप्त हैं, वहाँ निवासी प्रॉक्सी का चयन। यदि मार्केटप्लेस डेटा सेंटर IP को कठोरता से ब्लॉक नहीं करता है, तो निवासी पूल के लिए ट्रैफ़िक का अधिक भुगतान उचित नहीं है — कम सुरक्षित लक्ष्यों के लिए डेटा सेंटर प्रॉक्सी उपयुक्त हैं, जिनका टैरिफ़ मॉडल अलग है।
- परीक्षण रन की अनुपस्थिति। हजारों कार्डों पर पूर्ण पार्सिंग शुरू करने से पहले, स्क्रिप्ट को 50-100 कार्डों पर चलाना उचित है और वास्तविक ट्रैफ़िक खपत को मापना, ताकि इसे पूरे वॉल्यूम पर एक्सट्रपोल किया जा सके।
निष्कर्ष
पार्सिंग के लिए ट्रैफ़िक "खत्म" नहीं होता है, बल्कि नियंत्रण की अनुपस्थिति के कारण होता है: अनावश्यक चित्र, ब्लॉकों पर पुनरावृत्त अनुरोध, बिना सीमाओं के समानांतर धाराएँ और सभी कार्यों के लिए सामान्य प्रॉक्सी पूल। समाधान है ट्रैफ़िक को प्रोजेक्ट्स के अनुसार विभाजित करना, प्रॉक्सी खाते के स्तर पर दैनिक सीमाएँ निर्धारित करना, स्क्रिप्ट में खपत की काउंटर को शामिल करना और सूचनाओं के साथ निगरानी सेट करना, जब तक पैकेज वास्तव में समाप्त न हो जाए।
यदि आप Wildberries या Ozon जैसी सक्रिय बॉट सुरक्षा वाले मार्केटप्लेस की पार्सिंग कर रहे हैं, तो हम अनुशंसा करते हैं कि आप निवासी प्रॉक्सी का उपयोग करें ताकि ब्लॉकों को बायपास किया जा सके और इसके अलावा मोबाइल IP का उपयोग करें सबसे संवेदनशील एंटी-बॉट सुरक्षा परिदृश्यों के लिए — लेकिन दोनों मामलों में, ट्रैफ़िक सीमाएँ पहले से निर्धारित करना सुनिश्चित करें, ताकि महीने का पैकेज एक रात के सत्र में समाप्त न हो जाए।