Source: Oxylabs, Decodo, Webshare под одним владельцем

13 октября 2026 года пять компаний из мира сбора веб-данных объявили, что теперь работают под общим зонтом Source. В него вошли Oxylabs, Decodo (бывший Smartproxy), Webshare, ScrapingBee и Honeygain. Многие покупатели годами выбирали из этих брендов «основного» и «запасного» поставщика, считая их конкурентами. Теперь официально: это одна группа. Разбираемся, что именно объединилось, почему это касается всех, кто держит резервный пул прокси, и как за час проверить, что ваш запасной провайдер действительно независим от основного.

Что произошло: пять брендов, один владелец

По данным Proxyway, Source описывает себя как «экосистему данных». Головная структура базируется в Вильнюсе и, как отмечает Proxyway, сама входит в более широкую экосистему Tesonet. Цифры, которые группа приводит о себе:

более 800 сотрудников, из них свыше 350 разработчиков и инженеров;
более 180 патентов и 215 товарных знаков;
1,5 млн запросов в секунду в распределённых системах;
спрос со стороны ИИ-агентов и ИИ-продуктов вырос за год примерно вчетверо.

Группа выросла из Oxylabs. В июле 2026 года Oxylabs привлекла $130 млн от Warburg Pincus при оценке $3,6 млрд, это был её первый внешний раунд. Связи между брендами складывались годами: Webshare Oxylabs купила в 2022 году, ScrapingBee в 2025-м, а Honeygain с 2021 года служит для Oxylabs основным партнёром по добыче резидентных IP. Связь Decodo с Oxylabs, как пишет Wilson's Media, до запуска Source была публично не так очевидна. Показательная деталь: генеральный директор Source Витаутас Савицкас до марта 2026 года руководил Decodo.

Как бренды делят рынок

Oxylabs — крупный бизнес и ИИ-лаборатории;
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 описал кампанию, в которой злоумышленники через уязвимости в NAS D-Link, видеорегистраторах и SAP NetWeaver тайно ставили на чужие устройства легальное приложение Pawns.app и превращали их в коммерческие резидентные узлы. Под удар попали как минимум 143 устройства в 34 странах. 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 остаётся ответчиком по иску Reddit, поданному в октябре 2025 года вместе с SerpApi, Perplexity и AWMProxy. Для клиента это означает простую вещь: юридические и репутационные риски одного бренда теперь потенциально касаются всей группы. Решения о правилах использования, ценах и допустимых целях тоже могут начать согласовываться.

При этом бренды по-прежнему продаются как отдельные сервисы, и ничего не мешает пользоваться любым из них. Меняется только одно: выбирать два из них как «основной и запасной» без проверки больше не стоит.

Вывод

Запуск Source — хороший повод пересмотреть схему резервирования. Название бренда ничего не говорит о независимости поставщика: значение имеют владелец, источник IP и инфраструктура. Проверьте юрлица, спросите о происхождении адресов, сравните выходные IP и подсети, прогоните совместный тест на бан. Если пересечение большое, у вас не два провайдера, а один с двумя счетами. Лучше узнать это сейчас, чем в день, когда основной пул упадёт.