Пойманы на 99%: трещина в 50 миллисекунд, которая выдаёт даже лучшие резидентные прокси

Мы реселлим всю линейку hellworld.io — 14 резидентных брендов, 3 мобильных пула, Static ISP и два безлимитных тарифа. Поэтому, когда мы пишем об обнаружении резидентных прокси, рамки разговора должны быть честными: у каждого нашего клиента, который полагается на резидентные выходы, есть прямой интерес к этой статье. Мы не будем делать вид, что это не так. Цель этого материала — не отпугнуть кого-то от резидентных прокси. Она в том, чтобы объяснить конкретный серверный метод обнаружения, который тихо, но точно работает, и разобрать, что он значит — а чего не значит — для того, как эти инструменты применяются в 2026 году.

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

До поры до времени. Академическая статья 2022 года BADPASS: Bots Taking ADvantage of Proxy as a Service (ISPEC 2022, авторы — исследователи из EURECOM, KAUST и Amadeus) показала, что соединения резидентных прокси можно идентифицировать с точностью 99,01% с помощью единственного приёма: сравнить TCP RTT и TLS RTT одного и того же HTTPS-соединения на стороне сервера, прямо во время рукопожатия.

Без JavaScript. Без баз репутации IP. Без библиотек фингерпринтинга. Только два числа задержки, которые у сервера и так уже есть.

Если вы держите высокоценный сайт, который скрапят, — это один из самых чистых опубликованных методов обнаружения. Если вы запускаете скраперы, его стоит понять, потому что у провайдеров, которым вы сегодня доверяете, эта проблема почти наверняка есть у всех.

Почему резидентные прокси стало так трудно блокировать

Дата-центр прокси отфильтровать легко. AWS, GCP, Azure, DigitalOcean — их ASN, блоки IP, шаблоны имён хостов, сигнатуры TLS-стека и история злоупотреблений хорошо известны. Большинство коммерческих сервисов обнаружения ботов автоматически помечают трафик из этих диапазонов.

Резидентные прокси — совсем другой зверь. Выходной IP — это реальная домашняя широкополосная линия, мобильное устройство или потребительское железо, завербованное в пул провайдера прокси (иногда через SDK, вшитый в бесплатное приложение). Для сервера назначения он неотличим от обычного платящего клиента в Огайо, Токио или Сан-Паулу.

Именно поэтому платформы электронной коммерции, продажи билетов, туризма и авиакомпаний постоянно проигрывают скраперам в игре в кошки-мышки — и не случайно один из авторов статьи работает в Amadeus, мировом гиганте IT-инфраструктуры для туризма. Это не оторванные от жизни академики, теоретизирующие на тему «а что если боты начнут использовать прокси». Их годами лупят ровно этим.

Традиционное обнаружение ботов сильно опирается на репутацию IP, частоту запросов, фингерпринт устройства и поведенческие следы. Резидентные прокси почти полностью размывают сигнал репутации IP. Возникает естественный вопрос: может ли сервер вычислить, что перед ним прокси, вообще не глядя на IP — только по самому соединению?

Статья отвечает: да, измерив два RTT.

Ключевая идея: резидентные прокси разрывают TCP, но не TLS

Это самая изящная часть статьи.

Когда пользователь подключается к сайту напрямую, картина простая. Браузер открывает TCP-соединение прямо к серверу, а затем поверх этого TCP-соединения согласует TLS. И трёхстороннее рукопожатие TCP, и рукопожатие TLS происходят между одними и теми же двумя точками. Измеренные сервером время приёма-передачи TCP и время приёма-передачи TLS должны быть почти идентичны — они измеряют один и тот же путь.

Резидентные прокси работают иначе. Большинство из них устроены по архитектуре «backconnect»: клиент подключается к суперпрокси провайдера, тот выбирает резидентный шлюз, и уже шлюз открывает TCP-соединение к серверу назначения. С точки зрения сервера TCP-собеседник — это шлюз, а не исходный клиент.

Но HTTPS-прокси обычно пробрасывают TLS-сессию как непрозрачный туннель, а не терминируют и переустанавливают её. Это значит, что TLS-сессия по-прежнему согласуется сквозным образом (end-to-end) между исходным клиентом и сервером назначения. Шлюз лишь перекидывает зашифрованные байты.

Это порождает структурное рассогласование:

• TCP RTT измеряет расстояние от шлюза до сервера.
• TLS RTT измеряет расстояние от реального клиента через суперпрокси и шлюз до сервера.

Для прямого соединения эти два числа совпадают. Для соединения через резидентный прокси TLS RTT почти всегда заметно больше TCP RTT, потому что пакеты TLS-рукопожатия проходят всю цепочку прокси, а пакеты TCP-рукопожатия — нет.

В одной фразе: резидентный прокси разделяет транспортный уровень надвое, но TLS всё ещё притворяется сквозным, и у этой лжи есть измеримая цена в задержке.

Почему этот метод обнаружения особенно опасен

У серверных измерений задержки есть четыре свойства, которые делают их крайне неудобными для пользователей прокси:

1. Он работает полностью на сервере. Никакого участия клиента, никакого диалога согласия, никакого исполнения JavaScript. Если вы можете снимать тайминги пакетов на балансировщике или origin-сервере, вы можете его реализовать.

2. Блокировка JavaScript не помогает. Многие системы обнаружения ботов прогоняют пробы на стороне браузера — WebRTC, попытки подключения к localhost, причуды Performance API. Продвинутые боты отключают JavaScript, работают в headless-режиме или вырезают эти пробы. Этот метод обходит всё перечисленное, потому что нужный сигнал снимается ещё до того, как доставлен хоть какой-то HTML.

3. Ему безразлична репутация IP. Резидентные IP постоянно ротируются. Новые появляются ежедневно. Любое обнаружение, основанное на пометке конкретных IP как «плохих», обречено на вечную гонку с отставанием. Этот метод вообще игнорирует IP — он смотрит только на структуру соединения.

4. Обнаружение происходит до ответа. Разрыв RTT проявляется уже во время самого TLS-рукопожатия. Вы можете решить отклонить, замедлить или ограничить соединение ещё до отдачи первого байта HTML. С точки зрения защиты это огромное преимущество — вы не даёте скраперу ничего вытащить, пока сами принимаете решение.

Внутри эксперимента

Авторов не устроила одна теория. Они построили глобальный испытательный стенд, чтобы доказать, что разрыв реален и устойчив:

• 4 коммерческих резидентных провайдера были куплены: Bright Data (бывший Luminati), Oxylabs, ProxyRack и Smartproxy. 40–50 ГБ трафика на провайдера в месяц.
• 22 сервера, распределённые по миру через Amazon Lightsail (16) и Azure (6). Среди локаций — Индия, Австралия, Япония, Германия, Ирландия, Канада, восток и запад США, ЮАР, ОАЭ и Бразилия.
• Каждый сервер выступал и клиентом, и сервером. С каждого сервера команда отправляла HTTPS GET на каждый другой сервер: один раз напрямую и по одному разу через каждого из четырёх провайдеров прокси — пять путей на каждую пару.
• Кампания шла 110 дней (с 12 января по 1 мая 2022 года). Версия TLS на стороне сервера ежедневно чередовалась между TLS 1.2 и TLS 1.3, так что датасет покрывает обе.

После отсева битых захватов, шума сканеров и коротких простоев у них осталось 92 712 461 полная запись соединения — около 95% из почти 98 миллионов попыток соединения. Это серьёзный датасет.

Как измеряются два RTT

TCP RTT измеряется просто. Сервер отправляет SYN-ACK и ждёт финальный ACK от клиента. Время между этими двумя событиями и есть TCP RTT с точки зрения сервера. На прямом соединении это путь «клиент — сервер». На соединении через резидентный прокси это путь «шлюз — сервер».

TLS RTT измеряется чуть хитрее. Авторы выбирают пару записей TLS-рукопожатия, где сервер отправил нечто, на что он обязан дождаться ответа клиента, прежде чем продолжать. Для TLS 1.2 это примерно ServerHelloDone → ClientKeyExchange; для TLS 1.3 — после ServerHello и зашифрованных сообщений рукопожатия → клиентский change_cipher_spec / второй пакет. Конкретные записи тут не главное — принцип в том, чтобы «найти точку, где сервер что-то отправляет и обязан дождаться ответа, прежде чем продолжить».

Независимо от версии TLS, этот круговой обмен проходит весь TLS-путь: клиент → суперпрокси → шлюз → сервер. На прямом соединении это просто клиент → сервер.

Затем вычисляется одно число: TLS RTT − TCP RTT. Маленькое значение — соединение прямое. Стабильно большое — значит, есть лишний хоп, которого TCP-уровень не видит.

Результаты беспощадны

Результаты статьи показывают распределение TLS RTT − TCP RTT для прямых и проксированных соединений, и эти две совокупности почти не пересекаются.

• 97% прямых соединений дают разницу ≤ 20 ms.
• Ту же ось для проксированных соединений приходится рисовать в 100× шире — от 0 до 2000 ms, — потому что разрывы для прокси рутинно составляют сотни миллисекунд.

Некоторые соединения дают отрицательную разницу (TCP RTT больше TLS RTT). Так бывает, когда SYN-ACK или финальный ACK случайно задерживается джиттером, а последующие TLS-пакеты — нет. Это редкость:

• Прямые: 2,9% отрицательных
• Bright Data: 0,9%
• Oxylabs: 1,8%
• ProxyRack: 0,2%
• Smartproxy: 1,4%

Джиттер существует. Но разделимость он не разрушает.

50 ms: порог, который ловит 99%

Авторы остановились на 50 ms как практическом пороге. Они выбрали его, отдельно проанализировав, насколько сильно RTT внутри одного соединения естественно колеблется: в 53% соединений разброс RTT (макс минус мин) в пределах одного соединения составляет ≤ 50 ms. Так что 50 ms вмещает нормальный джиттер и при этом остаётся намного ниже типичного разрыва для прокси.

С этим правилом — «если TLS RTT − TCP RTT > 50 ms, помечаем как резидентный прокси» — результаты такие:

Метрика	Значение
Доля ложноположительных	0,04%
Доля ложноотрицательных	1,93%
Общая точность	99,01%

Доля ложноположительных в 0,04% означает, что почти ни один легитимный пользователь не попадает в облаву — это критично, потому что ошибочно записать в боты реального клиента куда дороже, чем пропустить пару скраперов. Доля ложноотрицательных в 1,93% означает, что почти ни один проксированный трафик не проскакивает мимо.

Даже худший случай — это 92,78%

Дотошные исследователи возразят: а что, если самое первое измерение TCP RTT случайно окажется максимумом на этом соединении? Это раздуло бы TCP RTT, сжало бы разрыв и пропустило бы часть проксированного трафика.

Авторы прогнали этот худший случай в стресс-тесте. Примерно у 29% соединений первый TCP RTT равен максимуму соединения. Если предположить, что каждое из них неудачно перекошено, можно было бы ожидать самую плохую возможную производительность обнаружения. С тем же порогом 50 ms:

• Ложноположительные: 0,01%
• Ложноотрицательные: 9,68%
• Точность: 92,78%

Даже при пессимистичных предположениях о джиттере это всё равно очень сильный классификатор. Реальные продакшен-развёртывания не столкнутся с «худшим случаем везде»; реальность гораздо ближе к 99%, чем к 92%.

«А если шлюз близко к серверу?»

Естественный контрход провайдера прокси — маршрутизировать шлюз как можно ближе к назначению, сжимая TCP RTT между шлюзом и сервером. Если этот хоп крошечный, разве разрыв не схлопнется?

Авторы проверили ровно те сценарии, где это должно бить сильнее всего. Для Bright Data, с множеством шлюзов в регионах ARIN/RIPE, они выделили соединения Виргиния ↔ Виргиния. Для Oxylabs и Smartproxy, с сильным присутствием в LACNIC, они смотрели на маршруты внутри Бразилии. Для ProxyRack, с заметными пулами AFRINIC, они использовали маршруты внутри ЮАР.

Результаты устояли. С порогом 50 ms доля ложноотрицательных в некоторых из этих подмножеств «лучший шанс уклониться» фактически упала примерно до 0,78% — потому что даже когда шлюз локальный, клиент и суперпрокси таковыми не являются, и TLS-путь по-прежнему охватывает всю цепочку.

Теоретический злоумышленник, который контролировал бы клиент, суперпрокси, шлюз и сервер в пределах одной агломерации, мог бы схлопнуть разрыв. Коммерческое планирование резидентных прокси так не работает; логика ротации не заботится о географической близости к цели.

Важно: этот метод не ловит VPN и NAT

Здесь важно внимательно прочитать статью. Цель обнаружения именно такова: соединения, которые разрывают сквозной TCP-уровень, но сохраняют сквозной TLS-уровень. Backconnect-резидентные прокси подходят под этот шаблон. Подходит и часть проброса в стиле SSH.

Стандартный NAT, IPsec VPN, WireGuard и подобные VPN-технологии обычно не терминируют TCP-соединение. Они переписывают IP, инкапсулируют пакеты, гонят их через туннели — но TCP-сессия по-прежнему сквозная между исходным клиентом и сервером. В итоге TCP RTT и TLS RTT выстраиваются так же, как на прямом соединении.

Если вы пытаетесь обнаружить в целом «находится ли пользователь за туннелем», этот метод — не тот инструмент. Для обнаружения VPN и NAT нужен анализ MTU, репутация IP, базовая калибровка задержек или фингерпринтинг протоколов.

Но для конкретного коммерческого рынка резидентных прокси — а именно он непропорционально отвечает за credential stuffing, скальпинг и масштабный скрапинг — этот метод опасно эффективен.

Оговорки, которые стоит знать

Статья не относится к публикациям топ-уровня USENIX/CCS/NDSS/IMC; ISPEC — уважаемая, но площадка второго эшелона в безопасности. В экспериментах используется собственная клиент-серверная инфраструктура авторов, а не продакшен-трафик реального сайта-защитника. Цель обнаружения узкая — резидентные прокси с разрывом TCP и прозрачным проходом TLS. И если провайдер перепроектирует свою архитектуру (например, начнёт терминировать TLS на шлюзе), сигнал обнаружения может ослабнуть.

Ни одна из этих оговорок не отменяет результат. Они лишь говорят, что метод — не серебряная пуля для любого вида прокси-трафика, а только для самого популярного.

Что это значит, если вы защищаете сайт

Если вы держите целевой сайт, это один из самых рентабельных и дешёвых методов обнаружения, которые можно добавить. Реализация в основном сводится к: снять метки времени на SYN-ACK/ACK и на выбранных записях TLS-рукопожатия, вычислить разрыв, поставить порог 50 ms и подать результат в свой существующий risk-score.

Действовать на основе одного этого сигнала не обязательно — сочетание его с rate-limiting, фингерпринтингом устройства и поведенческими сигналами дополнительно снижает долю ложноположительных. Но как один сигнал среди нескольких, «TLS RTT минус TCP RTT превышает 50 ms» обладает высокой информативностью, его почти невозможно подделать на стороне клиента, и он наблюдаем на каждом TLS-соединении.

Чтобы понять, как выглядят остальные уровни обнаружения в 2026 году, наш полевой гид Anti-Bot Landscape 2026 разбирает шесть anti-bot-вендоров, которые с наибольшей вероятностью стоят перед любой целью, до которой вы пытаетесь добраться.

Что это значит, если вы используете резидентные прокси

Неудобная правда: каждый коммерческий провайдер резидентных прокси, следующий стандартной архитектуре «backconnect с прозрачным проходом TLS», обнаруживается этим методом. Сюда входят почти все премиум-провайдеры, включая четырёх протестированных.

Путей смягчения немного:

• Архитектурное изменение на стороне провайдера. Провайдер мог бы терминировать TLS на шлюзе и переустанавливать его до цели, убирая структурную асимметрию. Для этого прокси должен выступать как «человек посередине» (man-in-the-middle), что ломает проверку сертификата и неприемлемо для серьёзных пользователей.
• Свести всю цепочку в одно место. Если клиент, суперпрокси, шлюз и сервер находятся в одной агломерации, разрыв сжимается. Коммерческое планирование на основе пулов этого не позволяет.
• Использовать типы соединений, которых этот метод не видит. Выходы на базе VPN и NAT не затрагиваются. Есть компромиссы — у них свои векторы обнаружения.
• Диверсифицировать типы соединений и смириться с тем, что часть трафика будет помечена. Это реалистичный ответ для большинства команд. Не каждому запросу нужен резидентный выход. Стратегически смешивайте static ISP, мобильные и резидентные, снижайте частоту запросов на соединение и проектируйте рабочий процесс так, чтобы помеченный трафик стоил вам повторной попытки, а не постоянной блокировки.

Это не статья в духе «резидентные прокси мертвы». Они по-прежнему работают. Они по-прежнему обходят большинство нынешних продакшен-защит, потому что большинство продакшен-защит пока не реализуют обнаружение на основе RTT. Суть в том, что у структурного преимущества резидентных прокси — выглядеть в точности как реальный пользователь — есть измеримая, фундаментальная трещина, которой может воспользоваться любой, кто всерьёз занимается защитой.

Если хотите глубже подумать, когда резидентные имеют смысл против мобильных, ISP или безлимитных, Дерево решений по уровням прокси проводит по компромиссам в разрезе сценариев использования. А за «голыми» цифрами производительности по провайдерам — 14 протестированных брендов, самый актуальный бенчмарк из тех, что мы публиковали.

Любой, кто строит серьёзную инфраструктуру против скрапинга начиная с 2026 года, выучит этот приём. Планируйте соответственно.

---

Источник: Casino, F., Patsakis, C., Lecharlier, B., & Ricci, V. (2022). BADPASS: Bots Taking ADvantage of Proxy as a Service. ISPEC 2022.