प्रॉक्सी के लिए टाइमआउट और रीट्राई लॉजिक कैसे सेट करें: डेटा हानि से बचाव पार्सिंग के दौरान

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

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

प्रॉक्सी के साथ काम करते समय टाइमआउट क्यों महत्वपूर्ण है

एक स्थिति की कल्पना करें: आपने Wildberries से 10,000 उत्पादों के लिए मूल्य पार्सर शुरू किया। स्क्रिप्ट प्रॉक्सी के माध्यम से काम कर रही है ताकि बैन न हो। सब कुछ ठीक चल रहा है, लेकिन 523वें अनुरोध पर प्रॉक्सी सर्वर उत्तर देना बंद कर देता है — शायद यह ओवरलोडेड है या अस्थायी रूप से अनुपलब्ध है। बिना सेट किए गए टाइमआउट के, आपका स्क्रिप्ट उत्तर की प्रतीक्षा अनंत काल तक करेगा (या जब तक सिस्टम टाइमआउट 2-5 मिनट में समाप्त नहीं हो जाता)। अंततः, पार्सिंग रुक जाती है, आप समय खो देते हैं, और जब तक आप समस्या का पता लगाते हैं, तब तक कई घंटे बीत चुके होते हैं।

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

• प्रॉक्सी सर्वर अस्थिर हो सकते हैं — विशेष रूप से सार्वजनिक या सस्ते। यहां तक कि गुणवत्ता वाले रेसिडेंशियल प्रॉक्सी कभी-कभी असली उपयोगकर्ता के इंटरनेट से डिस्कनेक्ट होने के कारण कनेक्शन खो देते हैं।
• लक्षित साइट आईपी को ब्लॉक कर सकती है — यदि प्रॉक्सी बैन में है, तो यह बिल्कुल उत्तर नहीं देगा या बहुत लंबे समय तक उत्तर देगा (कैप्चा या रीडायरेक्ट देते हुए)।
• नेटवर्क लेटेंसी अप्रत्याशित होती है — विशेष रूप से अन्य देशों से प्रॉक्सी का उपयोग करते समय। अनुरोध कई मध्यवर्ती नोड्स के माध्यम से जा सकता है।
• मास ऑपरेशंस को स्थिरता की आवश्यकता होती है — यदि आप 100,000 पृष्ठों को पार्स कर रहे हैं या 50 इंस्टाग्राम खातों का प्रबंधन कर रहे हैं, तो लटके हुए अनुरोधों का 1% = 1000 खोई हुई ऑपरेशंस।

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

टाइमआउट के प्रकार: कनेक्ट, पढ़ें और कुल टाइमआउट

तीन मुख्य प्रकार के टाइमआउट होते हैं, जिन्हें समझना और अलग से सेट करना आवश्यक है। कई शुरुआती डेवलपर्स और पार्सर उपयोगकर्ता केवल एक सामान्य टाइमआउट सेट करते हैं, जिससे समस्याएँ उत्पन्न होती हैं।

1. कनेक्ट टाइमआउट (कनेक्शन टाइमआउट)

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

कब सक्रिय होता है: प्रॉक्सी सर्वर अनुपलब्ध है, ओवरलोडेड है या आईपी फायरवॉल द्वारा ब्लॉक किया गया है।

अनुशंसित मान:

• तेज डेटा सेंटर प्रॉक्सी के लिए: 3-5 सेकंड
• रेसिडेंशियल प्रॉक्सी के लिए: 5-10 सेकंड
• मोबाइल प्रॉक्सी के लिए: 10-15 सेकंड (मोबाइल इंटरनेट धीमा होता है)

2. पढ़ें टाइमआउट (रीड टाइमआउट)

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

कब सक्रिय होता है: लक्षित साइट अनुरोध को धीमी गति से संसाधित करती है, ओवरलोडेड है या संदेहास्पद अनुरोधों को जानबूझकर धीमा करती है।

अनुशंसित मान:

• सरल पृष्ठों (HTML) के लिए पार्सिंग: 10-15 सेकंड
• जावास्क्रिप्ट-रेनडरिंग के साथ पार्सिंग के लिए: 30-60 सेकंड
• API अनुरोधों के लिए: 5-10 सेकंड
• बड़े फ़ाइलों को डाउनलोड करने के लिए: 120+ सेकंड

3. कुल टाइमआउट (टोटल टाइमआउट)

यह पूरे अनुरोध को शुरू से अंत तक पूरा करने के लिए अधिकतम समय है, जिसमें कनेक्शन, अनुरोध भेजना, उत्तर प्राप्त करना और पढ़ना शामिल है। टोटल टाइमआउट एक "आपातकालीन स्विच" है, जो यह सुनिश्चित करता है कि कोई भी अनुरोध निर्धारित समय से अधिक समय तक नहीं चलेगा।

कब उपयोग करें: जब यह महत्वपूर्ण हो कि प्रत्येक अनुरोध सख्त समय सीमा में हो (जैसे, वास्तविक समय में पार्सिंग के लिए आर्बिट्रेज के लिए)।

सूत्र: टोटल टाइमआउट = कनेक्ट टाइमआउट + पढ़ें टाइमआउट + 20-30% का मार्जिन

विभिन्न कार्यों के लिए टाइमआउट के लिए अनुकूलतम मान

टाइमआउट के सही मान आपकी कार्य, प्रॉक्सी के प्रकार और लक्षित साइट पर निर्भर करते हैं। बहुत छोटे टाइमआउट बहुत सारे झूठे त्रुटियों का कारण बनेंगे (प्रॉक्सी काम कर रहा है, लेकिन आप इसे अस्वीकार कर रहे हैं)। बहुत लंबे टाइमआउट मरे हुए प्रॉक्सी की प्रतीक्षा में समय बर्बाद करने का कारण बनेंगे।

रीट्राई लॉजिक: पुनः प्रयासों को सही तरीके से कैसे सेट करें

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

रीट्राई लॉजिक एक त्रुटि पर अनुरोध को स्वचालित रूप से पुनः प्रयास करना है। सही सेटिंग के मुख्य सिद्धांत:

1. निर्धारित करें कि कौन सी त्रुटियाँ पुनः प्रयास की आवश्यकता है

सभी त्रुटियों को पुनः प्रयास करने की आवश्यकता नहीं होती। उदाहरण के लिए:

• पुनः प्रयास करना चाहिए: टाइमआउट, कनेक्शन अस्वीकृत, प्रॉक्सी त्रुटि, 502/503/504 (सर्वर की अस्थायी त्रुटियाँ), रेट लिमिटिंग (429)
• पुनः प्रयास करने की आवश्यकता नहीं: 404 (पृष्ठ नहीं मिला), 403 (दृश्यता हमेशा के लिए प्रतिबंधित), 401 (गलत प्रमाणीकरण), डेटा मान्यता में त्रुटियाँ

2. प्रयासों की संख्या सेट करें

पुनः प्रयासों की सही संख्या डेटा की महत्वपूर्णता पर निर्भर करती है:

• गैर-आवश्यक कार्यों के लिए (विश्लेषण के लिए पार्सिंग): 2-3 प्रयास
• महत्वपूर्ण कार्यों के लिए (प्रतिस्पर्धियों की कीमतों की निगरानी): 3-5 प्रयास
• महत्वपूर्ण कार्यों के लिए (विज्ञापन खातों के साथ काम करना): 5-10 प्रयास

3. एक्सपोनेंशियल बैकऑफ का उपयोग करें

अनुरोध को तुरंत पुनः प्रयास न करें — इससे समस्या बढ़ सकती है (जैसे, यदि सर्वर ओवरलोडेड है)। प्रयासों के बीच बढ़ती हुई देरी का उपयोग करें:

• 1st प्रयास: तुरंत
• 2nd प्रयास: 1-2 सेकंड के बाद
• 3rd प्रयास: 4-5 सेकंड के बाद
• 4th प्रयास: 10-15 सेकंड के बाद

सूत्र: देरी = बेस_देरी * (2 ^ प्रयास_संख्या)। उदाहरण: 1 सेकंड, 2 सेकंड, 4 सेकंड, 8 सेकंड, 16 सेकंड।

4. पुनः प्रयासों के दौरान प्रॉक्सी की रोटेशन

सबसे महत्वपूर्ण नियम: पुनः प्रयास के दौरान अपने पूल से एक अलग प्रॉक्सी का उपयोग करें। यदि एक प्रॉक्सी अनुरोध को पूरा नहीं कर सका, तो पुनः प्रयास करने पर यह काम करने की संभावना बहुत कम है। लेकिन एक अन्य प्रॉक्सी उच्च संभावना के साथ सफल हो सकता है।

यह विशेष रूप से रेसिडेंशियल प्रॉक्सी के साथ काम करते समय महत्वपूर्ण है, जहां आपके पास सैकड़ों या हजारों आईपी पते का पूल होता है। प्रत्येक रीट्राई पर पूल से एक नया यादृच्छिक आईपी लें।

पायथन में टाइमआउट और रीट्राई सेटिंग के उदाहरण

पायथन में लोकप्रिय पुस्तकालयों का उपयोग करके टाइमआउट और रीट्राई लॉजिक को लागू करने के व्यावहारिक उदाहरणों पर विचार करें।

उदाहरण 1: requests के साथ बुनियादी सेटिंग

requests पुस्तकालय पायथन में HTTP अनुरोधों के लिए सबसे लोकप्रिय है। यहाँ टाइमआउट और सरल रीट्राई सेट करने का तरीका है:

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

# रीट्राई लॉजिक सेट करना
retry_strategy = Retry(
    total=5,  # अधिकतम 5 प्रयास
    backoff_factor=1,  # देरी: 1, 2, 4, 8, 16 सेकंड
    status_forcelist=[429, 500, 502, 503, 504],  # रीट्राई के लिए त्रुटि कोड
    allowed_methods=["HEAD", "GET", "POST", "PUT", "DELETE"]
)

adapter = HTTPAdapter(max_retries=retry_strategy)
session = requests.Session()
session.mount("http://", adapter)
session.mount("https://", adapter)

# प्रॉक्सी सेट करना
proxies = {
    'http': 'http://username:password@proxy.example.com:8080',
    'https': 'http://username:password@proxy.example.com:8080'
}

# टाइमआउट के साथ अनुरोध करना
try:
    response = session.get(
        'https://www.wildberries.ru/catalog/electronics',
        proxies=proxies,
        timeout=(5, 15)  # कनेक्ट टाइमआउट 5 सेकंड, पढ़ें टाइमआउट 15 सेकंड
    )
    print(f"सफलता! स्थिति: {response.status_code}")
    print(f"उत्तर का आकार: {len(response.content)} बाइट्स")
except requests.exceptions.Timeout:
    print("त्रुटि: टाइमआउट पार किया गया")
except requests.exceptions.ProxyError:
    print("त्रुटि: प्रॉक्सी के साथ समस्या")
except requests.exceptions.RequestException as e:
    print(f"अनुरोध त्रुटि: {e}")

इस उदाहरण में, हमने सत्र के स्तर पर स्वचालित रीट्राई सेट किया। त्रुटियों 429, 500, 502, 503, 504 पर, पुस्तकालय स्वचालित रूप से 5 बार अनुरोध को पुनः प्रयास करेगा, बढ़ती हुई देरी के साथ।

उदाहरण 2: रीट्राई के दौरान प्रॉक्सी की रोटेशन

प्रत्येक प्रयास पर प्रॉक्सी के पूल से रोटेशन के साथ एक अधिक उन्नत उदाहरण:

import requests
import random
import time

# प्रॉक्सी का पूल (अपने वास्तविक प्रॉक्सी से बदलें)
PROXY_POOL = [
    'http://user:pass@proxy1.example.com:8080',
    'http://user:pass@proxy2.example.com:8080',
    'http://user:pass@proxy3.example.com:8080',
    'http://user:pass@proxy4.example.com:8080',
]

def make_request_with_retry(url, max_retries=5, base_delay=1):
    """
    रीट्राई और प्रॉक्सी की रोटेशन के साथ अनुरोध करना
    """
    for attempt in range(max_retries):
        # पूल से एक यादृच्छिक प्रॉक्सी चुनें
        proxy = random.choice(PROXY_POOL)
        proxies = {'http': proxy, 'https': proxy}
        
        try:
            response = requests.get(
                url,
                proxies=proxies,
                timeout=(5, 15),
                headers={'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64)'}
            )
            
            # स्थिति कोड की जांच करें
            if response.status_code == 200:
                return response
            elif response.status_code in [429, 500, 502, 503, 504]:
                # अस्थायी त्रुटि - पुनः प्रयास करें
                print(f"प्रयास {attempt + 1}: कोड {response.status_code}, पुनः प्रयास...")
            else:
                # स्थायी त्रुटि - प्रयास समाप्त करें
                print(f"त्रुटि {response.status_code}, प्रयास समाप्त करें")
                return None
                
        except (requests.exceptions.Timeout, 
                requests.exceptions.ProxyError,
                requests.exceptions.ConnectionError) as e:
            print(f"प्रयास {attempt + 1}: त्रुटि {type(e).__name__}, पुनः प्रयास...")
        
        # यदि यह अंतिम प्रयास नहीं है - बढ़ती हुई देरी के साथ प्रतीक्षा करें
        if attempt < max_retries - 1:
            delay = base_delay * (2 ** attempt)
            print(f"अगले प्रयास से पहले {delay} सेकंड प्रतीक्षा...")
            time.sleep(delay)
    
    print("सभी प्रयास समाप्त")
    return None

# उपयोग
result = make_request_with_retry('https://www.ozon.ru/category/smartfony-15502/')
if result:
    print(f"सफलता! {len(result.content)} बाइट डेटा प्राप्त हुआ")
else:
    print("अनुरोध पूरा करने में असफल")

इस कोड में, प्रत्येक प्रयास पर एक नया यादृच्छिक प्रॉक्सी पूल से चुना जाता है, जो अनुरोध को सफलतापूर्वक पूरा करने की संभावना को काफी बढ़ाता है।

उदाहरण 3: tenacity पुस्तकालय का उपयोग

रीट्राई लॉजिक को अधिक लचीले ढंग से प्रबंधित करने के लिए, आप विशेष पुस्तकालय tenacity का उपयोग कर सकते हैं:

from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type
import requests

@retry(
    stop=stop_after_attempt(5),  # अधिकतम 5 प्रयास
    wait=wait_exponential(multiplier=1, min=1, max=30),  # एक्सपोनेंशियल देरी 1-30 सेकंड
    retry=retry_if_exception_type((requests.exceptions.Timeout, 
                                   requests.exceptions.ProxyError,
                                   requests.exceptions.ConnectionError))
)
def fetch_with_proxy(url, proxy):
    """
    स्वचालित रीट्राई के साथ कार्य
    """
    proxies = {'http': proxy, 'https': proxy}
    response = requests.get(url, proxies=proxies, timeout=(5, 15))
    response.raise_for_status()  # HTTP त्रुटि पर अपवाद उठाएगा
    return response

# उपयोग
try:
    result = fetch_with_proxy(
        'https://www.avito.ru/rossiya/telefony',
        'http://user:pass@proxy.example.com:8080'
    )
    print(f"सफलता! स्थिति: {result.status_code}")
except Exception as e:
    print(f"सभी प्रयासों के बाद अनुरोध पूरा करने में असफल: {e}")

पुस्तकालय tenacity डेकोरेटर्स के माध्यम से रीट्राई को सेट करने के लिए बहुत लचीले विकल्प प्रदान करता है। स्थापना: pip install tenacity

कोड के बिना पार्सिंग के लिए तैयार समाधान

यदि आप प्रोग्रामर नहीं हैं या विकास में समय बचाना चाहते हैं, तो ऐसे तैयार पार्सिंग उपकरण हैं जिनमें टाइमआउट और रीट्राई लॉजिक का अंतर्निहित समर्थन होता है। आपको कोड लिखने की आवश्यकता नहीं है — बस ग्राफिकल इंटरफेस में सेटिंग्स को कॉन्फ़िगर करें।

Octoparse

Windows और Mac के लिए लोकप्रिय दृश्य पार्सर। टाइमआउट और रीट्राई सेट करना:

• कार्य सेटिंग्स खोलें → उन्नत विकल्प
• पृष्ठ लोड टाइमआउट: 20-30 सेकंड सेट करें
• Ajax टाइमआउट: गतिशील सामग्री के लिए 10-15 सेकंड
• त्रुटि पर पुनः प्रयास次数: 3-5 प्रयास
• प्रॉक्सी सेटिंग्स में आप सूची अपलोड कर सकते हैं और स्वचालित रोटेशन सक्षम कर सकते हैं

ParseHub

मुफ्त योजना के साथ क्लाउड पार्सर। सेटिंग:

• सेटिंग्स → उन्नत → पृष्ठ लोड देरी: 5-10 सेकंड
• अनुरोध टाइमआउट: 30 सेकंड
• असफल अनुरोधों पर पुनः प्रयास करें: सक्षम करें, 3 प्रयास
• प्रोजेक्ट सेटिंग्स के माध्यम से प्रॉक्सी का समर्थन करता है

Apify

लोकप्रिय साइटों के लिए पार्सिंग के लिए तैयार स्क्रिप्टों (अभिनेताओं) के साथ वेब कार्यों के स्वचालन के लिए एक मंच। मार्केटप्लेस (Wildberries, Ozon) के लिए कई अभिनेता पहले से ही टाइमआउट और रीट्राई के लिए अनुकूलित सेटिंग्स के साथ आते हैं। आपको केवल:

• आवश्यक साइट के लिए तैयार अभिनेता का चयन करें
• प्रॉक्सी निर्दिष्ट करें (प्रॉक्सी प्रदाताओं के साथ एकीकरण का समर्थन करता है)
• कार्य शुरू करें — बाकी सब स्वचालित रूप से सेट हो गया है

एंटी-डिटेक्ट ब्राउज़र ऑटोमेशन के लिए

यदि आप Dolphin Anty, AdsPower या Multilogin के माध्यम से सोशल मीडिया या विज्ञापन प्लेटफार्मों के साथ काम कर रहे हैं, तो टाइमआउट ब्राउज़र प्रोफ़ाइल में सेट किया जाता है:

• Dolphin Anty: प्रोफ़ाइल सेटिंग्स → प्रॉक्सी → टाइमआउट: 10-15 सेकंड
• AdsPower: प्रॉक्सी सेटिंग्स → कनेक्शन टाइमआउट: 10 सेकंड, पढ़ें टाइमआउट: 20 सेकंड
• Multilogin: ब्राउज़र प्रोफ़ाइल → नेटवर्क → प्रॉक्सी टाइमआउट: 15 सेकंड

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

टाइमआउट सेट करते समय सामान्य गलतियाँ

यहां तक कि अनुभवी डेवलपर्स और पार्सिंग विशेषज्ञ टाइमआउट और रीट्राई के साथ काम करते समय सामान्य गलतियाँ करते हैं। यहाँ सबसे सामान्य हैं:

त्रुटि 1: बिल्कुल टाइमआउट का अभाव

कई पुस्तकालय डिफ़ॉल्ट रूप से टाइमआउट सेट नहीं करते हैं या बहुत बड़ा मान (कुछ मिनट) रखते हैं। यदि आपने स्पष्ट रूप से टाइमआउट निर्दिष्ट नहीं किया है — आपका स्क्रिप्ट लंबे समय तक लटक सकता है।

समाधान: हमेशा प्रत्येक अनुरोध में स्पष्ट रूप से टाइमआउट निर्दिष्ट करें। 15 सेकंड में त्रुटि प्राप्त करना बेहतर है, बजाय इसके कि 5 मिनट प्रतीक्षा करें।

त्रुटि 2: सभी रीट्राई पर एक ही प्रॉक्सी

यदि प्रॉक्सी ने पहले प्रयास में उत्तर नहीं दिया, तो उस प्रॉक्सी के माध्यम से पुनः प्रयास करने की संभावना बहुत कम होती है। कई लोग प्रयासों के बीच प्रॉक्सी को रोटेट करना भूल जाते हैं।

समाधान: प्रत्येक रीट्राई पर पूल से एक नई प्रॉक्सी का उपयोग करें। यह उच्च सफलता दर के लिए महत्वपूर्ण है।

त्रुटि 3: धीमी प्रॉक्सी के लिए बहुत छोटे टाइमआउट

मोबाइल और कुछ रेसिडेंशियल प्रॉक्सी डेटा सेंटर की तुलना में धीमी हो सकती हैं। यदि आप मोबाइल प्रॉक्सी के लिए 5 सेकंड का टाइमआउट सेट करते हैं — तो आपको पूरी तरह से काम करने वाले आईपी पर बहुत सारी झूठी त्रुटियाँ मिलेंगी।

समाधान: प्रॉक्सी के प्रकार पर विचार करें। मोबाइल के लिए कम से कम 10-15 सेकंड का टाइमआउट उपयोग करें।

त्रुटि 4: अनलिमिटेड रीट्राई

कुछ लोग बिना प्रयासों की संख्या को सीमित किए while True लूप में रीट्राई को लागू करते हैं। यदि समस्या लक्षित साइट पर है (जैसे, यह पूरी तरह से गिर गई है) — स्क्रिप्ट अनंत रूप से प्रयास करती रहेगी।

समाधान: हमेशा रीट्राई की संख्या को सीमित करें (अधिकतम 3-10 प्रयास) और बाद में विश्लेषण के लिए असफल अनुरोधों को लॉग करें।

त्रुटि 5: त्रुटि के प्रकार की अनदेखी

सभी त्रुटियों को पुनः प्रयास करने की आवश्यकता नहीं होती। उदाहरण के लिए, यदि आपको 404 (पृष्ठ नहीं मिला) मिला है — तो पुनः प्रयास करना बेकार है, पृष्ठ बस मौजूद नहीं है। लेकिन 503 (सेवा अस्थायी रूप से अनुपलब्ध) — कुछ सेकंड के बाद पुनः प्रयास करने का अर्थ है।

समाधान: त्रुटि के प्रकार का विश्लेषण करें और केवल अस्थायी समस्याओं (टाइमआउट, कनेक्शन त्रुटि, 429, 500, 502, 503, 504) को पुनः प्रयास करें।

त्रुटि 6: लॉगिंग का अभाव

बिना लॉग के, आप नहीं समझेंगे कि अनुरोध क्यों गिरते हैं: समस्या प्रॉक्सी में है, टाइमआउट में या लक्षित साइट में?

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

निष्कर्ष

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

इस मार्गदर्शिका से मुख्य निष्कर्ष:

• हमेशा स्पष्ट रूप से टाइमआउट सेट करें: कनेक्ट टाइमआउट 5-10 सेकंड, पढ़ें टाइमआउट 10-30 सेकंड कार्य के अनुसार
• रीट्राई लॉजिक का उपयोग करें जिसमें 3-5 प्रयासों की सीमा और एक्सपोनेंशियल बैकऑफ हो
• प्रत्येक पुनः प्रयास पर प्रॉक्सी को रोटेट करें — यह उच्च सफलता दर की कुंजी है
• केवल अस्थायी त्रुटियों (टाइमआउट, 429, 500, 502, 503, 504) को पुनः प्रयास करें, स्थायी (404, 403) पर प्रयास न करें
• विश्लेषण और सेटिंग्स को अनुकूलित करने के लिए सभी त्रुटियों को लॉग करें
• प्रॉक्सी के प्रकार पर विचार करें: मोबाइल डेटा सेंटर से धीमे होते हैं, टाइमआउट को तदनुसार बढ़ाएं

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

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