कई सर्वरों पर वितरित पार्सर: बिना संघर्ष और प्रतिबंधों के प्रॉक्सी पूल का विभाजन

जब पार्सर एक सर्वर से कई कार्यकर्ताओं के क्लस्टर में स्थानांतरित होता है, तो एक नई समस्या उत्पन्न होती है - कई मशीनें एक ही प्रॉक्सी पूल का एक साथ उपयोग करने लगती हैं। बिना समन्वय के, यह अनुरोधों में IP की डुप्लिकेशन, एक पते पर सीमाओं का उल्लंघन और बड़े पैमाने पर बैन की ओर ले जाता है। इस लेख में, हम देखेंगे कि सर्वरों के बीच प्रॉक्सी को सही तरीके से कैसे शार्ड किया जाए, कौन सी वितरण योजनाएं सबसे अच्छा काम करती हैं और इसे प्रैक्टिकल में Python और Redis के कोड के साथ कैसे लागू किया जाए।

वितरित पार्सर में प्रॉक्सी क्यों संघर्ष करते हैं

एक सामान्य स्थिति की कल्पना करें: आपके पास 500 प्रॉक्सी का एक पूल है और तीन सर्वर हैं, जिनमें से प्रत्येक 50 समानांतर कार्यकर्ताओं को Wildberries, Ozon या Avito के लिए चलाता है। यदि प्रत्येक सर्वर बिना समन्वय के सामान्य सूची से प्रॉक्सी लेता है, तो विभिन्न मशीनों पर दो कार्यकर्ता एक ही IP से एक ही डोमेन पर एक साथ अनुरोध भेज सकते हैं। एंटी-बॉट सिस्टम के लिए, यह एक ही पते से अनुरोधों की असामान्य रूप से उच्च आवृत्ति के रूप में दिखाई देता है - और IP कुछ ही मिनटों में बैन हो जाता है।

दूसरी समस्या - लोड का असमान वितरण। यदि प्रॉक्सी बस "जैसा हो सके" साझा की जाती हैं, तो एक सर्वर सबसे तेज और ताजे IP को ले सकता है, जबकि दूसरा पहले से खराब प्रतिष्ठा वाले शेष को ले सकता है। परिणामस्वरूप, सर्वरों पर पार्सिंग की गति में कई गुना अंतर होगा, और त्रुटियों का प्रतिशत भी।

तीसरी समस्या - स्थिति का नुकसान। यदि एक सर्वर पर प्रॉक्सी बैन हो जाती है, तो अन्य सर्वर इसके बारे में नहीं जानते और इसका उपयोग जारी रखते हैं, जब तक कि उन्हें भी बैन नहीं मिल जाता। प्रॉक्सी की स्थिति का केंद्रीय लेखा-जोखा के बिना, प्रत्येक सर्वर "अमेरिका को फिर से खोलता है", बेकार में अनुरोधों को बर्बाद करता है।

इन तीन समस्याओं का समाधान - एक समान समन्वय तंत्र को लागू करना: या तो केंद्रीय स्थिति भंडारण (Redis, PostgreSQL, Consul) के माध्यम से, या बिना सर्वरों के बीच रेंज के ओवरलैप के पूर्व निर्धारित पूल का निर्धारण करना।

वितरित पार्सर की आर्किटेक्चर

प्रॉक्सी को विभाजित करने से पहले, क्लस्टर की सामान्य आर्किटेक्चर के साथ तय करना आवश्यक है। दो बुनियादी दृष्टिकोण हैं।

स्थिर योजना (shared-nothing). प्रॉक्सी पूल को पहले से सर्वरों के बीच विभाजित किया जाता है, एक बार प्रारंभ में। प्रत्येक सर्वर को अपना अद्वितीय खंड मिलता है और वह स्वतंत्र रूप से इसके साथ काम करता है, अन्य सर्वरों से संपर्क किए बिना। लाभ - अधिकतम सरलता और विफलता सहिष्णुता: एक सर्वर का गिरना अन्य पर प्रभाव नहीं डालता। हानि - यदि एक सर्वर पर आधे प्रॉक्सी बैन हो जाते हैं, तो वह पड़ोसी से ताजे IP "उधार" नहीं ले सकता।

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

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

सर्वरों के बीच प्रॉक्सी पूल को विभाजित करने के तरीके

चलिए उन विशिष्ट एल्गोरिदम पर विचार करते हैं, जिन्हें पूल को विभाजित करने के लिए लागू किया जा सकता है।

सरल मोड्यूल विभाजन (round-robin sharding). प्रॉक्सी को 0 से N-1 तक क्रमांकित किया गया, सर्वर नंबर i उन सभी प्रॉक्सी को लेता है, जिनका index % सर्वरों_की_संख्या == i है। सरल, लेकिन सर्वरों को जोड़ने या हटाने के मामले में यह खराब सहनशीलता दिखाता है - मशीनों की संख्या में परिवर्तन होने पर लगभग पूरा पूल फिर से वितरित किया जाता है।

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

केंद्रीकृत ब्रोकर के साथ लॉकिंग. प्रॉक्सी को सर्वर के साथ सख्ती से सुरक्षित करने के बजाय, सभी सर्वर एक सामान्य सेवा (Redis, RabbitMQ) से "फ्री" प्रॉक्सी का अनुरोध करते हैं, जो इसे अस्थायी लॉक के साथ जारी करता है। इसका उपयोग करने के बाद, प्रॉक्सी को पूल में वापस कर दिया जाता है। यह सबसे लचीला विकल्प है, विशेष रूप से यदि सर्वरों पर लोड असमान है।

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

विधि	जटिलता	स्केलिंग के प्रति सहनशीलता	कब लागू करें
मोड्यूल के अनुसार विभाजन	कम	खराब	फिक्स्ड संख्या सर्वर
स्थिर हैशिंग	मध्यम	अच्छा	क्लस्टर का ऑटो-स्केलिंग
केंद्रीकृत ब्रोकर	मध्यम-उच्च	उत्कृष्ट	असमान लोड, उच्च ट्रैफिक
डोमेन के अनुसार विभाजन	कम	मध्यम	एक साथ कई प्लेटफार्मों की पार्सिंग

Redis पर प्रॉक्सी ब्रोकर का कार्यान्वयन

अधिकांश वितरित पार्सरों के लिए सबसे व्यावहारिक विकल्प - Redis पर केंद्रीकृत ब्रोकर है। Redis उपयुक्त है क्योंकि यह तेज है, परमाणु संचालन का समर्थन करता है और "बॉक्स से बाहर" TTL प्रदान करता है। विचार सरल है: सभी उपलब्ध प्रॉक्सी Redis सेट में होती हैं, और जब एक विशिष्ट कार्यकर्ता को प्रॉक्सी जारी की जाती है, तो इसे TTL के साथ एक कुंजी के माध्यम से एक निश्चित समय के लिए लॉक किया जाता है।

नीचे एक कार्यशील उदाहरण है जो Python में redis-py पुस्तकालय के साथ ब्रोकर को लागू करता है। यह लॉक के साथ स्वतंत्र प्रॉक्सी जारी करने, उपयोग के बाद इसे मुक्त करने और प्रॉक्सी को बैन के रूप में चिह्नित करने को लागू करता है।

import redis
import time
import random

r = redis.Redis(host="localhost", port=6379, db=0, decode_responses=True)

PROXY_POOL_KEY = "proxy:pool"       # सभी कार्यशील प्रॉक्सी का सेट
LOCK_PREFIX = "proxy:lock:"         # विशिष्ट प्रॉक्सी के लिए लॉक प्रीफिक्स
BANNED_PREFIX = "proxy:banned:"     # बैन चिह्नित करने का प्रीफिक्स
LOCK_TTL = 30                       # सेकंड, जिसके लिए प्रॉक्सी को लॉक किया जाता है
BAN_TTL = 3600                      # सेकंड, जिसके लिए प्रॉक्सी को बैन माना जाता है

def load_pool(proxy_list):
    """क्लस्टर के प्रारंभ में एक बार प्रॉक्सी की सूची को Redis में लोड करें।"""
    if proxy_list:
        r.sadd(PROXY_POOL_KEY, *proxy_list)

def get_free_proxy(server_id, max_attempts=20):
    """प्रत्येक सर्वर इस फ़ंक्शन को स्वतंत्र प्रॉक्सी प्राप्त करने के लिए कॉल करता है।"""
    candidates = list(r.smembers(PROXY_POOL_KEY))
    random.shuffle(candidates)

    for proxy in candidates[:max_attempts]:
        if r.exists(BANNED_PREFIX + proxy):
            continue
        lock_key = LOCK_PREFIX + proxy
        # यदि प्रॉक्सी स्वतंत्र है तो लॉक को परमाणु रूप से सेट करें
        acquired = r.set(lock_key, server_id, nx=True, ex=LOCK_TTL)
        if acquired:
            return proxy
    return None  # कोई स्वतंत्र प्रॉक्सी नहीं मिली, फॉलबैक की आवश्यकता है

def release_proxy(proxy):
    """सफल अनुरोध के बाद प्रॉक्सी को मुक्त करें।"""
    r.delete(LOCK_PREFIX + proxy)

def mark_banned(proxy):
    """प्रॉक्सी को BAN_TTL सेकंड के लिए बैन के रूप में चिह्नित करें, लॉक को हटा दें।"""
    r.set(BANNED_PREFIX + proxy, 1, ex=BAN_TTL)
    r.delete(LOCK_PREFIX + proxy)
    r.srem(PROXY_POOL_KEY, proxy)  # अस्थायी रूप से पूल से हटा दें

def return_to_pool_if_recovered():
    """नियमित कार्य: उन प्रॉक्सी को वापस करें जिनका बैन समाप्त हो गया है।"""
    for proxy in r.scan_iter(match=BANNED_PREFIX + "*"):
        clean_proxy = proxy.replace(BANNED_PREFIX, "")
        if not r.exists(BANNED_PREFIX + clean_proxy):
            r.sadd(PROXY_POOL_KEY, clean_proxy)

यहाँ मुख्य बिंदु - Redis में SET ... NX EX का उपयोग करना है। यह कमांड परमाणु है: यदि दो सर्वर एक ही समय में एक ही प्रॉक्सी को लॉक करने का प्रयास करते हैं, तो केवल एक ही सफल होगा, दूसरा असफल हो जाएगा और सूची से अगले उम्मीदवार के पास जाएगा। यही है जो सर्वरों के बीच सामान्य पूल तक समानांतर पहुंच के दौरान संघर्षों को समाप्त करता है।

पार्सर के कार्यकर्ता में ब्रोकर का उपयोग करने का उदाहरण:

import requests

def fetch_with_proxy(url, server_id):
    proxy = get_free_proxy(server_id)
    if not proxy:
        raise RuntimeError("पूल में कोई स्वतंत्र प्रॉक्सी नहीं है")

    proxies = {"http": f"http://{proxy}", "https": f"http://{proxy}"}
    try:
        response = requests.get(url, proxies=proxies, timeout=10)
        if response.status_code in (403, 429):
            mark_banned(proxy)
        else:
            release_proxy(proxy)
        return response
    except requests.exceptions.RequestException:
        mark_banned(proxy)
        raise

यह योजना आसानी से स्केल की जा सकती है - आप 10 या 50 सर्वर जोड़ सकते हैं, वे सभी एक ही Redis इंस्टेंस से संपर्क करेंगे, और IP पर संघर्ष नहीं होगा, क्योंकि लॉक भंडारण के स्तर पर परमाणु है, न कि एकल सर्वर के स्तर पर।

स्टिकी-सेशन्स और कार्यों के लिए प्रॉक्सी का बंधन

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

इसके लिए स्टिकी-सेशन का विचार पेश किया गया है: प्रॉक्सी को एक ही अनुरोध के बजाय एक विशेष कार्य या उपयोगकर्ता सत्र के साथ उसके जीवनकाल के लिए बंधित किया जाता है। Redis में, इसे session:{task_id} -> proxy के प्रकार की एक अलग कुंजी के माध्यम से लागू किया जाता है, जिसका TTL अपेक्षित सत्र की अवधि के बराबर होता है।

SESSION_PREFIX = "proxy:session:"
SESSION_TTL = 600  # सत्र के लिए 10 मिनट

def get_sticky_proxy(task_id, server_id):
    existing = r.get(SESSION_PREFIX + task_id)
    if existing:
        return existing
    proxy = get_free_proxy(server_id)
    if proxy:
        r.set(SESSION_PREFIX + task_id, proxy, ex=SESSION_TTL)
    return proxy

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

बैन का प्रबंधन और क्लस्टर में रोटेशन

वितरित प्रणाली में, यह महत्वपूर्ण है कि प्रॉक्सी के बैन की जानकारी तुरंत सभी सर्वरों के लिए उपलब्ध हो, न कि केवल उस सर्वर के लिए जिसने यह बैन प्राप्त किया। ऊपर दिए गए उदाहरण में, यह कार्य mark_banned फ़ंक्शन द्वारा किया जाता है - जैसे ही एक सर्वर लक्षित साइट से 403 या 429 को रिकॉर्ड करता है, प्रॉक्सी Redis में सामान्य पूल से हटा दी जाती है, और अन्य सर्वर स्वचालित रूप से इसे प्राप्त करना बंद कर देते हैं।

बैन का निर्धारण करने के लिए, केवल HTTP प्रतिक्रिया कोड का विश्लेषण करना पर्याप्त नहीं है, बल्कि पृष्ठ की सामग्री का भी विश्लेषण करना चाहिए - कुछ साइटें 200 OK लौटाती हैं, लेकिन वास्तविक सामग्री के बजाय कैप्चा या स्टब के साथ। बैन का पता लगाने की लॉजिक आमतौर पर इस प्रकार होती है:

• HTTP कोड 403, 429, 503 - ब्लॉक या रेट-लिमिट का स्पष्ट संकेत।
• कैप्चा या प्रमाणीकरण पृष्ठ पर रीडायरेक्ट - अनुरोध के बाद URL की जांच।
• उत्तर के आकार में अचानक कमी या अपेक्षित CSS चयनकर्ताओं की अनुपस्थिति - स्टब का संकेत।
• कनेक्शन टाइमआउट - अक्सर इसका मतलब है कि प्रॉक्सी ने पूरी तरह से प्रतिक्रिया देना बंद कर दिया है।

बैन को रिकॉर्ड करने के बाद, केवल प्रॉक्सी को हमेशा के लिए पूल से हटाने के बजाय, इसे "क्वारंटाइन" में रखना समझदारी है जिसमें TTL होता है (जैसे उदाहरण में - BAN_TTL), जिसके बाद प्रॉक्सी स्वचालित रूप से पूल में लौट आती है। मार्केटप्लेस और सोशल मीडिया पर कई ब्लॉक अस्थायी होते हैं और 30-60 मिनट में हटा दिए जाते हैं।

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

प्रॉक्सी पूल के स्वास्थ्य की निगरानी

कई सर्वरों के क्लस्टर में, सामान्य चित्र को खोना आसान है: वर्तमान में कितनी प्रॉक्सी सक्रिय हैं, कितनी बैन में हैं, प्रत्येक की औसत प्रतिक्रिया गति क्या है। बिना निगरानी के, यह समझना कठिन है कि पार्सिंग धीमी क्यों हो गई है - क्या एक सर्वर गिर गया है, या जीवित प्रॉक्सी समाप्त हो गई हैं।

न्यूनतम मेट्रिक्स का सेट, जिसे Redis या अलग डेटाबेस में इकट्ठा करना चाहिए:

• वर्तमान में पूल में सक्रिय प्रॉक्सी की संख्या।
• बैन की गई प्रॉक्सी की संख्या और उनके पुनर्प्राप्ति का औसत समय।
• अंतिम N अनुरोधों के लिए प्रत्येक प्रॉक्सी की औसत प्रतिक्रिया समय।
• सर्वरों और समग्र पूल के लिए सफल अनुरोधों का प्रतिशत (success rate)।
• लोड का वितरण - प्रत्येक सर्वर ने कितने अनुरोधों को एक निश्चित अवधि में संसाधित किया।

इन मेट्रिक्स को विज़ुअलाइज़ करने के लिए, इन्हें Prometheus में एक सरल एक्सपोर्टर के माध्यम से स्टोर करना सुविधाजनक होता है, जो हर मिनट Redis से डेटा पढ़ता है और इसे Grafana के लिए समझने योग्य प्रारूप में देता है। इससे किसी विशेष भूगोल या प्रॉक्सी के प्रकार के लिए सफलताओं की दर में गिरावट को जल्दी से देखना संभव हो जाता है और इससे पहले कि पार्सर पूरी तरह से रुक जाए, पूल में नए IP जोड़ना संभव हो जाता है।

नए सर्वरों को क्लस्टर में लॉन्च करते समय बैन के पीक को अलग से मॉनिटर करना चाहिए - यदि 3 से 6 सर्वरों के स्केलिंग के दौरान बैन का प्रतिशत अचानक बढ़ जाता है, तो संभावना है कि समस्या शार्डिंग में है: नए सर्वर पुराने के साथ प्रॉक्सी रेंज में ओवरलैप करने लगे हैं। यह पहला संकेत है कि आपको मोड्यूल के अनुसार विभाजन से स्थिर हैशिंग पर स्विच करने की आवश्यकता है।

वितरित पार्सर को लॉन्च करने की चेक-लिस्ट

कई सर्वरों पर पार्सर को तैनात करने से पहले, निम्नलिखित बिंदुओं पर जाएं:

• पूल के समन्वय तंत्र का चयन किया गया है: स्थिर विभाजन, स्थिर हैशिंग या Redis पर केंद्रीकृत ब्रोकर।
• प्रॉक्सी के लिए परमाणु लॉकिंग लागू की गई है, जो एक ही IP के दो सर्वरों द्वारा एक साथ उपयोग को समाप्त करती है।
• लॉकिंग और बैन के लिए TTL सेट किया गया है, ताकि प्रॉक्सी "लॉक्ड" स्थिति में हमेशा के लिए न फंस जाए जब कार्यकर्ता गिर जाए।
• उपयोगकर्ता सत्र के अनुकरण की आवश्यकता वाले कार्यों के लिए, पूरे कार्यकाल के लिए स्टिकी प्रॉक्सी का बंधन सेट किया गया है।
• बैन का पता लगाने के लिए HTTP कोड के साथ-साथ उत्तर की सामग्री के आधार पर सेट किया गया है।
• क्लस्टर में सक्रिय और बैन की गई प्रॉक्सी के लिए सफलताओं की दर की निगरानी सक्षम की गई है।
• प्रॉक्सी पूल को कार्यों के प्रकार के अनुसार विभाजित किया गया है: डेटा सेंटर IP - कम संवेदनशील अनुरोधों के लिए, रेसिडेंशियल या मोबाइल प्रॉक्सी - सत्रों के लिए, जहाँ वास्तविक उपयोगकर्ता के समानता महत्वपूर्ण है।
• स्थिति भंडारण (Redis) पर लोड की जांच की गई है - यदि सर्वरों की संख्या अधिक है और अनुरोधों की आवृत्ति अधिक है, तो एक Redis क्लस्टर की आवश्यकता हो सकती है।

निष्कर्ष

कई सर्वरों पर पार्सर के संक्रमण के दौरान संघर्षों का मुख्य कारण प्रॉक्सी पूल की स्थिति के बारे में एकल सत्य के स्रोत की अनुपस्थिति है। जैसे ही एक केंद्रीकृत ब्रोकर परमाणु लॉकिंग के साथ प्रकट होता है (Redis या समान भंडारण पर), IP की डुप्लिकेशन और बैन के असमंजस की समस्या अपने आप समाप्त हो जाती है। आगे, आपके क्लस्टर के आकार के अनुसार शार्डिंग रणनीति का चयन करना बाकी है: निश्चित संख्या के सर्वरों के लिए सरल विभाजन पर्याप्त है, जबकि गतिशील रूप से बढ़ती अवसंरचना के लिए बेहतर है कि स्थिर हैशिंग को तुरंत लागू किया जाए।

यदि आपका वितरित पार्सर मार्केटप्लेस या सोशल मीडिया के साथ काम करता है, जहाँ एकल सत्र के स्तर पर ट्रैफ़िक की विश्वसनीयता महत्वपूर्ण है, तो कार्यों के प्रकार के अनुसार पूल को विभाजित करना समझदारी है: बड़े पैमाने पर कैटलॉग स्कैनिंग के लिए डेटा सेंटर प्रॉक्सी उपयुक्त हैं, जबकि उपयोगकर्ता के व्यवहार के अनुकरण के लिए रेसिडेंशियल प्रॉक्सी वास्तविक घरेलू IP के साथ, जो संवेदनशील एंटी-फ्रॉड सिस्टम में बैन के प्रतिशत को काफी कम करती हैं।