Утечки WebRTC и почему его отключение — плохая идея: разбираем механику деанона и нативную подмену

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

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

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

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

Привет! Я Александр, пишу для антидетект-браузера Aurorium и по совместительству являюсь специалистом в вопросах автоматизации и парсинга, и я не понаслышке знаком с темой утечек IP-адресов, в том числе и с утечками через WebRTC. По традиции сварите чашечку кофе или чая и соорудите пару бутербродов — мы начинаем! 

Что такое WebRTC и как он работает

WebRTC (Web Real-Time Communication) — это встроенная в браузер технология, которая позволяет передавать звук, видео и любые данные напрямую между двумя устройствами (peer-to-peer, или P2P) без участия промежуточного сервера. Именно с помощью этой технологии в браузере и работают звонки в Google Meet, голосовые каналы в Discord, веб-мессенджеры, стриминг экрана и быстрая передача файлов. Не нужно устанавливать дополнительные расширения, все реализовано по дефолту. 

Давайте рассмотрим работу WebRTC на контрасте:

1. Обычная загрузка сайтов (через посредника): когда вы просто открываете страницу, браузер общается с сервером сайта по протоколу HTTP/HTTPS (поверх транспорта TCP). Если у вас установлен прокси, весь этот трафик просто идёт через прокси-сервер без каких-либо утечек.

2. Прямая связь WebRTC (напрямую от компьютера к компьютеру): для видеозвонка или голосовой связи путь через несколько промежуточных серверов будет слишком медленным. Каждая дополнительная задержка (пинг), даже минимальная, будет создавать зависания, долгий отклик и т. п., связь будет некомфортной (как в лучшие годы замедления YouTube). Поэтому браузер пытается проложить прямой короткий маршрут до второй стороны по более быстрому протоколу UDP.

Собственно, вот так и работает технология WebRTC на базовом уровне.

Как решить проблему утечки быстро — но как делать не нужно

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

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

Вот почему выключение функции не лучший выход. В стандартном десктопном окружении на базе Chromium технология WebRTC включена у 99+ % реальных пользователей. Она используется не только для звонков, но и для фоновых сетевых тестов. Это все равно что запустить подростка, у которого никогда не было сотового телефона, к его сверстникам. Как они будут смотреть на него? Скорее всего, как на странного человека, но эффект точно будет, внимание он к себе привлечет.

WebRTC отключается путем вырезания или блокировки объекта RTCPeerConnection. Если вы не технарь, а обычный пользователь, ответьте на короткий вопрос — во сколько лет вы узнали об этом факте? Уверен, что большинство ответит: «В “только что” лет».

1. Обычные пользователи никогда не будут лезть в флаги браузера и отключать WebRTC ради «приватности».

2. Отсутствие или подделку интерфейса на уровне кривого JS-расширения можно быстро распознать через проверку нативных прототипов и падение во внутренних воркерах.

Таким образом, к вашему «защищенному» профилю возникнет повышенное внимание со стороны антифрода задолго до того, как система в принципе начнет анализировать ваш прокси.

Цель правильного антидетект-подхода (защита от утечек здорового человека) — не отключить WebRTC, а заставить его работать честно, но так, чтобы STUN-запросы отправляли наружу адрес вашего прокси, а не реальный IP.

Как STUN и ICE «пробивают» прокси

Основной виновник утечки (если его можно так назвать) — протокол HTTP, и вот почему. 

Как базово работает STUN-запрос

Выше мы разобрались, что WebRTC пытается найти прямую дорогу между двумя сторонами. Когда сайт запрашивает соединение через WebRTC, браузеру нужно узнать свой маршрут до внешнего мира. Для этого он отправляет UDP-запрос на STUN-сервер (Session Traversal Utilities for NAT). Сервер смотрит на пришедший пакет, видит внешний IP и порт отправителя и возвращает их обратно в виде так называемого ICE-кандидата (Interactive Connectivity Establishment).

В текстовом описании сессии (SDP, Session Description Protocol) эти кандидаты обозначаются специальными тегами:

• host — локальный адрес внутри вашей машины или локальной сети.

• srflx (Server Reflexive) — внешний адрес, который увидел STUN-сервер.

Базово у этой технологии нет задачи скомпрометировать пользователя. Просто она так исторически работает.

В чем основная загвоздка при работе через прокси?

Стандартные прокси (особенно если мы говорим про недорогие серверные или резидентские прокси) работают по протоколу TCP. Они проксируют HTTP-запросы и HTTPS-трафик через туннель, но не поддерживают UDP-трафик. Мы, кстати, уже писали про то, что такое UDP-прокси и как они работают.

Когда браузер инициализирует WebRTC-соединение, его сетевой стек пытается отправить UDP-пакет на STUN-сервер. А так как TCP-прокси не умеет заворачивать UDP в свой туннель, запрос уходит напрямую через основной шлюз вашего интернет-провайдера в обход прокси. В результате STUN-сервер видит ваш реальный домашний IP, и он появляется в SDP-строке типа srflx.

Неужели ничего нельзя поделать? Можно! Проброс реального медиатрафика по UDP возможен через SOCKS5-прокси, которые умеют работать с командой UDP ASSOCIATE. Для остальных 90% сценариев, где используются обычные TCP-прокси, требуется программная эмуляция на стороне браузера 

Как еще может утечь ваш реальный IP-адрес

Помимо утечки через WebRTC есть еще две уязвимости, они менее очевидные, но не менее опасные для вашей анонимности.

Раскрытие внутренней сети компьютера 

Помимо внешнего IP провайдера, у вашего компьютера есть внутренний (локальный) IP-адрес, который ему выдал роутер или виртуальная сеть (192.168.1.55 или 10.8.0.2). И вот эти внутренние адреса могут также утекать.

Чем опасна утечка локального IP?

Если смотреть поверхностно, это не ваш реальный IP-адрес, кажется, что ничего страшного в такой утечке нет, но давайте посмотрим на проблему шире. Допустим, у вас запущено несколько аккаунтов на одном компьютере или сервере через антидетект-браузер и каждый такой профиль светит один и тот же внутренний адрес 192.168.х.х (а у каждого профиля есть свой уникальный прокси, соответственно гео отличается). Что видит антифрод — у нескольких профилей, которые де-юре находятся в разных ГЕО, один внутренний IP. Подозрительно? Естественно! Свяжет ли антифрод такие профили в единую сеть? Вопрос дискуссионный, можем накидать свои предложения в комментариях с аргументацией почему да или почему нет, обсудим.

Как Chrome решает эту проблему?

Разработчики Chromium знают об этой проблеме, поэтому по умолчанию браузер прячет ваш внутренний IP. Вместо цифр 192.168.x.x он подставляет в WebRTC-отчет рандомное имя с суффиксом .local (выглядит как случайный UUID вида e4b7c9a1-8d2f-…local), которое имеет смысл только внутри локальной сети, а сайту достается бессмысленная заглушка. Эта встроенная маскировка называется mDNS ICE candidates .

Правда есть небольшая проблема: такая вот .local маскировка автоматически отключается, когда вы даете сайту доступ к микрофону или камере (вызов getUserMedia). С этим вызовом сталкивался каждый пользователь, когда появляется уведомление с просьбой предоставить доступ к микрофону. 

Соответственно, когда вы даете такое разрешение, сайт становится доверенным и получает вместо заглушки реальный внутренний адрес.

Утечка через «вторую дверь» — протокол IPv6

В интернете параллельно работают два поколения IP-адресов:

• IPv4 (185.44.12.90), классический и хорошо известный всем адрес;

• IPv6 (2a00:1450:4010:c08::65), более новый вид адреса.

Как возникает утечка:

Многие домашние интернет-провайдеры и почти все мобильные операторы (если вы раздаете интернет с телефона) по умолчанию выдают вашему компьютеру сразу два адреса — и IPv4, и IPv6. А большинство прокси по дефолту поддерживают только старый формат IPv4.

Получается опасная ситуация:

1. Купленный вами IPv4-прокси контролирует только «первую дверь» (трафик IPv4).

2. «Вторая дверь» на вашем компьютере (протокол IPv6) никем не контролируется.

3. Когда WebRTC начинает собирать маршруты до вашего устройства, он проверяет обе двери сразу. И вот мы получаем ситуацию, что по линии IPv4 он показывает адрес установленного прокси, а по линии IPv6 — выходит в интернет напрямую через вашего провайдера и вписывает в отчет ваш настоящий домашний IPv6-адрес.

В итоге на простых чекерах, проверяющих только IPv4, все выглядит прилично, а антифрод-система видит не только американский или европейский IPv4-прокси, но и реальный IPv6-адрес вашего домашнего провайдера.

Где именно видно отключение WebRTC и внедрение в работу JS-расширений

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

Самое очевидно — десктопный Chrome, у которого принудительно выключен WebRTC (media.peerconnection.enabled = false) даст нулевой результат при попытке инициализировать RTCPeerConnection. Для защитного скрипта это будет маркером нестандартного окружения.

Сторонние расширения «глушат» WebRTC с помощью перезаписи методов в JavaScript-окружении. Антифрод-скрипт проверяет нативность функций (вызов .toString() на объекте должен возвращать function RTCPeerConnection()). Если там обнаруживается код расширения — это нестандартное окружение, и профиль может быть помечен как модифицированный.

Некоторые расширения подменяют API только в главном окне вкладки (window), забывая про изолированные потоки воркеров, где RTCPeerConnection продолжает работать со старыми настройками и выдавать реальный IP-адрес.

Как проверить утечки самостоятельно

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

Сперва необходимо провести сетевую проверку. Для этого зайдите на сайт чекера (BrowserLeaks или Pixelscan) с профиля, в котором нужно проверить утечку и найдите блок WebRTC. Убедитесь, что:

• В поле IP отображается адрес вашего прокси, а не домашнего провайдера.

• В списке кандидатов нет вашего реального IPv6 или локальных подсетей.

• Тип кандидата отображается корректно (srflx), а порт соответствует сетевому окружению прокси.

Далее необходимо проверить целостность среды и воркеров, для чего можно использовать другой чекер (CreepJS). Убедитесь, что в нем нет предупреждений о модификации прототипов. Проверьте, что функции возвращают нативный код и что профиль стабильно проходит фоновые проверки соединения без падений и таймаутов.

Также можно проверить через консоль браузера. Открываете в проверяемом профиле консоль и вставляете этот небольшой скрипт:

// 1. Проверяем, не спалилась ли JS-обёртка расширенияconsole.log('Проверка конструктора:', Function.prototype.toString.call(window.RTCPeerConnection));console.log('Проверка метода:', Function.prototype.toString.call(RTCPeerConnection.prototype.createOffer));// 2. Запускаем фоновую проверку STUN-соединенияconst pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] });pc.createDataChannel('check');pc.onicecandidate = (e) => {  if (e.candidate) console.log('Найден маршрут:', e.candidate.candidate);};pc.onicegatheringstatechange = () => {  console.log('Фаза сборки:', pc.iceGatheringState);};pc.createOffer().then(offer => pc.setLocalDescription(offer));

В результате вы должны увидеть вот такое поведение:

Фаза сборки: gatheringVM64:10 Найден маршрут: candidate:1982170229 1 udp 2113937151 20ad41a3-a899-4802-9f77-6dfc171a9518.local 59452 typ host generation 0 ufrag ur/C network-cost 999VM64:10 Найден маршрут: candidate:3646957807 1 udp 2113939711 803d0954-347c-42ca-9db6-4ab3b647ed7a.local 59453 typ host generation 0 ufrag ur/C network-cost 999VM64:10 Найден маршрут: candidate:2202552712 1 udp 1677729535 171.97.50.90 7172 typ srflx raddr 0.0.0.0 rport 0 generation 0 ufrag ur/C network-cost 999VM64:10 Найден маршрут: candidate:4049253755 1 udp 1677732095 2001:fb1:138:6b94:6594:77b5:e3c2:6f1f 59453 typ srflx raddr :: rport 0 generation 0 ufrag ur/C network-cost 999VM64:13 Фаза сборки: complete

Если вместо этого будет выдаваться сторонний код или ошибка, антифрод тоже это увидит.  

Заключение

Борьба с утечками WebRTC в 2026 году уже давно вышла за рамки простого «выключи то, что может тебя скомпрометировать». Попытки спрятаться за блокировщиками или отключением важных модулей браузера приведут к тому, что вас будут отсеивать за нестандартное поведение базовым поведенческим антифродом.

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