Детекция прокси давно вышла за рамки простой проверки по базам данных IP-адресов. Современные антибот-системы — Cloudflare, DataDome, PerimeterX, Akamai Bot Manager — строят многоуровневые профили клиента, сверяя десятки сигналов одновременно. Понимание этих механизмов полезно с двух сторон: разработчикам, которые строят защиту, и тем, кто легально тестирует собственные системы или работает с публичными данными в рамках допустимых сценариев.
Статья разбирает технический стек детекции: от IP-репутации и TLS-фингерпринта до поведенческого анализа и WebRTC-утечек. В каждом блоке — механизм детекции и способ его учёта при выборе инфраструктуры.
Статья разбирает технический стек детекции: от IP-репутации и TLS-фингерпринта до поведенческого анализа и WebRTC-утечек. В каждом блоке — механизм детекции и способ его учёта при выборе инфраструктуры.
Уровень 1. IP-репутация и ASN-анализ
Первый и самый грубый фильтр — проверка IP-адреса по базам репутации. Сайт сравнивает входящий адрес с несколькими источниками:
- Базы датацентровых ASN (Autonomous System Number — идентификатор сети провайдера): Amazon AWS, Google Cloud, Hetzner, DigitalOcean имеют публично известные диапазоны. Запрос с адреса из AS16509 (Amazon) — мгновенный сигнал к дополнительной проверке.
- Базы известных proxy-провайдеров: IP-ranges коммерческих прокси-сетей периодически попадают в такие списки через краулеры и отчёты.
- PTR-записи (обратный DNS): адреса с PTR-записями вроде proxy.example.com, exit.tor.network, datacenter-1.hosting.de однозначно идентифицируют себя.
- Геолокационное несоответствие: если IP зарегистрирован в Германии, а заголовок Accept-Language: ru-RU — несоответствие фиксируется.
Резидентские прокси (residential proxy) обходят этот уровень структурно: их адреса принадлежат обычным домашним провайдерам — Comcast, Rostelecom, Orange. В базах репутации они числятся как обычные пользователи, PTR-записи — стандартные потребительские, ASN — жилой провайдер.
Когда я тестировал обход детекции на нескольких публичных SaaS-сервисах с жёсткими антибот-системами, для чистоты эксперимента взял пул резидентских адресов от node-proxy.io — провайдер предоставляет адреса через реальные домашние соединения. На уровне IP-проверки все запросы проходили без триггеров: ASN соответствовал жилым провайдерам, PTR-записи — стандартные потребительские, геолокация — корректная.
Уровень 2. TLS-фингерпринт (JA3/JA4)
Это один из наиболее технически интересных методов детекции, который большинство пользователей прокси игнорируют — и зря.
При установке TLS-соединения клиент отправляет ClientHello — пакет с параметрами: поддерживаемые cipher suites (наборы алгоритмов шифрования), расширения TLS, группы эллиптических кривых, алгоритмы подписи. Разные клиенты формируют разные ClientHello. Из этих параметров вычисляется хэш — JA3-фингерпринт.
Chrome 120 имеет один JA3, Firefox 121 — другой, curl — третий, Python requests — четвёртый. Антибот-система на стороне сервера видит HTTP-заголовок User-Agent: Mozilla/5.0 Chrome/120 — но одновременно получает JA3, характерный для Python-библиотеки. Несоответствие — сигнал к блокировке.
Структура JA3-хэша строится из следующих полей ClientHello:
SSLVersion, Ciphers, Extensions, EllipticCurves, EllipticCurvePointFormats
Все поля конкатенируются через запятые, группы разделяются дефисом, результат — MD5-хэш строки. JA3S аналогичен, но строится по ServerHello.
JA4 (следующее поколение) добавляет версию TLS, количество расширений, ALPN (Application-Layer Protocol Negotiation — согласование протокола прикладного уровня: h2, http/1.1), что делает фингерпринт ещё устойчивее.
Как это учитывать: прокси-сервер сам по себе не меняет TLS-фингерпринт клиента — он работает на сетевом уровне, а TLS-рукопожатие происходит между клиентом и сервером (или между прокси и сервером при HTTPS CONNECT). Если прокси терминирует TLS (SSL-инспекция), то сервер видит JA3 прокси, а не браузера — что немедленно детектируется. Корректная схема при HTTPS CONNECT: туннелирование без терминации, JA3 источника сохраняется.
При тестировании через node-proxy.io с браузером Chrome фингерпринт на выходе соответствовал Chrome — прокси не терминировал TLS, туннель сохранял оригинальный ClientHello. Проверка через browserleaks.com/ja3 это подтвердила.
Уровень 3. HTTP/2-фингерпринт
Параллельно с JA3 антибот-системы анализируют HTTP/2-фингерпринт — характеристики инициализации HTTP/2-соединения:
- порядок и значения SETTINGS-фреймов (HEADER_TABLE_SIZE, ENABLE_PUSH, INITIAL_WINDOW_SIZE, MAX_FRAME_SIZE)
- порядок заголовков в HEADERS-фрейме
- значение WINDOW_UPDATE
- приоритеты потоков (Priority frames)
Chrome, Firefox, Safari, curl, Python httpx — все инициализируют HTTP/2 по-разному. Если User-Agent указывает на Chrome, а SETTINGS-фреймы соответствуют curl — детекция срабатывает независимо от IP.
Этот уровень обходится использованием реального браузера (Chromium, Firefox) или инструментов, имитирующих его HTTP/2-стек: Playwright, Puppeteer, или библиотек с синхронизированными SETTINGS под конкретный браузер (например, curl-impersonate, tls-client для Python).
Уровень 4. Поведенческий анализ
Если IP-репутация и TLS-фингерпринт не выявили аномалии, в работу вступает поведенческая аналитика. Она строится на нескольких группах сигналов.
Временны́е паттерны запросов. Человек делает запросы неравномерно: пауза перед кликом, задержка при прокрутке, непоследовательное чтение страниц. Краулер, даже с рандомизацией задержек, демонстрирует статистически другое распределение — дисперсия меньше, автокорреляция выше. Детекторы строят временны́е ряды и применяют статистические тесты.
Навигационные паттерны. Реальный пользователь заходит на главную, читает несколько секунд, переходит по ссылке с реального клика. Скрипт часто открывает только целевые URL напрямую, пропуская промежуточные страницы, или переходит по URL без загрузки ресурсов страницы (CSS, JS, изображения).
Загрузка ресурсов. Браузер загружает HTML, затем CSS, JS, шрифты, изображения — в строгом порядке, обусловленном рендерингом. Скрипт, запрашивающий только HTML, — аномалия.
Mouse events и взаимодействие с DOM. Cloudflare и аналоги инжектируют в страницу JavaScript, собирающий: движения мыши (траектория, скорость, ускорение), события клавиатуры, скролл, касания (для мобильных). Энтропия человеческого движения мыши значительно выше, чем у рандомизированного автоматического движения.
Canvas и WebGL fingerprint. JS-скрипт рисует скрытый элемент на canvas и считывает пиксельное представление — результат зависит от видеокарты, драйвера, ОС, браузера. При повторных запросах с разных IP, но с одинаковым canvas fingerprint, система связывает сессии.
Уровень 5. WebRTC и утечки реального IP
WebRTC (Web Real-Time Communication — технология браузерной коммуникации в реальном времени) открывает UDP-соединения напрямую между браузерами, в обход HTTP-прокси. Даже при настроенном HTTPS-прокси браузер может раскрыть реальный локальный и публичный IP через ICE-кандидаты (Interactive Connectivity Establishment — механизм выбора пути соединения).
Антибот-скрипты нередко инициируют WebRTC-запрос и сравнивают возвращённый IP с IP входящего HTTP-соединения. Расхождение — прямое указание на прокси.
Для браузерных сценариев это решается отключением WebRTC в настройках браузера или блокировкой через расширение. В Chromium-based браузерах: chrome://flags/#disable-webrtc или политика WebRtcIPHandlingPolicy: disable_non_proxied_udp. В Firefox: about:config → media.peerconnection.enabled: false.
При тестировании через node-proxy.io в браузерном режиме я отключил WebRTC через политику браузера — проверка на browserleaks.com/webrtc показала только IP прокси без утечек.
Уровень 6. Cookie, сессии и fingerprint-синхронизация
Антибот-системы сохраняют fingerprint клиента в зашифрованных cookie и сопоставляют при следующем визите. Если fingerprint изменился (новый IP, другой TLS, другой canvas) — повышенное внимание.
При работе с ротирующими прокси (rotating proxy — схема, при которой каждый запрос или сессия выходит с нового IP) важно синхронизировать смену IP со сменой браузерного профиля: cookie, localStorage, fingerprint. Иначе возникает аномалия: один и тот же cookie появляется с десятков разных IP — классический паттерн прокси-ротации.
Sticky session (режим, при котором все запросы в рамках одной сессии идут через один IP) решает эту проблему для большинства задач, где не требуется частая смена адреса. node-proxy.com поддерживает оба режима: ротацию для задач, где нужен новый адрес на каждый запрос, и sticky session продолжительностью до 30 минут для сценариев с авторизацией и многошаговыми сессиями.
Уровень 7. Активные пробы и honeypot-элементы
Ряд антибот-систем использует активные пробы на уровне контента страницы:
CSS-ловушки. В HTML добавляются элементы, скрытые через display: none или visibility: hidden — реальный пользователь их не видит и не кликает. Скрипт, анализирующий DOM без рендеринга, может кликнуть на скрытый элемент — немедленный бан.
Honeypot-ссылки. Ссылки, скрытые от пользователя, но видимые краулеру, ведут на фиктивные страницы. Переход по такой ссылке — автоматическая блокировка.
Ratelimit по поведенческим паттернам. Не по IP, а по fingerprint-кластеру: если группа fingerprint-идентичных клиентов делает запросы быстрее допустимого порога, весь кластер получает тихий блок (без явного 403 — возвращается искажённый контент или пустой ответ).
Что из этого следует при выборе инфраструктуры
Детекция работает по принципу суммирования сигналов: ни один из них не является абсолютным, но их комбинация даёт высокую уверенность. Требования к инфраструктуре, которая проходит многоуровневую проверку, складываются из следующих критериев.
IP-уровень: адреса из жилых ASN, без PTR-записей типа proxy/datacenter, с соответствующей геолокацией.
TLS-уровень: прокси не терминирует TLS при HTTPS CONNECT, JA3 браузера сохраняется на выходе.
Сессионный уровень: sticky session для сценариев с авторизацией, синхронизация смены IP с ротацией браузерного профиля для краулинга.
Поведенческий уровень: реальный браузерный движок (Playwright/Puppeteer) с реалистичными задержками и навигационными паттернами — прокси здесь не помогает, это задача на уровне клиента.
WebRTC: отключение в браузере при любом сценарии, где используется прокси.
Резидентские прокси закрывают первые три уровня структурно. Поведенческий анализ и fingerprint браузера — задача на стороне клиента, независимо от типа прокси.
P.S. WebRTC — наиболее часто упускаемый вектор детекции при браузерных сценариях. Даже при идеальном IP и корректном TLS, включённый WebRTC раскрывает реальный адрес через ICE-кандидаты. Проверка через browserleaks.com/webrtc перед запуском любого браузерного сценария занимает 30 секунд и позволяет исключить этот вектор полностью.