منبع: Oxylabs، Decodo، Webshare تحت یک مالک

۱۳ اکتبر ۲۰۲۶، پنج شرکت از دنیای جمع‌آوری داده‌های وب اعلام کردند که اکنون تحت یک چتر مشترک Source فعالیت می‌کنند. این شرکت‌ها شامل Oxylabs، Decodo (که قبلاً Smartproxy نامیده می‌شد)، Webshare، ScrapingBee و Honeygain هستند. بسیاری از خریداران سال‌ها از این برندها به عنوان تأمین‌کننده «اصلی» و «پشتیبان» استفاده می‌کردند و آن‌ها را رقبای یکدیگر می‌دانستند. اکنون به‌طور رسمی: این یک گروه واحد است. بیایید بررسی کنیم که چه چیزی به هم پیوسته است، چرا این موضوع برای همه کسانی که یک استخر پشتیبان پروکسی دارند مهم است و چگونه می‌توان در یک ساعت بررسی کرد که آیا تأمین‌کننده پشتیبان شما واقعاً مستقل از تأمین‌کننده اصلی است یا خیر.

چه اتفاقی افتاد: پنج برند، یک مالک

به گفته Proxyway، Source خود را به عنوان «اکوسیستم داده‌ها» توصیف می‌کند. ساختار اصلی آن در ویلنیوس مستقر است و همان‌طور که Proxyway اشاره می‌کند، خود بخشی از اکوسیستم وسیع‌تری به نام Tesonet است. ارقامی که این گروه درباره خود ارائه می‌دهد:

بیش از ۸۰۰ کارمند، از جمله بیش از ۳۵۰ توسعه‌دهنده و مهندس؛
بیش از ۱۸۰ پتنت و ۲۱۵ علامت تجاری؛
۱.۵ میلیون درخواست در ثانیه در سیستم‌های توزیع‌شده؛
تقاضا از سوی عوامل و محصولات هوش مصنوعی در یک سال تقریباً چهار برابر افزایش یافته است.

این گروه از Oxylabs رشد کرده است. در ژوئیه ۲۰۲۶، Oxylabs مبلغ ۱۳۰ میلیون دلار از Warburg Pincus جذب کرد و ارزش آن ۳.۶ میلیارد دلار تخمین زده شد که این اولین دور سرمایه‌گذاری خارجی آن بود. ارتباطات بین برندها سال‌ها شکل گرفته است: Webshare در سال ۲۰۲۲ توسط Oxylabs خریداری شد، ScrapingBee در سال ۲۰۲۵ و Honeygain از سال ۲۰۲۱ به عنوان شریک اصلی Oxylabs در استخراج IP‌های مقیم عمل می‌کند. ارتباط Decodo با Oxylabs، همان‌طور که Wilson's Media می‌نویسد، قبل از راه‌اندازی Source به‌طور عمومی چندان واضح نبود. نکته جالب: مدیرعامل Source، ویتوتاس ساویسکاس، تا مارس ۲۰۲۶ مدیر Decodo بود.

چگونه برندها بازار را تقسیم می‌کنند

Oxylabs — کسب‌وکار بزرگ و آزمایشگاه‌های هوش مصنوعی؛
Decodo — بخش متوسط؛
ScrapingBee — API برای توسعه‌دهندگان؛
Webshare — افراد پیشرفته و تیم‌های کوچک؛
Honeygain — اپلیکیشنی که به افراد عادی برای «ترافیک اضافی» دستگاه‌هایشان پول می‌دهد.

به‌طور رسمی برندها مستقل باقی می‌مانند: تیم‌ها، قیمت‌ها، محصولات و مشتریان خود را دارند. Source اعلام می‌کند که خود هیچ چیزی نمی‌فروشد، بلکه پتنت‌ها، خریدها، استخدام و انطباق را متمرکز می‌کند. آیا استخرهای IP یا زیرساخت مشترکی بین برندها وجود دارد، نه Source و نه نشریات تخصصی گزارش نمی‌دهند. اما برای خریدار، این سوال اصلی است.

چرا این موضوع به استخر پشتیبان شما مربوط می‌شود

استخر پشتیبان پروکسی در صورتی نیاز است که تأمین‌کننده اصلی از کار بیفتد: سایت هدف زیرشبکه‌های تأمین‌کننده را مسدود کرده است، تأمین‌کننده دچار حادثه شده، شرایط یا قیمت‌ها تغییر کرده‌اند. ما در بررسی زمانی که استخرهای پروکسی پشتیبان واقعاً حساب‌ها را نجات می‌دهند به تفصیل درباره سناریوها و معماری پشتیبان نوشته‌ایم. قانون اصلی آنجا ساده است: پشتیبان باید از تأمین‌کننده دیگری باشد و ایده‌آل این است که از منابع IP متفاوتی باشد.

ادغام تحت یک مالک این قانون را پیچیده‌تر از آنچه به نظر می‌رسد می‌کند. سه سطح وابستگی وجود دارد و برند در وب‌سایت فقط سطح اول را منعکس می‌کند:

حقوقی. چه کسی مالک شرکت است و تصمیمات او قیمت‌ها، قوانین و سرنوشت سرویس را تعیین می‌کند.
منبع IP. IP‌های مقیم از کجا می‌آیند: اپلیکیشن خود، SDK در اپلیکیشن‌های دیگر، برنامه‌های همکاری مانند Honeygain، یا خرید عمده از تأمین‌کننده دیگر.
زیرساخت. دروازه‌هایی که ترافیک از آن‌ها عبور می‌کند، میزبانی آن‌ها و شبکه‌ها.

دو تأمین‌کننده «مختلف» می‌توانند در هر یک از این سطوح مشترک باشند. اگر منبع IP مشترک باشد، ضد ربات سایت هدف که یاد گرفته این آدرس‌ها را شناسایی کند، هر دو استخر را به‌طور همزمان مسدود می‌کند و پشتیبان در لحظه‌ای که برای آن خریداری شده است، بی‌فایده خواهد بود.

همپوشانی استخرها ممکن است بدون مالک مشترک نیز اتفاق بیفتد

مهم است که این خبر را به تئوری توطئه تبدیل نکنید. همپوشانی IP در شرکت‌هایی که هیچ ارتباطی با یکدیگر ندارند نیز دیده می‌شود: بازار پروکسی‌های مقیم به‌صورت چندسطحی سازمان‌دهی شده است و بسیاری از برندها آدرس‌ها را از شبکه‌های عمده‌فروشی بزرگ خریداری می‌کنند و خود شبکه‌ها ترافیک را از طریق یکسانی از اپلیکیشن‌ها و SDK‌ها خریداری می‌کنند. بنابراین، باید نه تنها «چه کسی مالک است» را بررسی کنید، بلکه «آدرس‌ها از کجا می‌آیند» و «آیا آن‌ها در عمل همپوشانی دارند» را نیز بررسی کنید.

چگونه بررسی کنیم که تأمین‌کننده پشتیبان مستقل است: ۵ مرحله

بررسی حدود یک ساعت طول می‌کشد و هزینه‌ای معادل چند صد مگابایت ترافیک دارد. این کار را قبل از نیاز به پشتیبان انجام دهید.

مرحله ۱. شخصیت حقوقی و مالک

شرایط استفاده (Terms of Service) و سیاست حفظ حریم خصوصی هر دو تأمین‌کننده را باز کنید: در آنجا شخصیت حقوقی، کشور ثبت و آدرس ذکر شده است. سپس به ثبت شرکت‌های آن کشور و بخش «درباره شرکت» یا اطلاعیه‌های مطبوعاتی مراجعه کنید. آدرس مشترک، مدیران یکسان یا اشاره به گروه مشترک — دلیلی برای در نظر گرفتن تأمین‌کنندگان به عنوان یک تأمین‌کننده است. همچنین مفید است که به توصیف پرداخت در صورت‌حساب نگاه کنید: این معمولاً شخصیت حقوقی واقعی را به جای برند نام می‌برد.

مرحله ۲. منبع IP‌های مقیم

مستقیماً از پشتیبانی بپرسید: «چگونه IP‌های مقیم را به‌دست می‌آورید؟ اپلیکیشن خود، SDK در اپلیکیشن‌های دیگر، شرکا یا خرید عمده؟» یک تأمین‌کننده عادی حداقل به‌طور کلی پاسخ خواهد داد. اگر هر دو یک برنامه مشترک برای کسب درآمد از ترافیک را نام ببرند یا از پاسخ فرار کنند، منبع را مشترک در نظر بگیرید. این سوال بی‌اهمیت نیست و از نظر امنیتی نیز مهم است: در ۱۶ اکتبر، GBHackers به نقل از GreyNoise کمپینی را توصیف کرد که در آن مجرمان از طریق آسیب‌پذیری‌ها در NAS D-Link، دوربین‌های مداربسته و SAP NetWeaver به‌طور مخفیانه اپلیکیشن قانونی Pawns.app را بر روی دستگاه‌های دیگر نصب کرده و آن‌ها را به گره‌های مقیم تجاری تبدیل کردند. حداقل ۱۴۳ دستگاه در ۳۴ کشور تحت تأثیر قرار گرفتند. IPRoyal Pawns.app را به‌عنوان شریک مستقیم خود در استخراج IP‌های مقیم می‌نامد؛ در حالی که، همان‌طور که نشریه تأکید می‌کند، هیچ داده‌ای وجود ندارد که نشان دهد این کمپین توسط هر یک از تأمین‌کنندگان هدایت شده است. نتیجه‌گیری برای خریدار: شفافیت در منبع IP همچنین به این سوال مربوط می‌شود که آدرس‌هایی که دریافت می‌کنید چقدر پاک هستند.

مرحله ۳. همپوشانی IP‌های خروجی

این مهم‌ترین تست فنی است. از هر دو تأمین‌کننده روتیشن در یک کشور مشابه بگیرید و بین ۵۰۰ تا ۱۰۰۰ درخواست به سرویسی که IP شما را برمی‌گرداند ارسال کنید. لیست‌ها را ذخیره کرده و مقایسه کنید:

همپوشانی IP‌های دقیق — نشانه مستقیم یک استخر مشترک؛
همپوشانی زیرشبکه‌ها /۲۴ — نشانه منبع مشترک یا اپراتورهای مشترک؛
توزیع بر اساس 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("زیرشبکه‌های مشترک /۲۴:", len(net24(a) & net24(b)))

ASN برای آدرس‌های به‌دست‌آمده را می‌توان با هر سرویس جغرافیایی IP یا پایگاه داده محلی تعیین کرد. چگونه به‌درستی تعداد آدرس‌های منحصر به فرد در نمونه‌گیری را تفسیر کنیم، ما در مقاله چگونه اندازه واقعی استخر پروکسی را با ۱۰۰۰ درخواست بررسی کنیم بررسی کرده‌ایم. قانون کوتاه: چند درصد از زیرشبکه‌های مشترک /۲۴ در یک استخر بزرگ، پس‌زمینه‌ای طبیعی برای یک کشور است، در حالی که ده‌ها درصد از IP‌های دقیق مشترک عملاً یک استخر هستند.

مرحله ۴. دروازه‌ها و زیرساخت

ببینید که میزبان‌های دروازه‌های هر دو تأمین‌کننده به کجا حل می‌شوند (دستورات dig یا nslookup) و این آدرس‌ها به کدام شبکه‌ها تعلق دارند. یک میزبانی مشابه هنوز هیچ چیزی را اثبات نمی‌کند، اما دامنه‌های مشترک آدرس‌های دروازه، الگوهای مشابه پورت و فرمت ورود، پاسخ‌های مشابه به خطاهای تأیید هویت — همه این‌ها نشانه‌هایی هستند که ممکن است زیر یک پلتفرم با نام‌های مختلف قرار داشته باشند. در این صورت، خرابی دروازه هر دو سرویس را به‌طور همزمان از کار می‌اندازد.

مرحله ۵. تست برای مسدودسازی مشترک

این مهم‌ترین بررسی عملی است. یک سایت هدف را انتخاب کنید که تأمین‌کننده اصلی در آنجا قبلاً CAPTCHA یا مسدودسازی را تجربه کرده است و همان سناریو را با همان هدرها و پروفایل مرورگر از طریق پشتیبان اجرا کنید. اگر پشتیبان با همان فرکانس و در همان مراحل مسدود شود، برای این سایت پشتیبان نیست، حتی اگر مالکین متفاوت باشند. این تست را هر ماه تکرار کنید: استخرها تغییر می‌کنند.

چه پشتیبانی برای وظایف مختلف انتخاب کنیم

جمع‌آوری و نظارت بر قیمت‌ها. مهم‌ترین چیز استقلال منبع IP و دروازه‌ها است. یک طرح منطقی — پشتیبان از نوع دیگری: اگر استخر اصلی پروکسی‌های مقیم باشد، پشتیبان برای اهداف ساده می‌تواند از نوع دیتاسنتر باشد و بالعکس.
چند حساب و شبکه‌های اجتماعی. در اینجا پشتیبان باید از نظر نوع با اصلی همخوانی داشته باشد، در غیر این صورت پلتفرم تغییر «پروفایل» شبکه را مشاهده خواهد کرد. برای سناریوهای موبایل منطقی است که پشتیبان را بر روی پروکسی‌های موبایل با اپراتورهایی که در استخر اصلی وجود ندارند، نگه دارید.
وظایف بحرانی با SLA. دو تأمین‌کننده با مالکیت‌های مختلف و منبع IP متفاوت را نگه دارید و حداقل هر سه ماه یک‌بار همپوشانی را با مراحل ۳ و ۵ بررسی کنید.

چه چیز دیگری با ادغام تغییر می‌کند

ادغام همچنین یک جنبه دیگر دارد. گروه اعلام می‌کند که صدای مشترک برای او برای حفاظت از «دسترسی مسئولانه به داده‌های وب عمومی» ضروری است، و Wilson's Media یادآوری می‌کند که Oxylabs همچنان پاسخگوی شکایت Reddit است که در اکتبر ۲۰۲۵ به همراه SerpApi، Perplexity و AWMProxy ارائه شده است. برای مشتری، این به معنای یک چیز ساده است: ریسک‌های حقوقی و شهرت یک برند اکنون به‌طور بالقوه شامل کل گروه می‌شود. تصمیمات درباره قوانین استفاده، قیمت‌ها و اهداف مجاز نیز ممکن است شروع به هماهنگی کنند.

با این حال، برندها همچنان به‌عنوان خدمات جداگانه فروخته می‌شوند و هیچ چیزی مانع استفاده از هر یک از آن‌ها نمی‌شود. تنها چیزی که تغییر می‌کند: انتخاب دو تا از آن‌ها به‌عنوان «اصلی و پشتیبان» بدون بررسی دیگر منطقی نیست.

نتیجه‌گیری

راه‌اندازی Source — یک فرصت خوب برای بازنگری در طرح پشتیبانی است. نام برند هیچ چیزی درباره استقلال تأمین‌کننده نمی‌گوید: مالک، منبع IP و زیرساخت اهمیت دارند. شخصیت‌های حقوقی را بررسی کنید، درباره منبع آدرس‌ها بپرسید، IP‌های خروجی و زیرشبکه‌ها را مقایسه کنید و تست مشترک برای مسدودسازی را انجام دهید. اگر همپوشانی زیاد باشد، شما دو تأمین‌کننده ندارید، بلکه یک تأمین‌کننده با دو حساب دارید. بهتر است این موضوع را اکنون بدانید تا در روزی که استخر اصلی از کار بیفتد.