Резидентные vs дата-центр IP

Почему простой ASN-детектор не работает

Выходной IP резидентного прокси по определению это реальное устройство пользователя на реальном потребительском ASN: Comcast, BT, Deutsche Telekom, Reliance Jio, Ростелеком. ASN самого выходного IP не говорит ровным счётом ничего. Большинство коммерческих детекторов помечают такие адреса как clean именно потому, что останавливаются на проверке ASN.

Сигнал должен приходить откуда-то ещё: с прокси-бэкбонов (компании, которые агрегируют резидентные выходы), из поведенческих аномалий (RTT-mismatch, разные географии под одним user-agent), либо из публикуемых самими прокси-вендорами списков выходов.

Сигналы, которые действительно работают

1. 1. Репутация бэкбона

   Вендоры резидентных прокси публикуют свои клиентские IP это gateway, к которым подключаются клиенты до того, как трафик уйдёт через бытовое устройство. Мы отслеживаем бэкбоны: Webshare, Bright Data, IPRoyal, Oxylabs, NetNut, Smartproxy, Soax. Совпадение здесь это прямое доказательство использования резидентного прокси.

2. 2. RTT-mismatch (SNITCH)

   Резидентный прокси добавляет дополнительный хоп между клиентом и вашим сервером. RTT TLS-handshake заметно выше, чем TCP RTT (прокси терминирует TLS от лица пользователя). Метод SNITCH из работы NDSS 2025 формализует эту разницу, мы используем её как отдельный сигнал.

3. 3. Несоответствие гео и языка

   Браузер, заявляющий timezone Asia/Tokyo с резидентного IP в Мексике, это сильный признак прокси. Реальные путешественники с таким сочетанием встречаются редко, а массовое несоответствие почти всегда означает, что прокси-агрегатор раздаёт случайных клиентов через случайные выходы.

4. 4. Несоответствие JA3/JA4-отпечатка

   SDK резидентных прокси нередко переписывают TLS ClientHello в процессе ретрансляции. Получившийся JA4 не совпадает с тем, что выдал бы стоковый браузер на заявленной комбинации ОС/браузера.

5. 5. Velocity и поведенческие аномалии

   Один клиент резидентного прокси может прокручивать сотни выходных IP в минуту. С точки зрения вашего сервера: один и тот же user-agent, одни и те же session cookies, но новый IP на каждом запросе. Это не реальный пользователь.

6. 6. BGP single-homing у «резидентных» IP

   Настоящие потребительские ISP мульти-хомные (несколько upstream-пиров). Некоторые операторы резидентных прокси используют небольшие ASN, подключённые ровно к одному транзит-провайдеру. Это структурная подсказка: IP не настоящий бытовой широкополосный.

Как это выглядит в ответе нашего API

При обнаружении резидентного прокси ответ содержит сигнал residential_proxy_backbone в массиве signals[], имя бэкбона в vpn_provider_sources[] и вердикт в категории suspicious или vpn_likely в зависимости от подтверждения из других источников.

{
  "verdict": "vpn_likely",
  "score": 0.62,
  "signals": [
    {
      "type": "residential_proxy_backbone",
      "weight": 0.40,
      "matched": true,
      "detail": "Listed as a Webshare residential gateway"
    }
  ],
  "ip_info": {
    "vpn_provider": "Webshare",
    "vpn_provider_sources": ["Webshare residential backbone"]
  }
}

Дата-центровые IP (более простая задача рядом)

Дата-центровые IP помечать заметно проще. ASN это хостинг (AWS, GCP, OVH, DigitalOcean, Vultr), классификация PeeringDB обычно «Network Services» или «Content», а reverse DNS часто всё выдаёт (например ec2-XX-XX-XX-XX.compute-1.amazonaws.com). Мы комбинируем агрегатор X4BNet datacenter (41 735 CIDR), классификацию PeeringDB, ручные оверрайды по облачным провайдерам и правила на уровне ASN. Уровень ложных срабатываний в этом слое ниже 1%.