आईपी एड्रेस रोटेशन: प्रॉक्सी कैसे बदलें और क्यों

अनुरोध 1 → प्रॉक्सी A (185.45.12.34) → साइट देखती है 185.45.12.34
अनुरोध 2 → प्रॉक्सी B (92.118.45.78) → साइट देखती है 92.118.45.78
अनुरोध 3 → प्रॉक्सी C (178.62.91.22) → साइट देखती है 178.62.91.22
अनुरोध 4 → प्रॉक्सी A (185.45.12.34) → साइट देखती है 185.45.12.34

1. रेट लिमिटिंग (अनुरोध सीमाओं) को बायपास करना

अधिकांश वेबसाइटें प्रति यूनिट समय में एक आईपी से अनुरोधों की संख्या को सीमित करती हैं। उदाहरण के लिए, एक एपीआई प्रति घंटे एक आईपी से केवल 100 अनुरोधों की अनुमति दे सकता है। 10 आईपी के रोटेशन पूल का उपयोग करके, आप लोड को वितरित करके प्रति घंटे 1,000 अनुरोध भेज सकते हैं।

2. डेटा पार्सिंग के दौरान आईपी बैन से बचना

बड़ी मात्रा में डेटा एकत्र करते समय (ई-कॉमर्स पार्सिंग, मूल्य निगरानी, संपर्क एकत्र करना), एक ही आईपी से लगातार अनुरोध करने पर जल्दी ही आईपी ब्लॉक हो जाता है। रोटेशन अनुरोधों को इस तरह वितरित करने की अनुमति देता है कि प्रत्येक आईपी प्रति घंटे केवल कुछ ही अनुरोध करे—ठीक एक सामान्य उपयोगकर्ता की तरह।

3. भौगोलिक अवरोधों को बायपास करना

कई सेवाएं स्थान के आधार पर अलग सामग्री या कीमतें दिखाती हैं। विभिन्न देशों के प्रॉक्सी का उपयोग करके, आप भौतिक रूप से वहां मौजूद हुए बिना सभी क्षेत्रों से डेटा एकत्र कर सकते हैं।

4. स्वचालन को छिपाना

सुरक्षा प्रणालियाँ (Cloudflare, Akamai, PerimeterX) व्यवहार पैटर्न का विश्लेषण करती हैं। यदि कम समय में एक ही आईपी से सैकड़ों अनुरोध आते हैं, तो यह बॉट का स्पष्ट संकेत है। रोटेशन कई स्वतंत्र उपयोगकर्ताओं का भ्रम पैदा करने में मदद करता है।

5. प्रतिस्पर्धी खुफिया जानकारी

प्रतिस्पर्धियों की कीमतों पर नज़र रखना, विज्ञापन अभियानों की निगरानी करना, एसईओ स्थिति का विश्लेषण करना—इन सबमें बार-बार जाँच की आवश्यकता होती है। आईपी रोटेशन इन डेटा को बिना किसी का ध्यान आकर्षित किए एकत्र करने की अनुमति देता है।

6. परीक्षण और निगरानी

विभिन्न क्षेत्रों से वेबसाइट की उपलब्धता की जाँच करना, ए/बी प्रयोगों का परीक्षण करना, विभिन्न देशों में एसईओ स्थितियों की निगरानी करना—इन सभी के लिए विभिन्न स्थानों से आईपी पतों का उपयोग करने की आवश्यकता होती है।

1. रेट लिमिटिंग (अनुरोध आवृत्ति का विश्लेषण)

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

• रूढ़िवादी वेबसाइटें: 10-30 अनुरोध प्रति मिनट
• औसत वेबसाइटें: 50-100 अनुरोध प्रति मिनट
• एपीआई सेवाएँ: 100-1000 अनुरोध प्रति घंटा (अक्सर दस्तावेज़ीकरण में निर्दिष्ट)

2. आईपी प्रतिष्ठा विश्लेषण

विस्तृत डेटाबेस मौजूद हैं जो आईपी पतों को प्रकारों के अनुसार वर्गीकृत करते हैं:

• आवासीय आईपी (Residential IP) — घरेलू इंटरनेट प्रदाता (उच्च प्रतिष्ठा)
• डेटासेंटर आईपी (Datacenter IP) — होस्टिंग कंपनियों के सर्वर (संदिग्ध)
• मोबाइल आईपी (Mobile IP) — मोबाइल ऑपरेटर (उच्च प्रतिष्ठा)
• ज्ञात प्रॉक्सी आईपी (Known proxy IP) — ज्ञात प्रॉक्सी सर्वर (अक्सर ब्लॉक किए जाते हैं)

3. ब्राउज़र फ़िंगरप्रिंटिंग

आईपी बदलने पर भी, सुरक्षा प्रणालियाँ ब्राउज़र के अद्वितीय "फ़िंगरप्रिंट" द्वारा अनुरोधों को जोड़ सकती हैं: स्क्रीन रिज़ॉल्यूशन, स्थापित फ़ॉन्ट, प्लगइन्स, WebGL फ़िंगरप्रिंट, कैनवास फ़िंगरप्रिंट, ऑडियो कॉन्टेक्स्ट फ़िंगरप्रिंट।

4. व्यवहार विश्लेषण

आधुनिक एंटी-बॉट सिस्टम व्यवहार का विश्लेषण करते हैं:

• पेज स्क्रॉलिंग की गति
• माउस की गतिविधियाँ
• क्लिक पैटर्न
• कार्यों के बीच का समय
• पेज विज़िट का क्रम

5. टीएलएस फ़िंगरप्रिंटिंग

एचटीटीपीएस कनेक्शन के दौरान, सर्वर टीएलएस संस्करण, उपयोग किए गए सिफर सूट, एक्सटेंशन—ये डेटा एक अद्वितीय फ़िंगरप्रिंट बनाते हैं जिसका उपयोग आईपी बदलने पर भी ट्रैक करने के लिए किया जा सकता है।

रोटेशन के विशिष्ट अंतराल:

• हर 5 मिनट — उच्च अनुरोध आवृत्ति वाले गहन पार्सिंग के लिए
• हर 10-15 मिनट — अधिकांश कार्यों के लिए मानक मोड
• हर 30-60 मिनट — कम आवृत्ति वाले कार्यों के लिए
• हर 2-24 घंटे — स्टिकी सत्रों (sticky sessions) के लिए
• हर 2-24 घंटे — स्टिकी सत्रों (sticky sessions) के लिए

✅ फायदे:

• पूर्वानुमेयता — आप ठीक जानते हैं कि आईपी कब बदलेगा
• कार्यान्वयन में आसानी — टाइमर का उपयोग करके सेट करना आसान है
• स्टिकी सत्रों के लिए उपयुक्त — एक निश्चित समय के लिए आईपी बनाए रख सकते हैं
• समय के साथ समान वितरण — लोड समय के साथ समान रूप से वितरित होता है
• स्केलेबल — विभिन्न टाइमर के साथ कई सत्र समानांतर में चलाए जा सकते हैं

❌ नुकसान:

• परिवर्तनशील लोड के लिए अक्षमता — यदि अनुरोध कम हैं, तो आईपी अनावश्यक रूप से बदल जाता है
• सीमाओं को पार करने का जोखिम — यदि कम अंतराल में बहुत सारे अनुरोध भेजे जाते हैं
• अनुमानित पैटर्न — उन्नत सुरक्षा प्रणालियाँ नियमितता का पता लगा सकती हैं
• सत्र का नुकसान — आईपी बदलने पर प्रमाणीकरण या संदर्भ खो सकता है

🎯 किसके लिए सबसे उपयुक्त:

• पूर्वानुमेय लोड वाले कार्य
• लंबे सत्र (प्रमाणीकरण, खाता प्रबंधन)
• निश्चित अंतराल पर निगरानी
• ऐसी स्थितियाँ जहाँ एक निश्चित समय के लिए आईपी की स्थिरता महत्वपूर्ण है

10:00 - प्रॉक्सी A → कीमतों की जाँच (50 उत्पाद)
10:30 - प्रॉक्सी B → कीमतों की जाँच (50 उत्पाद)
11:00 - प्रॉक्सी C → कीमतों की जाँच (50 उत्पाद)
11:30 - प्रॉक्सी D → कीमतों की जाँच (50 उत्पाद)
12:00 - प्रॉक्सी A → कीमतों की जाँच (50 उत्पाद)

कार्यान्वयन के विकल्प:

1. प्रति-अनुरोध रोटेशन — प्रत्येक अनुरोध के लिए नया आईपी (सबसे आक्रामक रणनीति)
2. बर्स्ट रोटेशन — N अनुरोधों के बाद आईपी बदलना (उदाहरण के लिए, हर 10 अनुरोध के बाद)
3. अनुकूली रोटेशन — विशिष्ट HTTP कोड (429, 403, 503) प्राप्त होने पर आईपी बदलना
4. सत्र-आधारित — नया तार्किक सत्र शुरू होने पर आईपी बदलना

✅ फायदे:

• रेट लिमिटिंग से अधिकतम सुरक्षा — प्रत्येक आईपी न्यूनतम अनुरोध करता है
• अनुकूलनशीलता — रोटेशन केवल तभी होता है जब आवश्यक हो
• पूल का प्रभावी उपयोग — आईपी केवल तभी बदलते हैं जब उनकी आवश्यकता होती है
• अवरोधों पर त्वरित प्रतिक्रिया — त्रुटि मिलने पर तुरंत आईपी बदला जा सकता है
• पार्सिंग के लिए आदर्श — प्रत्येक पृष्ठ एक नए आईपी से अनुरोधित होता है

❌ नुकसान:

• सत्र बनाए रखने में असमर्थता — लगातार आईपी बदलने से प्रमाणीकरण टूट जाता है
• डीबग करना कठिन — किसी विशिष्ट आईपी के साथ समस्या को दोहराना मुश्किल है
• पूल की तेजी से समाप्ति — गहन कार्य के दौरान सभी आईपी का उपयोग जल्दी हो सकता है
• अधिक महंगा — प्रभावी ढंग से काम करने के लिए प्रॉक्सी के बड़े पूल की आवश्यकता होती है
• स्विचिंग पर ओवरहेड — प्रत्येक आईपी परिवर्तन में कुछ सेकंड का समय लगता है

🎯 किसके लिए सबसे उपयुक्त:

• बड़ी मात्रा में डेटा का गहन पार्सिंग
• कठोर दर सीमाओं को बायपास करना
• एकल अनुरोध जो स्थिति बनाए रखने की आवश्यकता नहीं रखते हैं
• बिना प्रमाणीकरण के सार्वजनिक पृष्ठों की पार्सिंग
• ऐसे कार्य जहाँ प्रत्येक अनुरोध पिछले से स्वतंत्र हो

साइट का प्रकार	अनुशंसित अनुरोधों की संख्या	अंतराल
अत्यधिक सुरक्षित (बैंक, सोशल मीडिया)	1-3 अनुरोध	अनुरोधों के बीच 5-10 सेकंड
ई-कॉमर्स (मार्केटप्लेस)	5-10 अनुरोध	अनुरोधों के बीच 2-5 सेकंड
समाचार पोर्टल	10-20 अनुरोध	अनुरोधों के बीच 1-3 सेकंड
सार्वजनिक एपीआई	एपीआई सीमाओं पर निर्भर करता है	दस्तावेज़ीकरण के अनुसार
स्थिर वेबसाइटें	20-50 अनुरोध	अनुरोधों के बीच 0.5-2 सेकंड

यादृच्छिक रोटेशन के प्रकार:

• यादृच्छिक समय अंतराल — आईपी बदलना यादृच्छिक अंतराल पर (उदाहरण के लिए, 3 से 15 मिनट के बीच)
• यादृच्छिक अनुरोध गणना — यादृच्छिक संख्या में अनुरोधों के बाद बदलना (उदाहरण के लिए, 5 से 20 के बीच)
• यादृच्छिक आईपी चयन — पूल से अगले आईपी का चयन क्रम से नहीं, बल्कि यादृच्छिक रूप से होता है
• भारित यादृच्छिक (Weighted random) — बेहतर प्रतिष्ठा वाले आईपी का उपयोग अधिक बार किया जाता है
• जिटर रोटेशन (Jittered rotation) — निश्चित अंतराल में यादृच्छिक विलंब जोड़ना

✅ फायदे:

• अप्रत्याशितता — सुरक्षा प्रणालियों के लिए पैटर्न का पता लगाना कठिन है
• वास्तविक उपयोगकर्ताओं का अनुकरण — मनुष्य पूरी तरह से नियमित रूप से कार्य नहीं करते हैं
• प्राकृतिक ट्रैफ़िक पैटर्न — जैविक ट्रैफ़िक के समान दिखता है
• पता लगाना कठिन — बड़े डेटा वॉल्यूम में भी पता लगाना मुश्किल है

❌ नुकसान:

• पूर्वानुमान लगाना कठिन — कार्य पूरा होने की गति का अनुमान लगाना मुश्किल है
• अप्रभावी हो सकता है — यदि यादृच्छिकता के कारण आईपी बहुत बार बदलता है
• डीबगिंग जटिलता — यादृच्छिकता के कारण समस्या को दोहराना कठिन है
• बड़े पूल की आवश्यकता — समान लोड सुनिश्चित करने के लिए
• कार्यान्वयन में जटिलता — अच्छी यादृच्छिकता पीढ़ी एल्गोरिथम की आवश्यकता होती है

🎯 किसके लिए सबसे उपयुक्त:

• उन्नत सुरक्षा प्रणालियों (Cloudflare, Akamai) को बायपास करना
• अत्यधिक गोपनीयता की आवश्यकता वाले दीर्घकालिक प्रोजेक्ट
• प्रतिस्पर्धी खुफिया जानकारी
• व्यवहार विश्लेषण वाले साइटों की पार्सिंग
• ऐसे कार्य जहाँ अधिकतम मानवीय व्यवहार अनुकरण महत्वपूर्ण है

मानदंड	समय-आधारित	अनुरोध-आधारित	यादृच्छिक
कार्यान्वयन की जटिलता	⭐ आसान	⭐⭐ मध्यम	⭐⭐⭐ कठिन
पूर्वानुमेयता	✅ उच्च	⚠️ मध्यम	❌ निम्न
रेट लिमिट से बचाव	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
अदृश्यता	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐
सत्र समर्थन	✅ हाँ	❌ नहीं	⚠️ आंशिक
पूल उपयोग की दक्षता	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
पार्सिंग गति	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
आवश्यक पूल आकार	छोटा-मध्यम	बड़ा	मध्यम-बड़ा
डीबगिंग में आसानी	✅ आसान	⚠️ मध्यम	❌ कठिन
लागत	💰 कम	💰💰💰 उच्च	💰💰 मध्यम

स्टिकी सत्रों की विशिष्ट सेटिंग्स:

• 1-5 मिनट — त्वरित संचालन के लिए छोटे सत्र
• 10-30 मिनट — अधिकांश कार्यों के लिए मानक मोड
• 1-2 घंटे — खातों के साथ काम करने और प्रमाणीकरण के लिए
• 12-24 घंटे — दीर्घकालिक संचालन के लिए अधिकतम अवधि
• अनंत (बंद होने तक) — सत्र समाप्त होने तक आईपी बना रहता है

✅ स्टिकी सत्रों के फायदे:

• प्रमाणीकरण बनाए रखना — खाते में लॉग इन करके उसके नाम पर काम कर सकते हैं
• कुकीज़ का समर्थन — साइट आपको सत्रों के बीच याद रखती है
• प्राकृतिक व्यवहार — एक सामान्य उपयोगकर्ता एक सत्र के दौरान एक ही आईपी का उपयोग करता है
• कम सीएपीटीचा — लगातार आईपी कम संदेह पैदा करता है
• कार्यों की निरंतरता — बहु-चरणीय संचालन संभव है
• डीबग करने में आसान — किसी विशिष्ट आईपी के साथ समस्या को दोहराना आसान है

❌ नुकसान:

• रेट लिमिटिंग के प्रति संवेदनशील — सभी अनुरोध एक ही आईपी से आते हैं
• पूरे सत्र के बैन का जोखिम — यदि आईपी ब्लॉक हो जाता है, तो आप अपनी सारी प्रगति खो देते हैं
• मापनीयता में कमी — एक आईपी की गति तक सीमित
• सीमित अवधि — सत्र अंततः समाप्त हो जाएगा और आईपी बदल जाएगा

✅ रोटेटिंग प्रॉक्सी के फायदे:

• रेट लिमिटिंग से अधिकतम सुरक्षा — प्रत्येक आईपी न्यूनतम अनुरोध करता है
• उच्च पार्सिंग गति — हजारों समानांतर अनुरोध भेज सकते हैं
• ब्लॉक होने का जोखिम कम — यदि एक आईपी ब्लॉक हो जाता है, तो यह काम को प्रभावित नहीं करता है
• मापनीयता — काम की मात्रा बढ़ाना आसान है
• अदृश्यता — कई स्वतंत्र उपयोगकर्ताओं जैसा दिखता है

❌ रोटेटिंग प्रॉक्सी के नुकसान:

• प्रमाणीकरण असंभव — लगातार आईपी बदलने से सत्र टूट जाता है
• कुकीज़ काम नहीं करतीं — प्रत्येक अनुरोध नए उपयोगकर्ता से आता हुआ प्रतीत होता है
• बहु-चरणीय संचालन असंभव — कार्ट, फॉर्म, चेकआउट काम नहीं करते हैं
• अधिक सीएपीटीचा — आईपी में लगातार बदलाव संदेह पैदा कर सकता है
• अधिक महंगा — प्रभावी ढंग से काम करने के लिए प्रॉक्सी के बड़े पूल की आवश्यकता होती है

मानदंड	स्टिकी सत्र	रोटेटिंग प्रॉक्सी
प्रमाणीकरण	✅ हाँ	❌ नहीं
कुकीज़	✅ काम करती हैं	❌ काम नहीं करतीं
रेट लिमिट से बचाव	⚠️ सीमित	✅ उत्कृष्ट
पार्सिंग गति	⭐⭐⭐	⭐⭐⭐⭐⭐
ब्लॉक होने का जोखिम	⚠️ मध्यम	✅ निम्न
लागत	💰 कम	💰💰 उच्च
जटिलता	⭐ सरल	⭐⭐ मध्यम

1. सोशल मीडिया प्रबंधन

कई Instagram, Facebook, Twitter खातों के साथ काम करते समय, सत्र के दौरान एक ही आईपी बनाए रखना आवश्यक है। प्रमाणीकृत खाते के साथ आईपी में लगातार बदलाव सीधे तौर पर ब्लॉक होने का कारण बनता है।

सिफारिश: स्टिकी सत्र 1-2 घंटे, प्रत्येक खाते के लिए एक अद्वितीय आईपी।

2. ई-कॉमर्स और शॉपिंग कार्ट

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

सिफारिश: पूरी खरीद प्रक्रिया के लिए स्टिकी सत्र 30-60 मिनट।

3. फॉर्म भरना और पंजीकरण

बहु-चरणीय फॉर्म, साइट पंजीकरण, ईमेल सत्यापन—इन सभी प्रक्रियाओं में आईपी की निरंतरता की आवश्यकता होती है। चरणों के बीच आईपी बदलने से संदेह पैदा हो सकता है या सत्यापन त्रुटियाँ हो सकती हैं।

सिफारिश: प्रक्रिया पूरी करने के लिए स्टिकी सत्र 10-30 मिनट।

4. वेब एप्लिकेशन परीक्षण

ई2ई परीक्षण, सेलेनियम/पपेटियर के साथ स्वचालन, उपयोगकर्ता परिदृश्यों का परीक्षण—इन सभी के लिए वास्तविक उपयोगकर्ता अनुभव की नकल करने हेतु आईपी बनाए रखने की आवश्यकता होती है।

सिफारिश: परीक्षण की पूरी अवधि (5-60 मिनट) के लिए स्टिकी सत्र।

5. प्रमाणीकरण की आवश्यकता वाले एपीआई के साथ काम करना

कई एपीआई आईपी पते से बंधे एक्सेस टोकन जारी करते हैं। आईपी बदलने से टोकन अमान्य हो जाएगा और आपको फिर से प्रमाणीकरण करना होगा।

सिफारिश: टोकन की जीवन अवधि (आमतौर पर 1-24 घंटे) के लिए स्टिकी सत्र।

import requests
from itertools import cycle

# प्रॉक्सी की सूची
proxies_list = [
    'http://user:pass@185.45.12.34:8000',
    'http://user:pass@92.118.45.78:8000',
    'http://user:pass@178.62.91.22:8000',
    'http://user:pass@45.89.234.56:8000'
]

# अनंत इटरेटर बनाना
proxy_pool = cycle(proxies_list)

# अनुरोध भेजने का फंक्शन
def make_request(url):
    proxy = next(proxy_pool)
    proxies = {
        'http': proxy,
        'https': proxy
    }

    try:
        response = requests.get(url, proxies=proxies, timeout=10)
        print(f"सफलतापूर्वक {proxy} के साथ: {response.status_code}")
        return response
    except Exception as e:
        print(f"{proxy} के साथ त्रुटि: {e}")
        return None

# उपयोग
urls = ['https://example.com/page1', 'https://example.com/page2']
for url in urls:
    make_request(url)
    # प्रत्येक अनुरोध सूची से अगले प्रॉक्सी का उपयोग करता है

import requests
import random
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

class ProxyRotator:
    def __init__(self, proxies_list):
        self.proxies = proxies_list
        self.failed_proxies = set()

    def get_random_proxy(self):
        """यादृच्छिक कार्यशील प्रॉक्सी प्राप्त करें"""
        available = [p for p in self.proxies if p not in self.failed_proxies]
        if not available:
            # यदि सभी प्रॉक्सी विफल हो जाते हैं, तो सूची रीसेट करें
            self.failed_proxies.clear()
            available = self.proxies
        return random.choice(available)

    def make_request(self, url, max_retries=3):
        """त्रुटियों पर स्वचालित रोटेशन के साथ अनुरोध भेजना"""
        session = requests.Session()

        # Retry रणनीति सेट करना
        retry = Retry(
            total=max_retries,
            backoff_factor=0.5,
            status_forcelist=[500, 502, 503, 504]
        )
        adapter = HTTPAdapter(max_retries=retry)
        session.mount('http://', adapter)
        session.mount('https://', adapter)

        for attempt in range(max_retries):
            proxy = self.get_random_proxy()
            proxies = {'http': proxy, 'https': proxy}

            try:
                response = session.get(url, proxies=proxies, timeout=15)

                # रेट लिमिटिंग के लिए जाँच
                if response.status_code == 429:
                    print(f"{proxy} पर दर सीमित, घुमा रहा हूँ...")
                    self.failed_proxies.add(proxy)
                    continue

                print(f"✓ {proxy} के साथ सफलता")
                return response

            except Exception as e:
                print(f"✗ {proxy} के साथ विफल: {e}")
                self.failed_proxies.add(proxy)

        raise Exception(f"{url} के लिए सभी प्रयास विफल रहे")

# उपयोग
proxies = [
    'http://user:pass@proxy1.com:8000',
    'http://user:pass@proxy2.com:8000',
    'http://user:pass@proxy3.com:8000'
]

rotator = ProxyRotator(proxies)
response = rotator.make_request('https://example.com')

import requests
import time
from datetime import datetime, timedelta

class TimeBasedRotator:
    def __init__(self, proxies_list, rotation_interval=600):
        """
        rotation_interval: सेकंड में समय (600 = 10 मिनट)
        """
        self.proxies = proxies_list
        self.rotation_interval = rotation_interval
        self.current_proxy = None
        self.last_rotation = None
        self.current_index = 0

    def get_proxy(self):
        """वर्तमान प्रॉक्सी प्राप्त करें या यदि समय समाप्त हो गया है तो घुमाएँ"""
        now = datetime.now()

        # पहला रन या समय समाप्त
        if (self.last_rotation is None or
            (now - self.last_rotation).seconds >= self.rotation_interval):

            self.current_proxy = self.proxies[self.current_index]
            self.current_index = (self.current_index + 1) % len(self.proxies)
            self.last_rotation = now
            print(f"🔄 घुमाया गया: {self.current_proxy}")

        return self.current_proxy

    def make_request(self, url):
        proxy = self.get_proxy()
        proxies = {'http': proxy, 'https': proxy}

        response = requests.get(url, proxies=proxies, timeout=10)
        return response

# उपयोग: आईपी हर 10 मिनट में बदल जाएगा
proxies_list = [
    'http://user:pass@proxy1.com:8000',
    'http://user:pass@proxy2.com:8000',
    'http://user:pass@proxy3.com:8000'
]
rotator = TimeBasedRotator(proxies_list, rotation_interval=600)

for i in range(100):
    response = rotator.make_request('https://example.com')
    print(f"अनुरोध {i}: {response.status_code}")
    time.sleep(2)  # अनुरोधों के बीच 2 सेकंड

const axios = require('axios');
const HttpsProxyAgent = require('https-proxy-agent');

class ProxyRotator {
  constructor(proxies) {
    this.proxies = proxies;
    this.currentIndex = 0;
  }

  getNextProxy() {
    const proxy = this.proxies[this.currentIndex];
    this.currentIndex = (this.currentIndex + 1) % this.proxies.length;
    return proxy;
  }

  async makeRequest(url, options = {}) {
    const proxy = this.getNextProxy();
    const agent = new HttpsProxyAgent(proxy);

    try {
      const response = await axios.get(url, {
        ...options,
        httpAgent: agent,
        httpsAgent: agent,
        timeout: 10000
      });

      console.log(`✓ ${proxy} के साथ सफलता: ${response.status}`);
      return response.data;

    } catch (error) {
      console.error(`✗ ${proxy} के साथ विफलता: ${error.message}`);
      throw error;
    }
  }
}

// उपयोग
const proxies = [
  'http://user:pass@proxy1.com:8000',
  'http://user:pass@proxy2.com:8000',
  'http://user:pass@proxy3.com:8000'
];

const rotator = new ProxyRotator(proxies);

async function scrape() {
  const urls = [
    'https://example.com/page1',
    'https://example.com/page2',
    'https://example.com/page3'
  ];

  for (const url of urls) {
    try {
      await rotator.makeRequest(url);
    } catch (error) {
      console.error(`${url} को स्क्रैप करने में विफल`);
    }
  }
}

scrape();

const puppeteer = require('puppeteer');

class PuppeteerProxyRotator {
  constructor(proxies) {
    this.proxies = proxies;
    this.currentIndex = 0;
  }

  getNextProxy() {
    const proxy = this.proxies[this.currentIndex];
    this.currentIndex = (this.currentIndex + 1) % this.proxies.length;
    return proxy;
  }

  async scrapeWithRotation(url) {
    const proxy = this.getNextProxy();

    // प्रॉक्सी URL को पार्स करना
    const proxyUrl = new URL(proxy);

    const browser = await puppeteer.launch({
      headless: true,
      args: [
        `--proxy-server=${proxyUrl.protocol}//${proxyUrl.host}`,
        '--no-sandbox',
        '--disable-setuid-sandbox'
      ]
    });

    try {
      const page = await browser.newPage();

      // यदि प्रमाणीकरण आवश्यक हो तो प्रॉक्सी को प्रमाणित करें
      if (proxyUrl.username && proxyUrl.password) {
        await page.authenticate({
          username: proxyUrl.username,
          password: proxyUrl.password
        });
      }

      await page.goto(url, { waitUntil: 'networkidle2', timeout: 30000 });

      const content = await page.content();
      console.log(`✓ ${proxy} के साथ ${url} स्क्रैप किया गया`);

      await browser.close();
      return content;

    } catch (error) {
      console.error(`✗ ${proxy} के साथ त्रुटि: ${error.message}`);
      await browser.close();
      throw error;
    }
  }
}

// उपयोग
const proxies = [
  'http://user:pass@185.45.12.34:8000',
  'http://user:pass@92.118.45.78:8000'
];

const rotator = new PuppeteerProxyRotator(proxies);

async function scrapeMultiplePages() {
  const urls = ['https://example.com/1', 'https://example.com/2'];

  for (const url of urls) {
    await rotator.scrapeWithRotation(url);
    // प्रत्येक पृष्ठ एक नए प्रॉक्सी के साथ खुलता है
  }
}

scrapeMultiplePages();

यह कैसे काम करता है:

1. आप एक एकल एंडपॉइंट से कनेक्ट होते हैं (उदाहरण के लिए, rotate.proxycove.com:8000)
2. प्रत्येक अनुरोध पर गेटवे स्वचालित रूप से पूल से एक यादृच्छिक आईपी चुनता है
3. आपको प्रॉक्सी की सूची प्रबंधित करने और रोटेशन तर्क लिखने की आवश्यकता नहीं है
4. पैरामीटर (उपयोगकर्ता नाम में session_id) के माध्यम से स्टिकी सत्र कॉन्फ़िगर किए जा सकते हैं

# पायथन उदाहरण रोटेटिंग गेटवे के साथ
import requests

# रोटेटिंग के लिए: प्रत्येक अनुरोध = नया आईपी
proxies = {
    'http': 'http://username:password@rotate.proxycove.com:8000',
    'https': 'http://username:password@rotate.proxycove.com:8000'
}

# स्टिकी सत्र के लिए: session_id जोड़ना
sticky_proxies = {
    'http': 'http://username-session-abc123:password@rotate.proxycove.com:8000',
    'https': 'http://username-session-abc123:password@rotate.proxycove.com:8000'
}

# रोटेटिंग: प्रत्येक अनुरोध एक नए आईपी के साथ
for i in range(10):
    r = requests.get('https://api.ipify.org', proxies=proxies)
    print(f"अनुरोध {i}: आईपी = {r.text}")  # हर बार अलग आईपी

# स्टिकी: सभी अनुरोध एक ही आईपी के साथ
for i in range(10):
    r = requests.get('https://api.ipify.org', proxies=sticky_proxies)
    print(f"अनुरोध {i}: आईपी = {r.text}")  # हमेशा एक ही आईपी

1. ProxyBroker

स्वचालित रोटेशन और जांच के साथ प्रॉक्सी खोजने के लिए लाइब्रेरी।

2. rotating-proxies (Scrapy middleware)

स्वचालित रोटेशन और ब्लैकलिस्ट प्रबंधन के साथ Scrapy के लिए मिडलवेयर।

3. requests-ip-rotator

आईपी रोटेशन के लिए requests लाइब्रेरी का विस्तार, AWS API Gateway समर्थन के साथ।

1. proxy-chain

रोटेशन और टनलिंग के साथ HTTP प्रॉक्सी सर्वर बनाने के लिए लाइब्रेरी।

2. puppeteer-extra-plugin-proxy-rotation

प्रत्येक पृष्ठ के लिए स्वचालित प्रॉक्सी रोटेशन के साथ पपेटियर के लिए प्लगइन।

1. भारित रोटेशन (Weighted Rotation)

बेहतर प्रतिष्ठा और गति वाले प्रॉक्सी का अधिक बार उपयोग किया जाता है। उदाहरण के लिए, आवासीय आईपी को 0.6 भार मिलता है, और डेटासेंटर को 0.4।

2. जियो-टारगेटेड रोटेशन

लक्ष्य URL के आधार पर स्वचालित रूप से सही देश/शहर से प्रॉक्सी का चयन। उदाहरण के लिए, .de डोमेन के लिए जर्मन प्रॉक्सी का उपयोग करना।

3. स्वास्थ्य जाँच और ऑटो-हटाना

प्रॉक्सी के स्वास्थ्य की आवधिक जाँच और खराब प्रॉक्सी को स्वचालित रूप से पूल से बाहर करना। "कूलडाउन" अवधि के बाद बहाली।

4. अनुरोध दर अनुकूली रोटेशन

प्राप्त HTTP कोड के आधार पर रोटेशन की आवृत्ति स्वचालित रूप से समायोजित होती है। 429 (Too Many Requests) मिलने पर रोटेशन तेज हो जाता है।

स्टिकी सत्रों की विशिष्ट सेटिंग्स:

• 1-5 मिनट — त्वरित संचालन के लिए छोटे सत्र
• 10-30 मिनट — अधिकांश कार्यों के लिए मानक मोड
• 1-2 घंटे — खातों के साथ काम करने और प्रमाणीकरण के लिए
• 12-24 घंटे — दीर्घकालिक संचालन के लिए अधिकतम अवधि
• अनंत (बंद होने तक) — सत्र समाप्त होने तक आईपी बना रहता है

✅ स्टिकी सत्रों के फायदे:

• प्रमाणीकरण बनाए रखना — खाते में लॉग इन करके काम कर सकते हैं
• कुकीज़ का समर्थन — साइट आपको सत्रों के बीच याद रखती है
• प्राकृतिक व्यवहार — सामान्य उपयोगकर्ता सत्र के दौरान एक ही आईपी का उपयोग करता है
• कम सीएपीटीचा — लगातार आईपी कम संदेह पैदा करता है
• कार्यों की निरंतरता — बहु-चरणीय संचालन संभव है
• डीबग करने में आसान — किसी विशिष्ट आईपी के साथ समस्या को दोहराना आसान है

❌ नुकसान:

• रेट लिमिटिंग के प्रति संवेदनशील — सभी अनुरोध एक ही आईपी से आते हैं
• पूरे सत्र के बैन का जोखिम — यदि आईपी ब्लॉक हो जाता है, तो आप अपनी सारी प्रगति खो देते हैं
• मापनीयता में कमी — एक आईपी की गति तक सीमित
• सीमित अवधि — सत्र अंततः समाप्त हो जाएगा और आईपी बदल जाएगा

✅ रोटेटिंग प्रॉक्सी के फायदे:

• रेट लिमिटिंग से अधिकतम सुरक्षा — प्रत्येक आईपी न्यूनतम अनुरोध करता है
• उच्च पार्सिंग गति — हजारों समानांतर अनुरोध भेज सकते हैं
• ब्लॉक होने का जोखिम कम — यदि एक आईपी ब्लॉक हो जाता है, तो यह काम को प्रभावित नहीं करता है
• मापनीयता — काम की मात्रा बढ़ाना आसान है
• अदृश्यता — कई स्वतंत्र उपयोगकर्ताओं जैसा दिखता है

❌ रोटेटिंग प्रॉक्सी के नुकसान:

• प्रमाणीकरण असंभव — लगातार आईपी बदलने से सत्र टूट जाता है
• कुकीज़ काम नहीं करतीं — प्रत्येक अनुरोध नए उपयोगकर्ता से आता हुआ प्रतीत होता है
• बहु-चरणीय संचालन असंभव — कार्ट, फॉर्म, चेकआउट काम नहीं करते हैं
• अधिक सीएपीटीचा — आईपी में लगातार बदलाव संदेह पैदा कर सकता है
• अधिक महंगा — प्रभावी ढंग से काम करने के लिए प्रॉक्सी के बड़े पूल की आवश्यकता होती है

मानदंड	स्टिकी सत्र	रोटेटिंग प्रॉक्सी
प्रमाणीकरण	✅ हाँ	❌ नहीं
कुकीज़	✅ काम करती हैं	❌ काम नहीं करतीं
रेट लिमिट से बचाव	⚠️ सीमित	✅ उत्कृष्ट
पार्सिंग गति	⭐⭐⭐	⭐⭐⭐⭐⭐
ब्लॉक होने का जोखिम	⚠️ मध्यम	✅ निम्न
लागत	💰 कम	💰💰 उच्च
जटिलता	⭐ सरल	⭐⭐ मध्यम

1. सोशल मीडिया प्रबंधन

कई Instagram, Facebook, Twitter खातों के साथ काम करते समय, सत्र के दौरान एक ही आईपी बनाए रखना आवश्यक है। प्रमाणीकृत खाते के साथ आईपी में लगातार बदलाव सीधे तौर पर ब्लॉक होने का कारण बनता है।

सिफारिश: स्टिकी सत्र 1-2 घंटे, प्रत्येक खाते के लिए एक अद्वितीय आईपी।

2. ई-कॉमर्स और शॉपिंग कार्ट

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

सिफारिश: पूरी खरीद प्रक्रिया के लिए स्टिकी सत्र 30-60 मिनट।

3. फॉर्म भरना और पंजीकरण

बहु-चरणीय फॉर्म, साइट पंजीकरण, ईमेल सत्यापन—इन सभी प्रक्रियाओं में आईपी की निरंतरता की आवश्यकता होती है। चरणों के बीच आईपी बदलने से संदेह पैदा हो सकता है या सत्यापन त्रुटियाँ हो सकती हैं।

सिफारिश: प्रक्रिया पूरी करने के लिए स्टिकी सत्र 10-30 मिनट।

4. वेब एप्लिकेशन परीक्षण

ई2ई परीक्षण, सेलेनियम/पपेटियर के साथ स्वचालन, उपयोगकर्ता परिदृश्यों का परीक्षण—इन सभी के लिए वास्तविक उपयोगकर्ता अनुभव की नकल करने हेतु आईपी बनाए रखने की आवश्यकता होती है।

सिफारिश: परीक्षण की पूरी अवधि (5-60 मिनट) के लिए स्टिकी सत्र।

5. प्रमाणीकरण की आवश्यकता वाले एपीआई के साथ काम करना

कई एपीआई आईपी पते से बंधे एक्सेस टोकन जारी करते हैं। आईपी बदलने से टोकन अमान्य हो जाएगा और आपको फिर से प्रमाणीकरण करना होगा।

सिफारिश: टोकन की जीवन अवधि (आमतौर पर 1-24 घंटे) के लिए स्टिकी सत्र।

import requests
from itertools import cycle

# प्रॉक्सी की सूची
proxies_list = [
    'http://user:pass@185.45.12.34:8000',
    'http://user:pass@92.118.45.78:8000',
    'http://user:pass@178.62.91.22:8000',
    'http://user:pass@45.89.234.56:8000'
]

# अनंत इटरेटर बनाना
proxy_pool = cycle(proxies_list)

# अनुरोध भेजने का फंक्शन
def make_request(url):
    proxy = next(proxy_pool)
    proxies = {
        'http': proxy,
        'https': proxy
    }

    try:
        response = requests.get(url, proxies=proxies, timeout=10)
        print(f"सफलतापूर्वक {proxy} के साथ: {response.status_code}")
        return response
    except Exception as e:
        print(f"{proxy} के साथ त्रुटि: {e}")
        return None

# उपयोग
urls = ['https://example.com/page1', 'https://example.com/page2']
for url in urls:
    make_request(url)
    # प्रत्येक अनुरोध सूची से अगले प्रॉक्सी का उपयोग करता है

import requests
import random
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

class ProxyRotator:
    def __init__(self, proxies_list):
        self.proxies = proxies_list
        self.failed_proxies = set()

    def get_random_proxy(self):
        """यादृच्छिक कार्यशील प्रॉक्सी प्राप्त करें"""
        available = [p for p in self.proxies if p not in self.failed_proxies]
        if not available:
            # यदि सभी प्रॉक्सी विफल हो जाते हैं, तो सूची रीसेट करें
            self.failed_proxies.clear()
            available = self.proxies
        return random.choice(available)

    def make_request(self, url, max_retries=3):
        """त्रुटियों पर स्वचालित रोटेशन के साथ अनुरोध भेजना"""
        session = requests.Session()

        # Retry रणनीति सेट करना
        retry = Retry(
            total=max_retries,
            backoff_factor=0.5,
            status_forcelist=[500, 502, 503, 504]
        )
        adapter = HTTPAdapter(max_retries=retry)
        session.mount('http://', adapter)
        session.mount('https://', adapter)

        for attempt in range(max_retries):
            proxy = self.get_random_proxy()
            proxies = {'http': proxy, 'https': proxy}

            try:
                response = session.get(url, proxies=proxies, timeout=15)

                # रेट लिमिटिंग के लिए जाँच
                if response.status_code == 429:
                    print(f"{proxy} पर दर सीमित, घुमा रहा हूँ...")
                    self.failed_proxies.add(proxy)
                    continue

                print(f"✓ {proxy} के साथ सफलता")
                return response

            except Exception as e:
                print(f"✗ {proxy} के साथ विफल: {e}")
                self.failed_proxies.add(proxy)

        raise Exception(f"{url} के लिए सभी प्रयास विफल रहे")

# उपयोग
proxies = [
    'http://user:pass@proxy1.com:8000',
    'http://user:pass@proxy2.com:8000',
    'http://user:pass@proxy3.com:8000'
]

rotator = ProxyRotator(proxies)
response = rotator.make_request('https://example.com')

import requests
import time
from datetime import datetime, timedelta

class TimeBasedRotator:
    def __init__(self, proxies_list, rotation_interval=600):
        """
        rotation_interval: सेकंड में समय (600 = 10 मिनट)
        """
        self.proxies = proxies_list
        self.rotation_interval = rotation_interval
        self.current_proxy = None
        self.last_rotation = None
        self.current_index = 0

    def get_proxy(self):
        """वर्तमान प्रॉक्सी प्राप्त करें या यदि समय समाप्त हो गया है तो घुमाएँ"""
        now = datetime.now()

        # पहला रन या समय समाप्त
        if (self.last_rotation is None or
            (now - self.last_rotation).seconds >= self.rotation_interval):

            self.current_proxy = self.proxies[self.current_index]
            self.current_index = (self.current_index + 1) % len(self.proxies)
            self.last_rotation = now
            print(f"🔄 घुमाया गया: {self.current_proxy}")

        return self.current_proxy

    def make_request(self, url):
        proxy = self.get_proxy()
        proxies = {'http': proxy, 'https': proxy}

        response = requests.get(url, proxies=proxies, timeout=10)
        return response

# उपयोग: आईपी हर 10 मिनट में बदल जाएगा
proxies_list = [
    'http://user:pass@proxy1.com:8000',
    'http://user:pass@proxy2.com:8000',
    'http://user:pass@proxy3.com:8000'
]
rotator = TimeBasedRotator(proxies_list, rotation_interval=600)

for i in range(100):
    response = rotator.make_request('https://example.com')
    print(f"अनुरोध {i}: {response.status_code}")
    time.sleep(2)  # अनुरोधों के बीच 2 सेकंड

const axios = require('axios');
const HttpsProxyAgent = require('https-proxy-agent');

class ProxyRotator {
  constructor(proxies) {
    this.proxies = proxies;
    this.currentIndex = 0;
  }

  getNextProxy() {
    const proxy = this.proxies[this.currentIndex];
    this.currentIndex = (this.currentIndex + 1) % this.proxies.length;
    return proxy;
  }

  async makeRequest(url, options = {}) {
    const proxy = this.getNextProxy();
    const agent = new HttpsProxyAgent(proxy);

    try {
      const response = await axios.get(url, {
        ...options,
        httpAgent: agent,
        httpsAgent: agent,
        timeout: 10000
      });

      console.log(`✓ ${proxy} के साथ सफलता: ${response.status}`);
      return response.data;

    } catch (error) {
      console.error(`✗ ${proxy} के साथ विफलता: ${error.message}`);
      throw error;
    }
  }
}

// उपयोग
const proxies = [
  'http://user:pass@proxy1.com:8000',
  'http://user:pass@proxy2.com:8000',
  'http://user:pass@proxy3.com:8000'
];

const rotator = new ProxyRotator(proxies);

async function scrape() {
  const urls = [
    'https://example.com/page1',
    'https://example.com/page2',
    'https://example.com/page3'
  ];

  for (const url of urls) {
    try {
      await rotator.makeRequest(url);
    } catch (error) {
      console.error(`${url} को स्क्रैप करने में विफल`);
    }
  }
}

scrape();

const puppeteer = require('puppeteer');

class PuppeteerProxyRotator {
  constructor(proxies) {
    this.proxies = proxies;
    this.currentIndex = 0;
  }

  getNextProxy() {
    const proxy = this.proxies[this.currentIndex];
    this.currentIndex = (this.currentIndex + 1) % this.proxies.length;
    return proxy;
  }

  async scrapeWithRotation(url) {
    const proxy = this.getNextProxy();

    // प्रॉक्सी URL को पार्स करना
    const proxyUrl = new URL(proxy);

    const browser = await puppeteer.launch({
      headless: true,
      args: [
        `--proxy-server=${proxyUrl.protocol}//${proxyUrl.host}`,
        '--no-sandbox',
        '--disable-setuid-sandbox'
      ]
    });

    try {
      const page = await browser.newPage();

      // यदि प्रमाणीकरण आवश्यक हो तो प्रॉक्सी को प्रमाणित करें
      if (proxyUrl.username && proxyUrl.password) {
        await page.authenticate({
          username: proxyUrl.username,
          password: proxyUrl.password
        });
      }

      await page.goto(url, { waitUntil: 'networkidle2', timeout: 30000 });

      const content = await page.content();
      console.log(`✓ ${proxy} के साथ ${url} स्क्रैप किया गया`);

      await browser.close();
      return content;

    } catch (error) {
      console.error(`✗ ${proxy} के साथ त्रुटि: ${error.message}`);
      await browser.close();
      throw error;
    }
  }
}

// उपयोग
const proxies = [
  'http://user:pass@185.45.12.34:8000',
  'http://user:pass@92.118.45.78:8000'
];

const rotator = new PuppeteerProxyRotator(proxies);

async function scrapeMultiplePages() {
  const urls = ['https://example.com/1', 'https://example.com/2'];

  for (const url of urls) {
    await rotator.scrapeWithRotation(url);
    // प्रत्येक पृष्ठ एक नए प्रॉक्सी के साथ खुलता है
  }
}

scrapeMultiplePages();

यह कैसे काम करता है:

1. आप एक एकल एंडपॉइंट से कनेक्ट होते हैं (उदाहरण के लिए, rotate.proxycove.com:8000)
2. प्रत्येक अनुरोध पर गेटवे स्वचालित रूप से पूल से एक यादृच्छिक आईपी चुनता है
3. आपको प्रॉक्सी की सूची प्रबंधित करने और रोटेशन तर्क लिखने की आवश्यकता नहीं है
4. पैरामीटर (उपयोगकर्ता नाम में session_id) के माध्यम से स्टिकी सत्र कॉन्फ़िगर किए जा सकते हैं

# पायथन उदाहरण रोटेटिंग गेटवे के साथ
import requests

# रोटेटिंग के लिए: प्रत्येक अनुरोध = नया आईपी
proxies = {
    'http': 'http://username:password@rotate.proxycove.com:8000',
    'https': 'http://username:password@rotate.proxycove.com:8000'
}

# स्टिकी सत्र के लिए: session_id जोड़ना
sticky_proxies = {
    'http': 'http://username-session-abc123:password@rotate.proxycove.com:8000',
    'https': 'http://username-session-abc123:password@rotate.proxycove.com:8000'
}

# रोटेटिंग: प्रत्येक अनुरोध एक नए आईपी के साथ
for i in range(10):
    r = requests.get('https://api.ipify.org', proxies=proxies)
    print(f"अनुरोध {i}: आईपी = {r.text}")  # हर बार अलग आईपी

# स्टिकी: सभी अनुरोध एक ही आईपी के साथ
for i in range(10):
    r = requests.get('https://api.ipify.org', proxies=sticky_proxies)
    print(f"अनुरोध {i}: आईपी = {r.text}")  # हमेशा एक ही आईपी

1. ProxyBroker

स्वचालित रोटेशन और जांच के साथ प्रॉक्सी खोजने के लिए लाइब्रेरी।

2. rotating-proxies (Scrapy middleware)

स्वचालित रोटेशन और ब्लैकलिस्ट प्रबंधन के साथ Scrapy के लिए मिडलवेयर।

3. requests-ip-rotator

आईपी रोटेशन के लिए requests लाइब्रेरी का विस्तार, AWS API Gateway समर्थन के साथ।

1. proxy-chain

रोटेशन और टनलिंग के साथ HTTP प्रॉक्सी सर्वर बनाने के लिए लाइब्रेरी।

2. puppeteer-extra-plugin-proxy-rotation

प्रत्येक पृष्ठ के लिए स्वचालित प्रॉक्सी रोटेशन के साथ पपेटियर के लिए प्लगइन।

1. भारित रोटेशन (Weighted Rotation)

बेहतर प्रतिष्ठा और गति वाले प्रॉक्सी का अधिक बार उपयोग किया जाता है। उदाहरण के लिए, आवासीय आईपी को 0.6 भार मिलता है, और डेटासेंटर को 0.4।

2. जियो-टारगेटेड रोटेशन

लक्ष्य URL के आधार पर स्वचालित रूप से सही देश/शहर से प्रॉक्सी का चयन। उदाहरण के लिए, .de डोमेन के लिए जर्मन प्रॉक्सी का उपयोग करना।

3. स्वास्थ्य जाँच और ऑटो-हटाना

प्रॉक्सी के स्वास्थ्य की आवधिक जाँच और खराब प्रॉक्सी को स्वचालित रूप से पूल से बाहर करना। "कूलडाउन" अवधि के बाद बहाली।

4. अनुरोध दर अनुकूली रोटेशन

प्राप्त HTTP कोड के आधार पर रोटेशन की आवृत्ति स्वचालित रूप से समायोजित होती है। 429 (Too Many Requests) मिलने पर रोटेशन तेज हो जाता है।

1. लक्ष्य साइट का प्रकार

• अत्यधिक सुरक्षित (बैंक, सोशल मीडिया): हर 3-5 अनुरोध या 10-15 मिनट में रोटेशन
• ई-कॉमर्स (Amazon, Walmart): हर 5-10 अनुरोध या 5-10 मिनट में रोटेशन
• समाचार साइटें: हर 10-20 अनुरोध या 15-30 मिनट में रोटेशन
• सार्वजनिक एपीआई: एपीआई दस्तावेज़ीकरण के अनुसार (अक्सर 100-1000 अनुरोध/घंटा प्रति आईपी)
• स्थिर साइटें: हर 20-50 अनुरोध या 30-60 मिनट में रोटेशन

2. एकत्र किए जाने वाले डेटा की मात्रा

• छोटी मात्रा (1,000 पृष्ठों तक): समय-आधारित, हर 15-30 मिनट में रोटेशन
• मध्यम मात्रा (1,000-10,000 पृष्ठ): अनुरोध-आधारित, हर 10-15 अनुरोधों पर रोटेशन
• बड़ी मात्रा (10,000+ पृष्ठ): प्रति-अनुरोध रोटेशन बड़े प्रॉक्सी पूल के साथ

3. प्रॉक्सी पूल का आकार

• छोटा पूल (10-50 आईपी): समय-आधारित रोटेशन 30-60 मिनट, ताकि प्रत्येक आईपी "ठंडा" हो सके
• मध्यम पूल (50-200 आईपी): अनुरोध-आधारित रोटेशन 10-20 अनुरोध प्रति आईपी
• बड़ा पूल (200+ आईपी): प्रति-अनुरोध रोटेशन, अधिकतम गति

4. सत्र की आवश्यकताएँ

• बिना प्रमाणीकरण के: आक्रामक रोटेशन, हर 1-5 अनुरोध
• प्रमाणीकरण के साथ: सत्र की पूरी अवधि (1-24 घंटे) के लिए स्टिकी सत्र
• हाइब्रिड मोड: प्रमाणीकरण के लिए स्टिकी, डेटा संग्रह के लिए रोटेटिंग

उपयोग का परिदृश्य	रोटेशन आवृत्ति	पूल का आकार	अनुरोधों के बीच विलंब
Google खोज पार्सिंग	हर 3-5 अनुरोध	200-500 आईपी	5-10 सेकंड
Amazon मूल्य निगरानी	हर 5-10 अनुरोध	100-300 आईपी	3-7 सेकंड
Instagram स्वचालन	स्टिकी 1-2 घंटे	1 आईपी प्रति खाता	30-60 सेकंड
समाचार एग्रीगेटर	हर 15-30 मिनट	50-100 आईपी	1-3 सेकंड
रियल एस्टेट पार्सिंग	हर 10-20 अनुरोध	50-200 आईपी	2-5 सेकंड
एपीआई निगरानी	एपीआई सीमाओं के अनुसार	सीमाओं के अनुसार	दस्तावेज़ीकरण के अनुसार
एसईओ स्थिति ट्रैकिंग	हर 20-30 अनुरोध	100-300 आईपी	3-8 सेकंड
Avito/Yula पार्सिंग	हर 7-15 अनुरोध	100-200 आईपी	3-6 सेकंड

1. राउंड-रॉबिन (चक्रीय)

प्रॉक्सी को सूची में क्रम से चुना जाता है। अंतिम के बाद, फिर से पहले से शुरू होता है। सबसे सरल विधि, जो समान वितरण सुनिश्चित करती है।

2. यादृच्छिक (Random)

प्रत्येक बार पूल से एक यादृच्छिक प्रॉक्सी चुना जाता है। पता लगाने के लिए एक कम अनुमानित पैटर्न।

3. न्यूनतम कनेक्शन (Least Connections)

सबसे कम सक्रिय कनेक्शन वाला प्रॉक्सी चुना जाता है। समानांतर अनुरोधों के लिए आदर्श।

4. भारित राउंड-रॉबिन (Weighted Round-Robin)

बेहतर प्रदर्शन वाले प्रॉक्सी को अधिक भार मिलता है और उनका उपयोग अधिक बार किया जाता है। आवासीय आईपी को 3 भार, डेटासेंटर को 1 भार मिल सकता है।

5. आईपी हैश (Hash)

प्रॉक्सी को यूआरएल या डोमेन के हैश के आधार पर चुना जाता है। यह सुनिश्चित करता है कि एक ही डोमेन के अनुरोध हमेशा एक ही आईपी के माध्यम से जाते हैं।

कूलडाउन अवधि की सिफारिशें:

• छोटा पूल (10-50 आईपी): एक आईपी के उपयोग के बीच 30-60 मिनट
• मध्यम पूल (50-200 आईपी): उपयोग के बीच 15-30 मिनट
• बड़ा पूल (200+ आईपी): 5-15 मिनट या प्रति-अनुरोध रोटेशन के साथ कोई कूलडाउन नहीं

1. आक्रामक मोड (Speed-First)

• प्रति-अनुरोध रोटेशन — प्रत्येक अनुरोध के लिए नया आईपी
• न्यूनतम विलंब (0.5-1 सेकंड अनुरोधों के बीच)
• बड़ा प्रॉक्सी पूल (500+ आईपी)
• समानांतर अनुरोध (5-30 थ्रेड)

⚠️ जोखिम: ब्लॉक होने की उच्च संभावना, आईपी का छोटा जीवन चक्र, रोटेशन के साथ भी रेट लिमिटिंग ट्रिगर हो सकता है।

📊 उपयुक्त: एक बार के कार्य, सार्वजनिक डेटा संग्रह, सहिष्णु साइटों के साथ काम करना।

2. संतुलित मोड (Balanced)

• अनुरोध-आधारित रोटेशन — हर 10-20 अनुरोध के बाद
• मध्यम विलंब (अनुरोधों के बीच 2-5 सेकंड)
• मध्यम प्रॉक्सी पूल (100-300 आईपी)
• मध्यम समानांतरवाद (5-15 थ्रेड)

✅ फायदे: गति और स्थिरता का अच्छा संतुलन, अधिकांश कार्यों के लिए उपयुक्त।

📊 उपयुक्त: ई-कॉमर्स निगरानी, नियमित पार्सिंग, दीर्घकालिक प्रोजेक्ट।

3. सतर्क मोड (Stealth-First)

• समय-आधारित रोटेशन — हर 15-30 मिनट
• बड़े विलंब (अनुरोधों के बीच 5-15 सेकंड)
• उच्च गुणवत्ता वाले प्रॉक्सी का छोटा पूल (50-100 आवासीय आईपी)
• न्यूनतम समानांतरवाद (1-3 थ्रेड)
• मानवीय व्यवहार का अनुकरण (यादृच्छिक विलंब, उपयोगकर्ता क्रियाएँ)

✅ फायदे: ब्लॉक होने का न्यूनतम जोखिम, दीर्घकालिक स्थिरता, वास्तविक उपयोगकर्ताओं जैसा दिखता है।

📊 उपयुक्त: सोशल मीडिया, उच्च-सुरक्षा वाली साइटें, खाता प्रबंधन, प्रतिस्पर्धी खुफिया जानकारी।

❌ समस्या 1: रोटेशन के बावजूद 429 (Too Many Requests) मिल रहा है

संभावित कारण:

• एक ही डोमेन पर बहुत बार रोटेशन
• सभी प्रॉक्सी एक ही सबनेट से हैं (ASN द्वारा पता लगाया गया)
• यूज़र-एजेंट और अन्य हेडर रोटेट नहीं हो रहे हैं
• कूलडाउन अवधि बहुत कम है

✅ समाधान:

• अनुरोधों के बीच विलंब 5-10 सेकंड तक बढ़ाएँ
• डेटासेंटर प्रॉक्सी के बजाय आवासीय प्रॉक्सी का उपयोग करें
• यूज़र-एजेंट, हेडर और टीएलएस फ़िंगरप्रिंट का रोटेशन शामिल करें
• प्रॉक्सी पूल का आकार 2-3 गुना बढ़ाएँ
• विलंब में जिटर (यादृच्छिक विचलन) जोड़ें

❌ समस्या 2: आईपी बदलने पर लगातार सीएपीटीचा आ रहा है

संभावित कारण:

• खराब प्रतिष्ठा वाले डेटासेंटर प्रॉक्सी
• बहुत आक्रामक रोटेशन संदेह पैदा कर रहा है
• सार्वजनिक (मुफ्त) प्रॉक्सी का उपयोग
• आईपी बदलने पर ब्राउज़र फ़िंगरप्रिंट नहीं बदलता है

✅ समाधान:

• आवासीय या मोबाइल प्रॉक्सी पर स्विच करें
• लगातार रोटेशन के बजाय स्टिकी सत्रों का उपयोग करें
• सीएपीटीचा हल करने वाली सेवाओं (2Captcha, AntiCaptcha) को एकीकृत करें
• एंटी-डिटेक्ट ब्राउज़र (Playwright, puppeteer-extra-plugin-stealth) का उपयोग करें
• मुख्य कार्य से पहले प्रॉक्सी को "वार्म-अप" करें (कुछ सरल अनुरोध भेजें)

❌ समस्या 3: प्रमाणीकरण के दौरान सत्र खो जाता है

संभावित कारण:

• आईपी रोटेशन सत्र को तोड़ता है
• कुकीज़ अनुरोधों के बीच सहेजी नहीं जाती हैं
• स्टिकी सत्र की अवधि समाप्त हो गई है

✅ समाधान:

• प्रमाणीकृत अनुरोधों के लिए session_id के साथ स्टिकी सत्र का उपयोग करें
• स्टिकी सत्र की अवधि बढ़ाएँ (1-24 घंटे)
• सत्रों के बीच कुकीज़/टोकन सहेजें और पुन: उपयोग करें
• हाइब्रिड दृष्टिकोण: प्रमाणीकरण के लिए स्टिकी, डेटा संग्रह के लिए रोटेटिंग

❌ समस्या 4: प्रॉक्सी पूल जल्दी समाप्त हो जाता है

संभावित कारण:

• बहुत आक्रामक प्रति-अनुरोध रोटेशन
• बड़ी मात्रा में काम के लिए छोटा पूल
• कूलडाउन अवधि पर विचार नहीं किया गया

✅ समाधान:

• बर्स्ट रोटेशन पर स्विच करें (हर N अनुरोध के बाद बदलना, हर बार नहीं)
• लोड के अनुपात में प्रॉक्सी पूल का आकार बढ़ाएँ
• कूलडाउन ट्रैकिंग के साथ कतार लागू करें
• प्रदाता से रोटेटिंग प्रॉक्सी गेटवे का उपयोग करें

❌ समस्या 5: पार्सिंग की गति धीमी है

संभावित कारण:

• धीमे प्रॉक्सी (उच्च पिंग)
• समानांतर के बजाय अनुक्रमिक प्रसंस्करण
• अनुरोधों के बीच बड़े विलंब
• बार-बार रोटेशन के कारण कनेक्शन स्थापित करने में ओवरहेड

✅ समाधान:

• कनेक्शन पूलिंग और कीप-अलाइव का उपयोग करें
• अनुरोधों को समानांतर रूप से संसाधित करें (थ्रेडिंग/asyncio)
• कम पिंग वाले प्रॉक्सी चुनें (विलंब के आधार पर फ़िल्टर करें)
• रोटेशन आवृत्ति कम करें (बर्स्ट के बजाय प्रति-अनुरोध)
• तेज प्रॉक्सी का उपयोग करें (आवासीय के बजाय ISP)

मेट्रिक	सामान्य	समस्या यदि
सफलता दर	> 95%	< 85%
429 त्रुटि दर	< 2%	> 10%
403/503 त्रुटि दर	< 3%	> 15%
CAPTCHA दर	< 1%	> 5%
औसत प्रतिक्रिया समय	< 3 सेकंड	> 10 सेकंड
टाइमआउट दर	< 1%	> 5%
उपयोग किए गए अद्वितीय आईपी	> 80% पूल	< 50% पूल

✅ 1. आईपी रोटेशन को हमेशा अन्य तकनीकों के साथ मिलाएं

आईपी रोटेशन केवल एक घटक है। यूज़र-एजेंट, वास्तविक ब्राउज़र (Puppeteer/Playwright), मानवीय व्यवहार का अनुकरण, हेडर और कुकीज़ का रोटेशन भी करें।

✅ 2. महत्वपूर्ण कार्यों के लिए आवासीय/मोबाइल प्रॉक्सी का उपयोग करें

डेटासेंटर प्रॉक्सी सस्ते हैं लेकिन उनकी प्रतिष्ठा खराब है। सोशल मीडिया, ई-कॉमर्स और उच्च-सुरक्षा वाली साइटों के लिए केवल आवासीय या मोबाइल आईपी का उपयोग करें।

✅ 3. ग्रेसफुल डिग्रेडेशन लागू करें

त्रुटियाँ बढ़ने पर स्वचालित रूप से अनुरोधों को धीमा करें, विलंब बढ़ाएँ, उच्च गुणवत्ता वाले प्रॉक्सी पर स्विच करें। अनुकूलनशीलता कठोर कॉन्फ़िगरेशन से बेहतर है।

✅ 4. स्केलिंग से पहले छोटे नमूने पर परीक्षण करें

बड़े पैमाने पर पार्सिंग शुरू करने से पहले 100-1000 अनुरोधों पर रणनीति का परीक्षण करें। सुनिश्चित करें कि सफलता दर > 95% है, कोई बड़े पैमाने पर अवरोधन नहीं है, और गति स्वीकार्य है।

✅ 5. robots.txt और सेवा की शर्तों का सम्मान करें

नैतिक पार्सिंग दीर्घकालिक सफलता की कुंजी है। robots.txt का पालन करें, सर्वर को ओवरलोड न करें, सहमति के बिना व्यक्तिगत डेटा एकत्र न करें। रूस में, यह व्यक्तिगत डेटा कानून द्वारा नियंत्रित होता है।

✅ 6. गुणवत्ता वाले प्रॉक्सी में निवेश करें

मुफ्त और सस्ते प्रॉक्सी लंबी अवधि में अधिक महंगे पड़ते हैं: कम गति, लगातार अवरोधन, डेटा हानि, सुरक्षा जोखिम। ProxyCove जैसे विश्वसनीय प्रदाताओं का उपयोग करें जो अपटाइम की गारंटी देते हैं।

मुख्य निष्कर्ष:

1. कोई सार्वभौमिक समाधान नहीं — रणनीति का चुनाव साइट के प्रकार, डेटा की मात्रा, बजट और गति की आवश्यकताओं पर निर्भर करता है
2. तीन मुख्य प्रकार के रोटेशन: time-based (स्थिरता), request-based (गति), random (अदृश्यता) — संयोजन का उपयोग करें
3. स्टिकी सत्र महत्वपूर्ण हैं — प्रमाणीकरण, कार्ट और बहु-चरणीय प्रक्रियाओं के लिए आवश्यक हैं। रोटेटिंग प्रॉक्सी बड़े पैमाने पर पार्सिंग के लिए हैं
4. गुणवत्ता मात्रा से अधिक महत्वपूर्ण है — अधिकांश कार्यों के लिए 50 आवासीय आईपी 500 डेटासेंटर आईपी से बेहतर हैं
5. निगरानी अनिवार्य है — समय पर अनुकूलन के लिए सफलता दर, त्रुटि कोड और प्रतिक्रिया समय ट्रैक करें
6. गति और अदृश्यता में संतुलन — आक्रामक पार्सिंग अल्पकालिक परिणाम देती है, सतर्क पार्सिंग दीर्घकालिक स्थिरता देती है
7. प्रदाता के माध्यम से स्वचालन — समय बचाने के लिए स्वयं के समाधान के बजाय रोटेटिंग गेटवे का उपयोग करें
8. अनुकूलनशीलता > स्थिरता — सुरक्षा प्रणालियाँ विकसित हो रही हैं, आपकी रणनीति को भी अनुकूलित होना चाहिए

📋 पार्सिंग शुरू करने से पहले चेकलिस्ट:

💼 व्यवसाय के लिए:

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

🎓 डेवलपर्स के लिए:

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