गूगल कोलैब और ज्यूपिटर में प्रॉक्सी सेटअप करना: आईपी ब्लॉकिंग के बिना पार्सिंग के लिए

Google Colab और Jupyter Notebook स्क्रिप्टिंग के लिए तेज़ी से लिखने और चलाने के लिए सुविधाजनक उपकरण हैं, बिना अपने स्थानीय मशीन पर Python स्थापित किए। लेकिन क्लाउड नोटबुक की एक विशेषता है, जिसे अक्सर भुला दिया जाता है: सभी अनुरोध Google के डेटा सेंटर के IP पतों से आते हैं, जो एंटी-बॉट सिस्टम द्वारा लंबे समय से ज्ञात हैं और लगभग तुरंत बैन कर दिए जाते हैं। इस लेख में, हम देखेंगे कि Colab और Jupyter में प्रॉक्सी को सही तरीके से कैसे कनेक्ट किया जाए, क्लाउड वातावरण द्वारा लगाए गए सीमाएँ क्या हैं और पार्सिंग को इस तरह से कैसे व्यवस्थित किया जाए कि यह पहले 50 अनुरोधों के बाद न गिरे।

Google Colab को सामान्य PC की तुलना में अधिक बार क्यों बैन किया जाता है

Colab के लिए पार्सिंग की मुख्य समस्या IP पतों का सामान्य पूल है। हर बार जब आप नोटबुक चलाते हैं, Google अपने क्लाउड रेंज (AS15169 और समान) से IP के साथ एक वर्चुअल मशीन आवंटित करता है। ये रेंज लंबे समय से अधिकांश एंटी-बॉट सिस्टम के ब्लैकलिस्ट में हैं: Cloudflare, DataDome, PerimeterX, और Wildberries, Ozon और मार्केटप्लेस की अंतर्निहित सुरक्षा इन्हें सेकंड के भीतर पहचान लेती है। अनुरोध साइट तक नहीं पहुँचता — इसे ASN (Autonomous System Number) द्वारा फ़िल्टर किया जाता है, जो User-Agent या व्यवहार की जाँच से पहले ही होता है।

दूसरी वजह है उपयोग की व्यापकता। हजारों डेवलपर्स एक साथ Colab के माध्यम से पार्सर, बॉट और ML स्क्रिप्ट चला रहे हैं, इसलिए इन IP की प्रतिष्ठा कई लक्षित साइटों पर पहले से ही "जल चुकी" है। भले ही आप हर 10 सेकंड में एक सावधानीपूर्वक GET अनुरोध करें, साइट 403 वापस कर सकती है बस इसलिए कि उसी रेंज से एक घंटे पहले किसी ने 500 थ्रेड्स में सर्वर पर हमला किया था।

तीसरी वजह है कि स्थानीय रूप से चलाया गया Jupyter आमतौर पर इस समस्या का सामना नहीं करता (यदि आपके पास सामान्य घरेलू या कार्यालय IP है), लेकिन जब आप JupyterHub के माध्यम से होस्टिंग सर्वर पर या क्लाउड प्रदाता के कंटेनर में काम करना शुरू करते हैं — स्थिति Colab के समान हो जाती है। इसलिए "प्रॉक्सी की आवश्यकता है या नहीं" का प्रश्न क्लाउड नोटबुक के लिए स्पष्ट रूप से हल किया जाता है: बिना प्रॉक्सी के पार्सिंग पहले कुछ अनुरोधों के बाद लगभग काम नहीं करती है।

कौन सा प्रॉक्सी क्लाउड पार्सिंग के लिए उपयुक्त है

प्रॉक्सी के प्रकार का चयन इस बात पर निर्भर करता है कि आप क्या पार्स कर रहे हैं और लक्षित साइट की सुरक्षा कितनी आक्रामक है। Colab और Jupyter के लिए एक और बिंदु पर विचार करना महत्वपूर्ण है: नोटबुक सत्र का समय सीमित है, इसलिए लंबे समय तक चलने वाले स्टिकी सत्र प्रॉक्सी हमेशा महत्वपूर्ण नहीं होते — अक्सर एक ही रन के भीतर कनेक्शन की स्थिरता अधिक महत्वपूर्ण होती है।

प्रॉक्सी का प्रकार	Colab/Jupyter में कब उपयोग करें	विशेषताएँ
डेटा सेंटर प्रॉक्सी	कठोर सुरक्षा के बिना वेबसाइटों का पार्सिंग, ओपन API, स्थिर पृष्ठ	उच्च गति, कम कीमत, लेकिन आक्रामक साइटों पर ASN द्वारा भी बैन किया जा सकता है
रिहायशी प्रॉक्सी	Wildberries, Ozon, Avito, Google, एंटी-बॉट सुरक्षा के साथ सोशल मीडिया का पार्सिंग	वास्तविक उपयोगकर्ताओं के IP, कम ही ब्लैकलिस्ट में आते हैं, अधिक लेटेंसी
मोबाइल प्रॉक्सी	मोबाइल वेबसाइटों का पार्सिंग, TikTok, Instagram API के माध्यम से	सबसे उच्च ट्रस्ट, लेकिन महंगे और धीमे रोटेशन

अधिकांश मार्केटप्लेस और सर्च इंजन पार्सिंग कार्यों के लिए Colab में रिहायशी प्रॉक्सी के साथ प्रत्येक अनुरोध पर रोटेशन का संयोजन सबसे अच्छा संतुलन होगा — यह व्यवहार पैटर्न के आधार पर बैन होने की संभावना को कम करता है, भले ही अनुरोध Google के क्लाउड वातावरण से किया गया हो।

requests और urllib में प्रॉक्सी सेटअप

Colab में प्रॉक्सी का मूल सेटअप स्थानीय Python वातावरण से अलग नहीं है। अंतर केवल इतना है कि Colab में पुस्तकालयों को आमतौर पर !pip install के माध्यम से फिर से स्थापित करना आवश्यक है, क्योंकि मानक छवि हमेशा आवश्यक सभी चीजें नहीं रखती है।

!pip install requests

import requests

proxy = {
    "http": "http://login:[email protected]:9000",
    "https": "http://login:[email protected]:9000"
}

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}

response = requests.get(
    "https://example.com/catalog",
    proxies=proxy,
    headers=headers,
    timeout=15
)

print(response.status_code)
print(response.text[:500])

एक महत्वपूर्ण बिंदु: Colab में कोई स्थायी कॉन्फ़िगरेशन फ़ाइल नहीं है, इसलिए प्रॉक्सी का लॉगिन और पासवर्ड या तो हार्डकोड करना पड़ता है (जो नोटबुक को प्रकाशित करते समय सुरक्षित नहीं है), या Colab में पर्यावरण चर के माध्यम से google.colab.userdata में संग्रहीत करना पड़ता है, या Colab Secrets के माध्यम से कनेक्ट करना पड़ता है। यह कोड में पासवर्ड को सीधे रखने की तुलना में अधिक सुविधाजनक है, विशेष रूप से यदि आप अपने सहयोगियों के साथ नोटबुक साझा कर रहे हैं।

from google.colab import userdata

proxy_login = userdata.get('PROXY_LOGIN')
proxy_pass = userdata.get('PROXY_PASS')

proxy_url = f"http://{proxy_login}:{proxy_pass}@gate.proxycove.com:9000"
proxies = {"http": proxy_url, "https": proxy_url}

Colab में Selenium और headless Chrome के साथ प्रॉक्सी

यदि साइट JavaScript के माध्यम से सामग्री को रेंडर करती है (Wildberries, Ozon, Avito के लिए सामान्य स्थिति), तो साधारण requests पर्याप्त नहीं हैं — एक headless ब्राउज़र की आवश्यकता होती है। Colab में यह आमतौर पर Chromium के साथ Selenium होता है, जिसे मैन्युअल रूप से स्थापित करना आवश्यक है, क्योंकि मूल छवि में यह नहीं होता है।

!apt-get update
!apt install chromium-chromedriver
!pip install selenium

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

chrome_options = Options()
chrome_options.add_argument('--headless')
chrome_options.add_argument('--no-sandbox')
chrome_options.add_argument('--disable-dev-shm-usage')
chrome_options.add_argument('--proxy-server=http://gate.proxycove.com:9000')

driver = webdriver.Chrome(options=chrome_options)
driver.get("https://example.com/catalog")
print(driver.page_source[:500])
driver.quit()

समस्या यह है कि --proxy-server फ्लैग सीधे लॉगिन और पासवर्ड के साथ प्रमाणीकरण का समर्थन नहीं करता है। Selenium में प्रमाणीकरण के साथ प्रॉक्सी के लिए, या तो IP प्रमाणीकरण (नोटबुक के स्थिर IP पर व्हाइटलिस्टिंग, जो Colab में अस्थिर है, क्योंकि मशीन का IP हर नए रन पर बदलता है) का उपयोग करना पड़ता है, या प्रॉक्सी के साथ लॉगिन क्रेडेंशियल्स को निर्दिष्ट करते हुए Chrome एक्सटेंशन "ऑन द फ्लाई" उत्पन्न करना पड़ता है, या selenium-wire जैसी पुस्तकालय के माध्यम से प्रॉक्सी टनल का उपयोग करना पड़ता है, जो बॉक्स से बाहर प्रमाणीकरण प्रॉक्सी का समर्थन करता है।

!pip install selenium-wire

from seleniumwire import webdriver

proxy_options = {
    'proxy': {
        'http': 'http://login:[email protected]:9000',
        'https': 'http://login:[email protected]:9000',
    }
}

driver = webdriver.Chrome(seleniumwire_options=proxy_options, options=chrome_options)
driver.get("https://example.com/catalog")

Jupyter Notebook: स्थानीय बनाम क्लाउड

स्थानीय मशीन पर चलाया गया Jupyter Notebook (Anaconda के माध्यम से या सीधे pip के माध्यम से) आपका घरेलू या कार्यालय IP पता उपयोग करता है — और इस मामले में प्रॉक्सी केवल छिपाने या भू-सीमाओं को बायपास करने के लिए आवश्यक हैं, न कि डेटा सेंटर के ASN द्वारा बैन से बचने के लिए। इस मामले में सेटअप पूरी तरह से सामान्य Python स्क्रिप्ट के समान है: वही requests, वही Selenium, ड्राइवरों और सिस्टम पैकेजों की स्थापना पर कोई प्रतिबंध नहीं।

स्थिति बदल जाती है यदि आप क्लाउड सेवा के माध्यम से Jupyter का उपयोग कर रहे हैं: JupyterHub पर VPS, Kaggle Notebooks, Deepnote, Binder या कॉर्पोरेट क्लाउड क्लस्टर। इन मामलों में IP फिर से प्रदाता के डेटा सेंटर का होता है, और Colab की सभी समस्याएँ एक समान होती हैं। Colab से मुख्य अंतर यह है कि ऐसे सेवाओं में अक्सर सत्र के दौरान अधिक स्थिर IP होता है (हर बार कोर को पुनरारंभ करने पर नहीं बदलता), जो IP पर व्हाइटलिस्टिंग सेटअप को सरल बनाता है, यदि आपका प्रॉक्सी प्रदाता इसे समर्थन करता है।

व्यावहारिक निष्कर्ष: यदि पार्सिंग व्यवसाय के लिए महत्वपूर्ण है (उदाहरण के लिए, मार्केटप्लेस पर प्रतिस्पर्धियों की कीमतों की दैनिक निगरानी), तो मुफ्त क्लाउड नोटबुक को प्रोडक्शन वातावरण के रूप में नहीं लेना बेहतर है, बल्कि केवल स्क्रिप्ट के विकास और परीक्षण के लिए उनका उपयोग करें, अंतिम पार्सर को स्थायी IP और सेटअप प्रॉक्सी के साथ सर्वर पर ले जाएँ।

क्लाउड नोटबुक की सीमाएँ, जो पार्सिंग को तोड़ती हैं

IP की प्रतिष्ठा की समस्याओं के अलावा, Google Colab में कुछ तकनीकी सीमाएँ हैं, जो सीधे पार्सिंग की स्थिरता को प्रभावित करती हैं:

• निष्क्रियता का टाइमआउट। Colab का मुफ्त संस्करण ~90 मिनट की निष्क्रियता के बाद नोटबुक को बंद कर देता है और 12 घंटे की निरंतर कार्यवाही के बाद सत्र को मजबूरन समाप्त कर देता है — हजारों पृष्ठों के लंबे पार्सिंग को भागों में विभाजित करना या Google Drive पर मध्यवर्ती परिणामों को सहेजना आवश्यक है।
• हर नए रनटाइम पर IP बदलना। यदि आपने वातावरण को डिस्कनेक्ट और फिर से कनेक्ट किया है, तो वर्चुअल मशीन का IP पता बदल जाता है — यह प्रॉक्सी सेवा के पक्ष पर IP पर व्हाइटलिस्टिंग के किसी भी सेटअप को तोड़ता है।
• आउटगोइंग कनेक्शनों पर प्रतिबंध। Google एक वर्चुअल मशीन से एक साथ नेटवर्क कनेक्शनों की संख्या को सीमित करता है, इसलिए कई समानांतर अनुरोधों के साथ आक्रामक मल्टीथ्रेडिंग साइट के ब्लॉक में नहीं, बल्कि Colab की सीमाओं में रुक सकती है।
• बिना डिस्क माउंट किए स्थायी स्टोरेज नहीं है। कुकीज़, ब्राउज़र सत्र और प्रॉक्सी कनेक्शन का कैश हर पुनरारंभ पर गायब हो जाता है — प्रमाणीकरण के साथ पार्सिंग के लिए कुकीज़ को स्पष्ट रूप से Google Drive पर फ़ाइल में सहेजना आवश्यक है।
• अनपेक्षित नेटवर्क विलंबता। Google की क्लाउड अवसंरचना कभी-कभी विलंबता में कूद देती है, जिसके कारण अनुरोधों के टाइमआउट को अतिरिक्त समय (15-30 सेकंड मानक 5-10 के बजाय) के साथ सेट करना आवश्यक है।

ये सीमाएँ Colab को पार्सर के तर्क के विकास और डिबगिंग के लिए एक उत्कृष्ट उपकरण बनाती हैं, लेकिन लंबे प्रोडक्शन कार्यों के लिए इसे खराब बनाती हैं — उनके लिए तैयार स्क्रिप्ट को VPS या स्थायी IP वाले समर्पित सर्वर पर ले जाना बेहतर है।

प्रॉक्सी का रोटेशन और लूप में त्रुटियों को संभालना

ताकि पार्सिंग पहली ही ब्लॉक पर न गिरे, कोड में प्रॉक्सी बदलने के साथ पुनः प्रयास करने की लॉजिक होनी चाहिए। नीचे एक साधारण लूप का उदाहरण है जिसमें रोटेशन और त्रुटियों को संभालने की लॉजिक है, जिसे आप सीधे Colab में चला सकते हैं।

import requests
import time
import random

proxy_pool = [
    "http://login:[email protected]:9000",
    "http://login:[email protected]:9001",
    "http://login:[email protected]:9002",
]

def get_with_retry(url, max_retries=5):
    for attempt in range(max_retries):
        proxy_url = random.choice(proxy_pool)
        proxies = {"http": proxy_url, "https": proxy_url}
        try:
            response = requests.get(url, proxies=proxies, timeout=20)
            if response.status_code == 200:
                return response
            else:
                print(f"कोशिश {attempt+1}: स्थिति {response.status_code}")
        except requests.exceptions.RequestException as e:
            print(f"कोशिश {attempt+1}: त्रुटि {e}")
        time.sleep(random.uniform(2, 5))
    return None

result = get_with_retry("https://example.com/catalog")
if result:
    print(result.status_code)
else:
    print("सभी प्रयास समाप्त हो गए")

बड़े कैटलॉग (उदाहरण के लिए, Wildberries पर हजारों उत्पाद कार्ड) के पार्सिंग के लिए, इस लॉजिक को अनुरोधों के बीच विराम और Google Drive में CSV या डेटाबेस में मध्यवर्ती परिणामों को सहेजने के साथ कार्यों की कतार में लपेटा जाता है, ताकि Colab सत्र के टूटने पर प्रगति न खोएं।

Colab में पार्सर चलाने से पहले चेकलिस्ट

• प्रॉक्सी को अलग परीक्षण अनुरोध के माध्यम से कनेक्ट और परीक्षण किया गया है
• प्रॉक्सी का लॉगिन और पासवर्ड Colab Secrets में संग्रहीत हैं, न कि खुले कोड में
• JS साइटों के लिए Selenium का उपयोग किया जाता है जिसमें selenium-wire या निर्दिष्ट प्रमाणीकरण एक्सटेंशन होता है
• कोड में 403/429 त्रुटियों पर पुनः प्रयास करने की लॉजिक और प्रॉक्सी का रोटेशन है
• मध्यवर्ती परिणाम हर N रिकॉर्ड पर Google Drive पर सहेजे जाते हैं
• संभव विलंबताओं को ध्यान में रखते हुए अनुरोधों के टाइमआउट बढ़ाए गए हैं
• अनुरोधों की समानांतरता सीमित है, ताकि Colab के आउटगोइंग कनेक्शनों की सीमाओं में न फंसे
• प्रोडक्शन कार्यों के लिए स्क्रिप्ट को स्थायी IP वाले अलग सर्वर पर ले जाने की योजना बनाई गई है

निष्कर्ष

Google Colab और क्लाउड Jupyter पार्सर की लॉजिक के तेज विकास और परीक्षण के लिए उत्कृष्ट हैं, लेकिन डेटा सेंटर के सामान्य IP के कारण लगभग हमेशा पहले चरणों में प्रॉक्सी की आवश्यकता होती है। साधारण साइटों के लिए जिनमें आक्रामक सुरक्षा नहीं होती है, डेटा सेंटर प्रॉक्सी पर्याप्त होते हैं, जबकि मार्केटप्लेस, सर्च इंजन और सोशल मीडिया के पार्सिंग के लिए रिहायशी और मोबाइल IP अधिक विश्वसनीय होते हैं, जो ASN द्वारा फ़िल्टर में कम आते हैं।

यदि आप Colab से Wildberries या Ozon पर कीमतों की नियमित निगरानी करने की योजना बना रहे हैं, तो हम रिहायशी प्रॉक्सी से शुरू करने की सिफारिश करते हैं — ये बिना बार-बार ब्लॉक किए स्थिर पहुंच प्रदान करते हैं, और एक बार के परीक्षण स्क्रिप्ट के लिए आप अधिक बजट वाले डेटा सेंटर प्रॉक्सी का उपयोग कर सकते हैं, उन्हें उसी योजना के माध्यम से requests या Selenium के माध्यम से कनेक्ट करके।