Как проверить антидетект-браузер на утечки через WebRTC, UDP и QUIC

Утечка SOCKS5-UDP - это когда браузер отправляет UDP-пакеты, чаще всего трафик WebRTC или QUIC, напрямую в интернет вместо прокси-туннеля. Причина простая: большинство конфигураций прокси перенаправляют только TCP. Ловите это на видеозвонках, при загрузке сайтов по HTTP/3 или в антидетект-профиле, который должен прятаться за резидентным IP. И риск здесь прямой: реальные IP-адрес, провайдер и страна всплывают рядом с той личностью, которую вы строили в профиле.

Что на самом деле означает утечка SOCKS5-UDP

Утечка SOCKS5-UDP - это ситуация, когда часть трафика, обычно WebRTC или QUIC, полностью обходит прокси и идет через реальное сетевое подключение. В адресной строке браузера по-прежнему отображается IP прокси. Тем временем скрипт в той же вкладке уже получил ваш настоящий IP по отдельному каналу.

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

TCP против UDP: почему большинство прокси покрывают лишь половину трафика

Стандартные SOCKS5 и HTTP-прокси создавались вокруг TCP - протокола, на котором работают обычная загрузка страниц, авторизация и отправка форм. UDP - второй протокол того же транспортного уровня, что и TCP, но он обходится без рукопожатия и не гарантирует доставку пакетов. Поэтому он быстрее, но его сложнее стабильно ретранслировать, и значительная часть прокси-программ просто никогда его не поддерживала.

RFC 1928, спецификация SOCKS5, на самом деле содержит отдельную команду UDP ASSOCIATE именно для такого сценария. Клиент открывает управляющее TCP-соединение, проходит аутентификацию и просит прокси открыть UDP-релей. В ответ прокси предоставляет адрес для отправки датаграмм, после чего каждый UDP-пакет перед пересылкой оборачивается в небольшой заголовок SOCKS5. Важная деталь: то же TCP-соединение должно оставаться открытым на протяжении всей UDP-сессии, поскольку оно управляет временем жизни релея. Как только соединение прерывается, прокси закрывает ассоциацию. В подробном разборе UDP через SOCKS5 мы объясняем это рукопожатие глубже - на случай, если вам нужна вся механика.

Наличие UDP ASSOCIATE в спецификации SOCKS5 - это одно. Заставить браузер действительно пропускать трафик WebRTC и QUIC через этот релей - отдельная задача, и именно здесь ломается большинство конфигураций. Многие прокси-провайдеры рекламируют «SOCKS5 с UDP», хотя работающий поверх него браузер продолжает отправлять STUN-запросы через обычный сетевой адаптер. Прокси и браузер должны работать согласованно. Этот разрыв подробно рассматривается в нашем руководстве об антидетект-браузерах и анонимности.

И главная причина вовсе не в прокси. Реализация SOCKS5 в самом Chromium ограничена операциями TCP CONNECT: команды UDP ASSOCIATE в ней вообще нет. Более того, когда профилю назначен SOCKS5-прокси, Chromium принудительно отключает QUIC и переводит соединение на HTTP/2 поверх TCP. Поэтому нативная поддержка UDP в антидетект-браузере означает, что разработчик модифицировал сетевой стек Chromium, а не просто добавил переключатель в настройки.

QUIC, HTTP/3 и WebTransport: протоколы, которые обходят устаревшие прокси

QUIC - транспортный протокол поверх UDP. Сначала Google разработала его как gQUIC, затем IETF стандартизировала его в RFC 9000, а сегодня он лежит в основе HTTP/3. QUIC решает проблему блокировки начала очереди: в TCP один потерянный пакет останавливает всю очередь, и остальные данные ждут его повторной отправки, даже если уже давно дошли до получателя. QUIC мультиплексирует потоки так, что потерянный пакет задерживает только те данные, которые в нем находились. Chrome, Firefox, Safari и большинство CDN, включая Cloudflare, Google и Fastly, уже по умолчанию предпочитают HTTP/3, когда он доступен.

WebTransport работает непосредственно поверх такой QUIC-сессии. Он открывается запросом CONNECT через HTTP/3, а затем поддерживает постоянный зашифрованный канал для передачи данных с низкой задержкой. По сути, он похож на WebSockets, но использует UDP вместо TCP. Прокси, который перехватывает только TCP, вообще не знает о существовании сессии WebTransport. Он лишь видит, как UDP-пакеты проходят мимо по реальному сетевому интерфейсу, и ничто их не останавливает.

Нагляднее всего эту разницу показывает wtcheck.top. Страница параллельно определяет ваш адрес через обычное TCP-соединение и через WebTransport поверх QUIC, а затем выводит оба значения рядом. Если профиль правильно туннелирует UDP, строки совпадают. Если нет, второе значение мгновенно раскрывает реальный адрес.

Здесь же подключаются STUN-запросы WebRTC. WebRTC использует процесс ICE, чтобы найти самый быстрый маршрут для однорангового соединения. Браузер собирает список ICE-кандидатов - всех адресов, по которым с ним можно установить связь, - с локальных сетевых интерфейсов и внешних серверов. Часть этого процесса - запрос к STUN-серверу (Session Traversal Utilities for NAT) с вопросом: «Как мой IP выглядит снаружи?» Если запрос идет через реальный интерфейс вместо прокси, STUN-сервер возвращает ваш настоящий публичный IP прямо в JavaScript страницы, не требуя специального разрешения. Технические подробности есть в нашей статье о WebRTC STUN.

Не следует путать STUN и TURN. STUN лишь сообщает браузеру, как его адрес выглядит снаружи. TURN ретранслирует весь трафик через собственный сервер и поэтому не показывает реальный IP собеседнику. Утечка происходит именно через STUN, поскольку ICE сначала пробует его как менее затратный вариант.

Пошаговая проверка браузера на утечку IP через WebRTC

Тест на утечку WebRTC отвечает на один прямой вопрос: совпадает ли IP-адрес, который показывает WebRTC, с IP вашего прокси? Ниже - способ проверить это точно, а не гадать.

1. Откройте антидетект-профиль с уже назначенным и активным прокси
2. До любых других действий запишите IP и страну прокси из панели провайдера
3. В том же профиле перейдите на browserleaks.com/webrtc
4. Сравните строку «Public IP Address» в блоке «Your WebRTC IP» с записанным IP прокси
5. Разверните «SDP Log» и проверьте список ICE-кандидатов. Утечку интерфейса часто видно именно там, даже когда итоговое поле выглядит чистым
6. Повторите тест в другом профиле с другим прокси, чтобы исключить случайный результат

Если «Public IP Address» точно совпадает с адресом прокси, этот канал выглядит чистым. Если там указан IP вашего интернет-провайдера, что-то на компьютере передает реальные сетевые данные прямо на страницу.

Строку «Local IP Address» современные браузеры намеренно маскируют. Вместо частного адреса вроде 192.168.1.5 вы увидите случайное имя хоста вида 1f4712db-ea17-4bcf-a596-105139dfd8bf.local. Это mDNS - протокол обнаружения устройств в локальной сети, который WebRTC использует специально, чтобы не передавать частный IP в JavaScript. Chrome, Firefox, Edge и Safari по умолчанию работают именно так, поэтому .local в этой строке - нормальное поведение, а не утечка. Прочерк вместо адреса тоже нормален: он означает, что браузер вообще не собрал локальных кандидатов. Именно такой результат показан на скриншоте ниже.

Есть и другая ловушка, о которой почти никто не пишет. Само по себе совпадение IP в этом тесте еще не доказывает, что UDP действительно идет через туннель. Некоторые антидетект-браузеры просто подменяют ответ WebRTC на уровне JavaScript API: страница получает IP прокси, а сами UDP-пакеты обходят туннель через реальный сетевой адаптер. Поэтому одного WebRTC-теста недостаточно. Настоящее туннелирование дает совпадение сразу по трем каналам. Подмена перестает работать, как только вы выходите за пределы WebRTC, и именно это проверяет следующий раздел.

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

Пошаговая проверка утечек QUIC, HTTP/3 и WebTransport

Проверка QUIC и WebTransport требует немного больше терпения, чем тест WebRTC. Главным образом потому, что такие соединения согласовывают версию протокола и не всегда устанавливаются при первой загрузке. Сразу оговоримся насчет http3.is: сервис проверяет черновые версии h3-29 и h3-27 образца 2020 года, тогда как финальный HTTP/3 стандартизирован как RFC 9114 с идентификатором h3. Его вердикт «HTTP/3 не использовался» сам по себе еще не говорит о проблеме, поэтому основным инструментом лучше считать browserleaks.com/quic.

1. Откройте http3.is в активном профиле и прочитайте сообщение на баннере
2. Обновите страницу два-три раза. Иногда браузеру нужен предыдущий визит, прежде чем он попробует HTTP/3
3. Откройте quic.tanatos.org:444 во второй вкладке и запишите IP, порт и версию протокола
4. Сверьте этот IP с адресом прокси в панели провайдера
5. Откройте browserleaks.com/quic и проверьте IP-адрес соединения, набор шифров, отпечаток JA4 и статус Encrypted Client Hello
6. Завершите проверку на wtcheck.top, где отдельно отображается ваш IP через TCP и через WebTransport поверх QUIC

Несколько пояснений. Без порта 444 домен quic.tanatos.org показывает общий список инструментов, а не сам тест. В отчете BrowserLeaks JA4 - это хеш параметров TLS-рукопожатия, по которому сайт распознает ваш клиент, а Encrypted Client Hello указывает, зашифровано ли имя домена в запросе. Оба поля здесь второстепенны: главное - IP-адрес соединения. Сервис wtcheck.top удобен, но его поддерживает команда одного из антидетект-браузеров в таблице ниже, поэтому рекомендации на его странице стоит воспринимать как рекламу.

Чистый результат намеренно выглядит скучно: один и тот же IP везде - в WebRTC, HTTP/3 и WebTransport. При утечке первый инструмент показывает IP прокси, а третий - IP вашего провайдера. Это несоответствие и есть сигнал.

Третий возможный результат чаще всего вызывает недоумение: соединение по HTTP/3 вообще не устанавливается. Это не поломка. Помните, что Chromium отключает QUIC при настроенном SOCKS5-прокси? Трафик просто переключился на TCP и прошел через прокси, то есть утечки нет. Опасный сценарий выглядит иначе: HTTP/3 работает, но в отчете указан ваш собственный IP.

Какие антидетект-браузеры действительно туннелируют UDP через SOCKS5

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

Две строки требуют отдельного комментария. Утверждение Multilogin «SOCKS5 поддерживает UDP» описывает возможности самого протокола, а не использование этих возможностей браузерным клиентом. Это разные вещи. Аргумент GeeLark «это настоящий Android в облаке» тоже ничего не доказывает: облачное устройство все равно подключено к прокси, который, в свою очередь, должен поддерживать UDP ASSOCIATE.

В похожих подборках часто встречаются Vision Browser и WADE X с пометкой «UDP через SOCKS5». Обе ссылки ведут на партнерский контент одного продавца прокси, а публичной технической документации, которая подтверждала бы это заявление, мы не нашли. Поэтому этих продуктов нет в таблице. Полную картину цен, доступа к API и глубины работы с отпечатками на рынке смотрите в нашем сравнении 13 антидетект-браузеров, которое выходит далеко за рамки одной колонки UDP.

Ничто из этого не работает без поддержки со стороны прокси. Браузер с идеальной реализацией UDP ASSOCIATE все равно будет допускать утечки, если подключенный к нему резидентный прокси пересылает только TCP.

Распространенные причины утечек UDP и способы их устранения

Большинство утечек сводится к нескольким типичным причинам. И для каждой есть конкретное решение, а не расплывчатое «будьте осторожны».

• Провайдер прокси пересылает только TCP: перейдите на тариф, где прямо заявлена поддержка UDP ASSOCIATE, а не просто «SOCKS5»
• Браузер по умолчанию игнорирует прокси для WebRTC: используйте браузер с нативной маршрутизацией UDP или отключите WebRTC в настройках профиля, если не нужны видео и голосовая связь. В обычном Chrome отдельного переключателя уже нет - понадобится расширение или корпоративная политика
• IPv6 утекает в обход туннеля: отключите IPv6 на уровне сетевого адаптера в операционной системе, поскольку большинство прокси туннелируют только IPv4
• Расширение браузера отправляет собственные сетевые запросы в обход прокси-настроек профиля: удалите или отключите непроверенные расширения, особенно кошельки и VPN-расширения, работающие параллельно
• Устаревший DNS-кеш или системные настройки прокси переопределяют настройки профиля: очистите DNS-кеш операционной системы, убедитесь, что профиль не переключается на системный прокси, и запустите DNS Leak Test на quic.tanatos.org

Прежде чем менять прокси или браузер, исключите самое простое объяснение: возможно, UDP вообще не работает в вашей сети. Корпоративные межсетевые экраны, гостиничный Wi-Fi и некоторые мобильные операторы намеренно блокируют UDP на порте 443. Для такой диагностики подойдет networktest.twilio.com. Он последовательно пробует подключиться через UDP, TCP и TLS, проверяет доступность серверов STUN и TURN и показывает, какой транспорт до вас доходит. Если UDP не работает даже без прокси, проблема не в антидетект-браузере.

Если вы одновременно ведете несколько профилей, повторяйте тест дважды в месяц. Прокси-провайдеры меняют инфраструктуру почти без предупреждений, и IP, который поддерживает UDP сегодня, уже на следующей неделе может незаметно лишиться этой возможности.

SOCKS5-UDP против стандартного SOCKS5 или HTTP-прокси

Стандартный SOCKS5 или HTTP-прокси пересылает только TCP. И точка. SOCKS5-UDP относится к тому же семейству протоколов, но команда UDP ASSOCIATE в нем действительно реализована и используется как прокси-сервером, так и подключенным к нему клиентом.

Если ваша работа ограничивается статическим скрейпингом страниц без видео, расширений криптокошельков и сайтов, которые активно используют HTTP/3, стандартного прокси действительно может хватить. Но как только появляются WebRTC, игры или современные CDN, разница между двумя колонками превращается в ваш реальный IP в отчете об утечке.

Как собрать конфигурацию, которая действительно проходит эти тесты

Покупка прокси с поддержкой UDP решает только половину задачи. Вторая половина - движок браузера, который действительно направляет WebRTC, QUIC и WebTransport через туннель, а не незаметно переключается на реальный сетевой адаптер. Именно на этой второй части большинство антидетект-конфигураций проваливает все описанные выше тесты.

Afina решает эту задачу внутри самого движка браузера, а не костылем поверх него. Каждый профиль направляет трафик SOCKS5-UDP, включая QUIC и HTTP/3, через назначенный прокси - поэтому отпечаток WebRTC в тесте совпадает с IP прокси, а не с реальным подключением. Материал статьи для тестирования и обучения: итоговый результат все равно зависит от конкретного прокси, с которым работает браузер.

Скачать