13 अक्टूबर 2026 को, वेब डेटा संग्रह की दुनिया की पांच कंपनियों ने घोषणा की कि वे अब Source के तहत काम कर रही हैं। इसमें Oxylabs, Decodo (पूर्व में Smartproxy), Webshare, ScrapingBee और Honeygain शामिल हैं। कई खरीदार वर्षों से इन ब्रांडों में से "मुख्य" और "बैकअप" प्रदाता का चयन कर रहे थे, उन्हें प्रतिस्पर्धी मानते हुए। अब आधिकारिक रूप से: यह एक समूह है। आइए समझते हैं कि क्या एकीकृत हुआ है, यह सभी के लिए क्यों महत्वपूर्ण है जो बैकअप प्रॉक्सी पूल रखते हैं, और एक घंटे में कैसे जांचें कि आपका बैकअप प्रदाता वास्तव में मुख्य प्रदाता से स्वतंत्र है।
क्या हुआ: पांच ब्रांड, एक मालिक
Proxyway के अनुसार, Source खुद को "डेटा पारिस्थितिकी तंत्र" के रूप में वर्णित करता है। इसका मुख्य ढांचा विल्नियस में स्थित है और, जैसा कि Proxyway नोट करता है, यह Tesonet के व्यापक पारिस्थितिकी तंत्र का हिस्सा है। समूह द्वारा अपने बारे में दिए गए आंकड़े:
- 800 से अधिक कर्मचारी, जिनमें 350 से अधिक डेवलपर्स और इंजीनियर शामिल हैं;
- 180 से अधिक पेटेंट और 215 ट्रेडमार्क;
- वितरित प्रणालियों में प्रति सेकंड 1.5 मिलियन अनुरोध;
- AI एजेंटों और AI उत्पादों की मांग पिछले वर्ष में लगभग चार गुना बढ़ गई है।
समूह Oxylabs से विकसित हुआ। जुलाई 2026 में, Oxylabs ने Warburg Pincus से $130 मिलियन जुटाए, जिसका मूल्यांकन $3.6 बिलियन था, यह उसका पहला बाहरी राउंड था। ब्रांडों के बीच संबंध वर्षों से विकसित हो रहे थे: Webshare को Oxylabs ने 2022 में खरीदा, ScrapingBee को 2025 में, और Honeygain 2021 से Oxylabs के लिए रेजिडेंट IP की खनन में मुख्य भागीदार के रूप में कार्य कर रहा है। Decodo का Oxylabs के साथ संबंध, जैसा कि Wilson's Media लिखता है, Source के लॉन्च से पहले सार्वजनिक रूप से इतना स्पष्ट नहीं था। एक महत्वपूर्ण विवरण: Source के CEO विटौटास साविटकास ने मार्च 2026 तक Decodo का नेतृत्व किया।
ब्रांड कैसे बाजार को साझा करते हैं
- Oxylabs — बड़े व्यवसाय और AI प्रयोगशालाएँ;
- Decodo — मध्यम खंड;
- ScrapingBee — डेवलपर्स के लिए API;
- Webshare — उन्नत एकल उपयोगकर्ता और छोटे टीमें;
- Honeygain — एक ऐप जो सामान्य लोगों को उनके उपकरणों के "अतिरिक्त" ट्रैफ़िक के लिए भुगतान करता है।
औपचारिक रूप से ब्रांड स्वतंत्र रहते हैं: अपनी टीमें, मूल्य, उत्पाद और ग्राहक। Source का कहना है कि वह खुद कुछ नहीं बेचता, बल्कि पेटेंट, खरीद, भर्ती और अनुपालन को केंद्रीकृत करता है। क्या ब्रांडों के IP पूल या बुनियादी ढांचे साझा हैं, न तो Source और न ही विशेष प्रकाशन बताते हैं। लेकिन खरीदार के लिए यही मुख्य प्रश्न है।
यह आपके बैकअप पूल को क्यों प्रभावित करता है
बैकअप प्रॉक्सी पूल की आवश्यकता तब होती है जब मुख्य काम करना बंद कर देता है: लक्षित वेबसाइट ने प्रदाता के उपनेट्स को प्रतिबंधित कर दिया, प्रदाता में तकनीकी समस्या है, शर्तें या मूल्य बदल गए हैं। बैकअप के परिदृश्यों और आर्किटेक्चर के बारे में हमने जब बैकअप प्रॉक्सी पूल वास्तव में खातों को बचाते हैं में विस्तार से लिखा है। वहां मुख्य नियम सरल है: बैकअप किसी अन्य प्रदाता से होना चाहिए और आदर्श रूप से अन्य IP स्रोतों से।
एक ही मालिक के तहत एकीकरण इस नियम को अधिक जटिल बनाता है, जितना लगता है। तीन स्तर की निर्भरता हैं, और वेबसाइट पर ब्रांड केवल पहले को दर्शाता है:
- कानूनी। कौन कंपनी का मालिक है और किसके निर्णय मूल्य, नियम और सेवा की किस्मत को निर्धारित करते हैं।
- IP का स्रोत। रेजिडेंट पते कहां से आते हैं: अपना ऐप या SDK, Honeygain जैसी साझेदारी कार्यक्रम, या किसी अन्य प्रदाता से थोक खरीद।
- बुनियादी ढांचा। गेटवे, जिनके माध्यम से ट्रैफ़िक जाता है, उनकी होस्टिंग और नेटवर्क।
दो "विभिन्न" प्रदाता किसी भी स्तर पर मेल खा सकते हैं। यदि IP का स्रोत मेल खाता है, तो लक्षित वेबसाइट का एंटी-बॉट, जिसने इन पते को पहचानना सीख लिया है, दोनों पूलों को एक साथ ब्लॉक कर देगा, और बैकअप उस क्षण में बेकार हो जाएगा, जिसके लिए इसे खरीदा गया था।
पूल का मेल बिना सामान्य मालिक के भी हो सकता है
महत्वपूर्ण है कि इस समाचार को साजिश के सिद्धांत में न बदलें। IP का ओवरलैप उन कंपनियों में भी होता है जो किसी भी तरह से संबंधित नहीं हैं: रेजिडेंट प्रॉक्सी का बाजार बहु-स्तरीय है, और कई ब्रांड बड़े थोक नेटवर्क के पते को फिर से बेचते हैं, और स्वयं नेटवर्क एक ही ऐप और SDK के माध्यम से ट्रैफ़िक खरीदते हैं। इसलिए, केवल "कौन मालिक है" की जांच करना ही नहीं, बल्कि "पते कहां से आते हैं" और "क्या वे वास्तव में ओवरलैप करते हैं" की जांच करना आवश्यक है।
कैसे जांचें कि बैकअप प्रदाता स्वतंत्र है: 5 कदम
जांच में लगभग एक घंटा लगता है और यह कुछ सौ मेगाबाइट ट्रैफ़िक की लागत होती है। इसे तब करें जब बैकअप की आवश्यकता न हो।
कदम 1. कानूनी व्यक्ति और मालिक
दोनों प्रदाताओं के उपयोग की शर्तें (Terms of Service) और गोपनीयता नीति खोलें: वहां कानूनी व्यक्ति, पंजीकरण का देश और पता दिया गया है। फिर — उस देश की कंपनी रजिस्टर और "हमारे बारे में" या प्रेस विज्ञप्तियों का अनुभाग। मेल खाता हुआ पता, एक ही निदेशक या सामान्य समूह का उल्लेख — प्रदाताओं को एक ही आपूर्तिकर्ता मानने का कारण है। स्टेटमेंट में भुगतान विवरण भी देखना फायदेमंद है: यह अक्सर वास्तविक कानूनी व्यक्ति का नाम बताता है, न कि ब्रांड का।
कदम 2. रेजिडेंट IP का स्रोत
समर्थन से सीधे पूछें: "आप रेजिडेंट IP कैसे प्राप्त करते हैं? अपना ऐप, अन्य ऐप में SDK, साझेदार या थोक खरीद?" सामान्य प्रदाता कम से कम सामान्य रूप से जवाब देगा। यदि दोनों एक ही ट्रैफ़िक मोनेटाइजेशन प्रोग्राम का नाम लेते हैं या जवाब से बचते हैं, तो इसे सामान्य स्रोत मानें। यह प्रश्न सुरक्षा के दृष्टिकोण से भी महत्वपूर्ण है: 16 अक्टूबर को GBHackers ने GreyNoise के संदर्भ में एक अभियान का वर्णन किया, जिसमें हमलावरों ने D-Link NAS, वीडियो रिकॉर्डर और SAP NetWeaver में कमजोरियों के माध्यम से अन्य उपकरणों पर वैध ऐप Pawns.app को चुपचाप स्थापित किया और उन्हें व्यावसायिक रेजिडेंट नोड्स में बदल दिया। कम से कम 34 देशों में 143 उपकरणों को लक्षित किया गया। IPRoyal Pawns.app को अपने रेजिडेंट IP के खनन के लिए सीधे भागीदार के रूप में बताता है; इस बीच, प्रकाशन यह स्पष्ट करता है कि अभियान का नेतृत्व किसी भी प्रदाता द्वारा नहीं किया गया था। खरीदार के लिए निष्कर्ष: IP की उत्पत्ति की पारदर्शिता यह भी एक प्रश्न है कि आप कितने साफ पते प्राप्त कर रहे हैं।
कदम 3. आउटगोइंग IP का ओवरलैप
यह मुख्य तकनीकी परीक्षण है। दोनों प्रदाताओं से एक ही देश में रोटेशन लें और 500-1000 अनुरोध करें उस सेवा के लिए, जो आपका IP लौटाती है। सूचियों को सहेजें और तुलना करें:
- सटीक IP का मेल — सामान्य पूल का सीधा संकेत;
- सबनेट्स /24 का मेल — सामान्य स्रोत या सामान्य ऑपरेटरों का संकेत;
- ASN के अनुसार वितरण — यदि दोनों सूचियों में समान अनुपात में एक ही ऑपरेटर नेटवर्क हावी हैं, तो स्रोत संभवतः निकट हैं।
Python में न्यूनतम स्क्रिप्ट:
import requests
def collect(proxy_url, n=500):
ips = set()
for _ in range(n):
try:
r = requests.get("https://api.ipify.org",
proxies={"http": proxy_url, "https": proxy_url},
timeout=15)
ips.add(r.text.strip())
except requests.RequestException:
pass
return ips
a = collect("http://login:[email protected]:port")
b = collect("http://login:[email protected]:port")
net24 = lambda s: {".".join(ip.split(".")[:3]) for ip in s}
print("अनोखे IP:", len(a), len(b))
print("सामान्य IP:", len(a & b))
print("सामान्य /24:", len(net24(a) & net24(b)))प्राप्त पते के लिए ASN को किसी भी IP-भू-स्थान सेवा या स्थानीय डेटाबेस के माध्यम से निर्धारित किया जा सकता है। हमने सामग्री में बताया है कैसे 1000 अनुरोधों में प्रॉक्सी पूल का वास्तविक आकार जांचें। संक्षिप्त नियम: एक बड़े पूल के लिए कुछ प्रतिशत सामान्य /24 एक देश के लिए सामान्य पृष्ठभूमि है, और सटीक IP के दशकों प्रतिशत सामान्य होना वास्तव में एक ही पूल है।
कदम 4. गेटवे और बुनियादी ढांचा
देखें कि दोनों प्रदाताओं के गेटवे होस्ट कहां रेज़ॉल्व होते हैं (कमांड dig या nslookup) और ये पते किन नेटवर्कों के हैं। एक ही होस्टिंग कुछ नहीं साबित करती, लेकिन गेटवे के पते का सामान्य रेंज, समान पोर्ट स्कीम और लॉगिन का प्रारूप, प्रमाणीकरण त्रुटियों पर समान उत्तर — यह संकेत है कि विभिन्न नामों के तहत एक ही प्लेटफ़ॉर्म हो सकता है। इस स्थिति में, गेटवे की तकनीकी समस्या दोनों सेवाओं को तुरंत प्रभावित कर देगी।
कदम 5. संयुक्त प्रतिबंध पर परीक्षण
सबसे व्यावहारिक जांच। एक लक्षित वेबसाइट लें, जहां मुख्य प्रदाता पहले से ही कैप्चा या प्रतिबंधों का सामना कर रहा है, और बैकअप के माध्यम से उसी परिदृश्य को उसी हेडर और ब्राउज़र प्रोफ़ाइल के साथ चलाएं। यदि बैकअप उसी आवृत्ति और उसी चरणों पर प्रतिबंधित होता है, तो इस वेबसाइट के लिए यह बैकअप नहीं है, भले ही मालिक अलग हों। हर महीने परीक्षण दोहराएं: पूल बदलते हैं।
विभिन्न कार्यों के लिए कौन सा बैकअप चुनें
- पार्सिंग और मूल्य निगरानी। IP और गेटवे के स्रोत की स्वतंत्रता सबसे महत्वपूर्ण है। एक समझदारी योजना — दूसरे प्रकार का बैकअप: यदि मुख्य पूल रेजिडेंट प्रॉक्सी है, तो सरल उद्देश्यों के लिए बैकअप डेटा सेंटर प्रॉक्सी हो सकते हैं, और इसके विपरीत।
- मल्टी-खाता और सोशल मीडिया। यहां बैकअप को मुख्य के प्रकार के साथ मेल खाना चाहिए, अन्यथा प्लेटफ़ॉर्म "नेटवर्क प्रोफ़ाइल" में बदलाव देखेगा। मोबाइल परिदृश्यों के लिए, मुख्य पूल में नहीं होने वाले ऑपरेटरों के साथ मोबाइल प्रॉक्सी पर बैकअप रखना तार्किक है।
- SLA के साथ महत्वपूर्ण कार्य। विभिन्न मालिकों और IP की विभिन्न उत्पत्ति के साथ दो प्रदाताओं को रखें और कदम 3 और 5 पर ओवरलैप की जांच कम से कम एक बार तिमाही में करें।
संघटन का और क्या बदलता है
संघटन का एक दूसरा पहलू भी है। समूह का कहना है कि सामान्य आवाज़ "सार्वजनिक वेब डेटा तक जिम्मेदार पहुंच" की रक्षा के लिए आवश्यक है, और Wilson's Media याद दिलाता है कि Oxylabs अक्टूबर 2025 में Reddit द्वारा दायर मुकदमे में उत्तरदाता बना हुआ है, जिसे SerpApi, Perplexity और AWMProxy के साथ दायर किया गया था। ग्राहक के लिए इसका मतलब सरल है: एक ब्रांड के कानूनी और प्रतिष्ठात्मक जोखिम अब पूरे समूह को संभावित रूप से प्रभावित करते हैं। उपयोग की शर्तों, कीमतों और स्वीकार्य उद्देश्यों के बारे में निर्णय भी समन्वयित किए जा सकते हैं।
हालांकि, ब्रांड अभी भी अलग-अलग सेवाओं के रूप में बेचे जाते हैं, और इनमें से किसी का भी उपयोग करने में कोई रोक नहीं है। केवल एक चीज बदलती है: बिना जांच के उन्हें "मुख्य और बैकअप" के रूप में चुनना अब उचित नहीं है।
निष्कर्ष
Source का लॉन्च बैकअप योजना की समीक्षा करने का एक अच्छा अवसर है। ब्रांड का नाम प्रदाता की स्वतंत्रता के बारे में कुछ नहीं कहता: मालिक, IP का स्रोत और बुनियादी ढांचा महत्वपूर्ण हैं। कानूनी व्यक्तियों की जांच करें, पते की उत्पत्ति के बारे में पूछें, आउटगोइंग IP और सबनेट की तुलना करें, संयुक्त प्रतिबंध पर परीक्षण चलाएं। यदि ओवरलैप बड़ा है, तो आपके पास दो प्रदाता नहीं हैं, बल्कि एक ही है जिसके दो खाते हैं। यह जानना बेहतर है कि अब, जब मुख्य पूल गिर जाएगा।