Residential или datacenter proxy: как выбрать по целевому сайту?

Оба типа работают по одним и тем же протоколам (HTTP и SOCKS5) и одинаково настраиваются на клиенте. Разница в том, какой сети принадлежит выходной IP. В этом руководстве разобрано, как сайты видят эту разницу, как соотносить успешность, скорость и стоимость, приведена таблица выбора по типу цели и гибридная схема, в которой оба типа работают вместе. В примерах используется шлюз WeProxy gw.weproxy.com.tr:8989, а USER и PASSWORD — заглушки для учётных данных.

Чем residential proxy отличается от datacenter proxy?

Каждый IP-адрес принадлежит автономной системе (AS). AS — это набор IP-блоков с единой политикой маршрутизации, который идентифицируется номером ASN (RFC 1930). Residential IP находятся в AS интернет-провайдеров, обслуживающих домашних абонентов и малый бизнес. Datacenter IP находятся в AS хостинговых, облачных и CDN-компаний.

Из этого происхождения следуют три практических вывода. Datacenter-выходы стоят на мощных серверных каналах, поэтому задержка низкая, а пропускная способность высокая. Residential-выходы проходят через реальное домашнее подключение, поэтому они медленнее, а отдельные выходы могут отключиться во время соединения. Зато residential IP — это тот же тип адреса, который сайт видит в обычном трафике посетителей, поэтому на целях с защитой от ботов он вызывает меньше подозрений.

Residential-пул WeProxy формируется через партнёрскую SDK-программу на основе согласия: участники подключаются осознанно и могут выйти в любой момент. Datacenter-пул состоит из IPv4-адресов серверной инфраструктуры.

Как сайты распознают datacenter IP?

Сайт оценивает тип входящего IP, сверяя его с несколькими источниками. Эта проверка может выполняться на сетевом уровне, ещё до загрузки страницы. Поэтому сайт, который блокирует тип IP целиком, может отклонить datacenter-запрос уже на первом ответе, как бы аккуратно ни были настроены заголовки.

ASN и диапазоны IP

Самый простой метод — запрос ASN. Если AS, к которой относится IP, принадлежит хостинговой или облачной компании, запрос помечается как «datacenter». Крупные облачные провайдеры публикуют свои диапазоны IP в машиночитаемом виде, а WAF и CDN предлагают эти списки и коммерческие IP-базы как готовые правила. Имена в обратном DNS (PTR) с server, vps или cloud указывают в ту же сторону.

Как выглядит IP, можно проверить самостоятельно: инструмент IP lookup показывает ASN, провайдера и местоположение. Введите выходной IP прокси, и вы примерно увидите то, что целевой сайт видит при первом взгляде.

Репутация IP и плотность подсети

Второй уровень — репутация. IP и подсети, ранее связанные со спамом, перебором паролей или агрессивным сканированием, теряют баллы. Datacenter-блоки состоят из последовательных адресов, поэтому, увидев плотный трафик из одного блока /24, сайт может ограничить весь блок, а не отдельный IP. Residential-адреса распределены по разным провайдерам и блокам, поэтому такие массовые ограничения затрагивают их меньше.

Сигналы помимо IP

Тип IP — не единственный сигнал. Сайты также смотрят на отпечаток TLS-рукопожатия, порядок и согласованность HTTP-заголовков, поведение cookies и темп запросов. Несоответствие между отпечатком ОС в стеке TCP/IP (значения TTL и окна, которые читают пассивные инструменты вроде p0f) и User-Agent тоже может быть отмечено. Residential IP не спасёт плохо настроенный клиент, а datacenter IP не всегда означает блокировку.

Как сравнить успешность, скорость и стоимость?

Три метрики связаны между собой. Быстрый, но часто блокируемый выход тратит и время, и трафик на каждую неудачную попытку. Поэтому сравнивать нужно не по одному запросу, а по успешному результату.

Считайте стоимость успешного запроса

Правильная единица сравнения — «стоимость одного успешного запроса». Приблизительная формула: стоимость = (MB на запрос × цена за MB) / доля успешных. Заблокированные запросы тоже расходуют трафик, потому что WeProxy считает использование как сумму отправленного и полученного трафика. Страница CAPTCHA или тело ошибки тоже входят в эту сумму.

Пример расчёта: страница товара весит 1,5 MB. Datacenter-выход успешно выполняет 40% запросов к цели, residential — 95%. На стороне datacenter одна успешная страница в среднем обходится в 1,5 / 0,40 = 3,75 MB трафика; на стороне residential — 1,5 / 0,95 ≈ 1,6 MB. Что дешевле, теперь определяют цены за GB; актуальные пакеты указаны на страницах продуктов. На цели, где успешность datacenter близка к 95%, datacenter почти всегда выигрывает.

Платить за GB или за IP?

Модель тарификации стоит рассматривать отдельно от типа IP. В WeProxy пакеты rotating datacenter и rotating residential оплачиваются за GB; купленные GB остаются на балансе без ограничения по сроку, пока не будут израсходованы. Пакеты static datacenter и static residential оплачиваются за IP на период, и ограничения трафика на этих IP нет.

Правило простое. Оплата за GB подходит для задач, распределённых по множеству IP и целей, когда известен трафик на страницу. Если непрерывный трафик большого объёма идёт через несколько фиксированных IP, оплата за IP делает расходы предсказуемыми. Ни одна из моделей не ограничивает потоки и одновременные сессии.

Что выбрать для какой цели? Таблица решений

Таблица ниже — отправная точка, а не жёсткое правило. Два сайта одной категории могут использовать очень разную защиту; окончательное решение должен дать небольшой тест.

Подробности о поисковых системах и SEO — на странице SEO proxy, архитектура сбора данных — на странице web scraping. Фиксированная идентичность для каждого аккаунта в соцсетях разобрана на странице социальные сети.

Что меняется в задачах с сессией?

При входе в аккаунт, работе с корзиной или многошаговыми формами IP не должен меняться в течение сессии. В rotating residential-пуле можно закрепить один и тот же выходной IP на срок до 24 часов, добавив идентификатор сессии к имени пользователя. Если нужна одна идентичность на дни или недели, лучше подходит static residential IP (сессии до 30 дней). Когда использовать sticky, а когда rotating, подробно описано в руководстве sticky vs rotating.

Гибридная стратегия: сначала datacenter, при необходимости residential

Во многих задачах scraping самый эффективный путь — использовать оба типа вместе. Запрос сначала уходит через datacenter. Если ответ несёт признак блокировки, тот же запрос повторяется через residential. Успешность отслеживается по доменам, и домены, где datacenter стабильно проваливается, сразу направляются на residential.

Признак блокировки — не только код статуса. 403 и 429 — явные сигналы, но некоторые сайты возвращают страницу CAPTCHA или пустой список товаров с кодом 200. Поэтому надёжнее проверять в теле ответа ожидаемый маркер содержимого (название товара, поле цены). Что означают коды и на каком уровне они возникают, смотрите в руководстве по кодам ошибок прокси.

Пример на Python ниже реализует эту логику. В панели для каждого пакета отображаются свои данные подключения; замените заглушки DC_USER и RES_USER на имя пользователя и пароль соответствующего пакета.

from urllib.parse import urlparse
import requests

DC_PROXY = "http://DC_USER:[email protected]:8989"
RES_PROXY = "http://RES_USER:[email protected]:8989"

BLOCK_MARKERS = ("captcha", "access denied", "unusual traffic")
stats = {}  # домен -> [успешные через datacenter, всего через datacenter]


def is_blocked(response, must_contain):
    if response.status_code in (403, 429):
        return True
    body = response.text.lower()
    if any(marker in body for marker in BLOCK_MARKERS):
        return True
    return must_contain.lower() not in body


def fetch(url, must_contain):
    domain = urlparse(url).hostname
    ok, total = stats.setdefault(domain, [0, 0])
    # Сначала datacenter: первые 50 запросов или пока успешность выше 80%
    if total < 50 or ok / total >= 0.8:
        stats[domain][1] += 1
        try:
            r = requests.get(url, proxies={"http": DC_PROXY, "https": DC_PROXY},
                             timeout=(10, 30))
            if not is_blocked(r, must_contain):
                stats[domain][0] += 1
                return r, "datacenter"
        except requests.exceptions.RequestException:
            pass
    # Блокировка или ошибка: повтор через residential
    r = requests.get(url, proxies={"http": RES_PROXY, "https": RES_PROXY},
                     timeout=(10, 45))
    return r, "residential"

Timeout на чтение для residential больше, потому что ответы через домашнее подключение могут приходить дольше. Пороговые значения (50 запросов, 80%) настраивайте под цель. На доменах, где datacenter остаётся ниже 80%, каждая неудачная попытка тратит лишний трафик; в этот момент прямой переход на residential может оказаться дешевле — проверьте по формуле выше.

Вторая форма гибридной схемы — разделение труда. Шаги обнаружения, такие как sitemap, списки категорий и страницы результатов поиска, загружаются через datacenter, а защищённые страницы товаров или профилей — через residential. Если шаги обнаружения составляют большую часть запросов, такое разделение заметно сокращает residential-трафик.

Смена типа выхода после блокировки не должна становиться способом нарушить условия использования цели. Автоматизация должна работать с открытой частью сайта, которую разрешает цель, и в рамках правил WeProxy о допустимом использовании. Если собираемые данные содержат персональные данные, применимость GDPR или KVKK нужно оценивать отдельно.

Как проверить, какой тип работает?

Проверка оценки из таблицы на вашей собственной цели занимает несколько минут. Отправьте через каждый тип 50–100 запросов на один и тот же URL с одинаковыми заголовками и запишите три значения: успешность (пришло ли ожидаемое содержимое), медианное время ответа и объём загрузки на запрос.

# Узнайте выходной IP, затем проверьте его ASN и тип в инструменте IP lookup
curl -s -x "http://USER:[email protected]:8989" https://api.ipify.org
echo

# Измерьте код статуса, время и объём загрузки на цели
curl -s -o /dev/null \
  -w "%{http_code} %{time_total}s %{size_download}B\n" \
  -x "http://USER:[email protected]:8989" \
  https://example.com/

Сначала запишите свой IP без прокси с помощью инструмента My IP и убедитесь, что IP через прокси отличается. Работоспособность прокси в целом можно отдельно проверить в proxy checker. Если успешность datacenter близка к residential, оставайтесь на datacenter; если разница заметна, решайте по формуле стоимости выше.

Повторяйте тест несколько раз в течение дня, а не в пределах одного часа. Некоторые сайты ужесточают правила в определённые часы или после определённого числа запросов. Новые аккаунты получают 1 GB бесплатного residential-трафика для проверки сети, этого достаточно для небольшого сравнения.

Где в этом выборе ISP и мобильные прокси?

Между этими двумя типами и за их пределами есть ещё два варианта. ISP proxy — статические IP, зарегистрированные в сети провайдера, но работающие на серверной инфраструктуре; это промежуточная точка между доверием residential и скоростью datacenter. Мобильные прокси используют IP операторов 4G/5G и чаще выбираются для мобильных приложений и социальных платформ. Полное сравнение четырёх типов — в руководстве по residential, мобильным, datacenter и ISP прокси, а разница между ISP и datacenter — в сравнении ISP proxy и datacenter proxy.

Какой продукт WeProxy подходит для какого сценария?

Четыре продукта закрывают четыре угла двух осей выбора (тип IP и ротация):

• Rotating Datacenter IPv4 Proxy: 10M+ IPv4-адресов, таргетинг по ASN и городу, оплата за GB. Для массового сбора данных с незащищённых целей и как первый уровень гибридной схемы.
• Rotating Residential IPv4 Proxy: пул 100M+ IP, таргетинг по городу и ZIP, sticky- и rotating-сессии. Для поисковых систем, крупных интернет-магазинов и как резервный уровень гибридной схемы.
• Static Datacenter IPv4 Proxy: выделенный IP, фиксированные ASN и локация, безлимитная пропускная способность. Для whitelist в API и автоматизации, обращающейся к вашим собственным серверам.
• Static Residential IPv4 Proxy: фиксированный IP от провайдера, сессии до 30 дней, безлимитный трафик на IP. Для работы с аккаунтами, которым долго нужна одна и та же идентичность.

Все пакеты поддерживают HTTP и SOCKS5; аутентификация — по логину и паролю или через IP whitelist. Выбирайте по цели, а не по продукту: сначала измерьте, как цель реагирует на datacenter IP, затем используйте тот тип или гибридную комбинацию обоих, которая даёт наименьшую стоимость успешного запроса.