Утечки WebRTC в 2026: почему отключение не спасает антидетект-профиль

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Отключение WebRTC само по себе выдаёт профиль антифроду — устойчивость мультиаккаунтинга теперь зависит от нативной подмены STUN/ICE-трафика и от того, умеет ли прокси в UDP, а не от «выключить фичу».

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Мультиаккаунтинг ломается не на капче и не на отпечатке Canvas. Он ломается на сетевом уровне, тихо, за одну секунду. Браузер отправляет UDP-пакет на STUN-сервер, пакет уходит мимо прокси, и антифрод видит домашний IP. Дальше сетка профилей связывается в один узел и умирает целиком.

Об этом написал Александр, автор разбора для антидетект-браузера Aurorium. Материал короткий (9 минут на прочтение), охват на момент выгрузки — 871 читатель. Суть при этом не в охвате. Разбор объясняет, почему привычный рефлекс «выключить WebRTC» в 2026-м работает против вас: профиль с вырезанным RTCPeerConnection привлекает внимание раньше, чем антифрод вообще посмотрит на прокси.

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

Что такое WebRTC и почему он вообще болтает с внешним миром

WebRTC — встроенная в браузер технология прямой связи между двумя устройствами. Голос в Discord, звонок в Google Meet, демонстрация экрана, быстрая передача файла. Ничего ставить не надо, всё уже внутри.

Обычная загрузка страницы идёт по HTTP/HTTPS поверх TCP. Сидит за прокси — весь трафик идёт через прокси, утечек нет. С медиа так не получится: лишние промежуточные серверы добавляют задержку, и звонок начинает рассыпаться. Поэтому браузер ищет короткий маршрут напрямую по UDP.

Чтобы найти этот маршрут, браузеру надо узнать, как он выглядит снаружи. Он бьёт UDP-запросом по STUN-серверу (Session Traversal Utilities for NAT). Сервер видит внешний адрес и порт отправителя и возвращает их обратно — это ICE-кандидат. В описании сессии (SDP) кандидаты помечаются тегами: host — локальный адрес внутри машины или локальной сети, srflx — внешний адрес, который зафиксировал STUN-сервер.

У технологии нет задачи вас деанонимизировать. Она так исторически устроена. Проблема появляется, когда вы сажаете её на прокси, который не умеет то, что умеет она.

Где рвётся: TCP-прокси и лишний UDP-пакет

Дешёвые серверные и резидентские прокси работают по TCP. Они туннелируют HTTP и HTTPS. UDP они не заворачивают никак.

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

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

Рядом утекает и внутренняя сеть: адреса вида 192.168.1.55 или 10.8.0.2 всплывают в кандидатах host. По отдельности они безобидны. Другое дело, когда один и тот же 192.168.x.x повторяется у нескольких профилей из разных ГЕО — это готовый сигнал для связывания аккаунтов в одну сеть.

Проброс настоящего медиатрафика по UDP возможен. Но только через SOCKS5 с командой UDP ASSOCIATE. Всё остальное — программная эмуляция на стороне браузера. И вот здесь начинается разница между «спрятать» и «выглядеть нормально».

Почему «выключить» перестало работать

Логика «нет фичи — нет проблемы» лет десять была рабочей. Глушили WebRTC программно или вешали плагин-блокировщик, и какое-то время это проходило в классическом мультиаккаунтинге.

Прошло. Потому что выключенный WebRTC — сам по себе аномалия.

В стандартном десктопном окружении на базе Chromium технология WebRTC включена у 99+ % реальных пользователей.

Антифрод смотрит не на наличие функции, а на её поведение. Вырезали или заблокировали объект RTCPeerConnection — проверка нативных прототипов это увидит. Кривое JS-расширение палится ещё быстрее: достаточно уронить внутренний воркер и посмотреть, как поведёт себя подмена. Обычный человек в флаги браузера не лезет и WebRTC ради приватности не отключает. Профиль, который это сделал, выделяется из толпы до того, как система дойдёт до анализа прокси.

Отдельный слой — Chrome и его собственная маскировка. По умолчанию браузер подменяет локальный IP на mDNS-кандидат вида <uuid>.local. Выглядит прилично. Ломается на бытовом сценарии: пользователь дал доступ к микрофону или камере через getUserMedia — и маскировка отключается, локальный адрес снова виден. Именно поэтому «вроде настроено» и «держится на дистанции» — разные вещи.

Правильная цель звучит так:

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

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

Четыре подхода: что реально работает, а что создаёт видимость

Таблица читается просто: два верхних варианта экономят деньги и стоят вам профилей. Нижние два стоят денег и требуют проверки.

Кому это нужно и как применить

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

Второй — агентства и фрилансеры, которые заходят в один и тот же сервис от имени разных клиентов. Тут утечка бьёт не по аккаунту, а по договору: клиент узнаёт, что его кабинет заблокирован из-за «нашей» инфраструктуры.

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

Порядок действий простой. Сначала смотрите, что отдаёт ваш профиль на публичных WebRTC-тестах: какие кандидаты, есть ли srflx с чужим адресом, повторяется ли локальный адрес между профилями. Потом проверяете, умеет ли ваш прокси UDP и через какой протокол. И только потом идёте в настройки антидетекта смотреть, что там за подмена — настоящая или декоративная.

Подвох

Главная ловушка — интерфейс. Галочка «защита WebRTC» есть почти везде. Что она делает по факту — вопрос к вендору и к вашей проверке. Второй момент: нативная подмена не отменяет качества прокси. Адрес в кандидате будет принадлежать прокси, и если этот адрес уже в чёрных списках, вы просто аккуратно утечёте известный IP вместо домашнего.

Третье. SOCKS5 с UDP ASSOCIATE — не кнопка. Его надо согласовывать с поставщиком прокси, а поставщик не всегда рад: UDP-трафик дороже в обслуживании и хуже логируется. Часть пулов его просто не отдаёт, и вы узнаете об этом на бою.

Четвёртое, самое неприятное. Отсутствие утечки — не доказательство анонимности. Профиль без WebRTC-утечки, но с несовпадающим часовым поясом и mDNS-кандидатом на машине без микрофона выглядит страннее, чем профиль с честным прокси и работающим WebRTC.

Брать или подождать: вердикт за 30 секунд

Подождать — если у вас пять профилей, один ручной оператор и задача «зайти и посмотреть». Тут хватит аккуратного прокси и головы на плечах, нативная подмена не окупится.

Брать — если профилей десятки, они ходят в сервисы с живым антифродом, и вы уже ловили блокировки «на ровном месте». Тогда проверка WebRTC-поведения входит в обязательный аудит перед закупкой прокси и антидетекта, а не после первой волны банов.

Не брать никогда — схему «вырезали RTCPeerConnection и забыли». Это мусор. Вы покупаете не защиту, а дополнительный сигнал для антифрода.

Что сделать на этой неделе

1. Прогнать два-три рабочих профиля через публичные WebRTC-тесты и сохранить список кандидатов до изменений.
2. Сверить локальные адреса между профилями из разных ГЕО. Совпадения записать отдельным списком.
3. Спросить поставщика прокси прямым текстом: SOCKS5, UDP ASSOCIATE, да или нет. Ответ «наверное» считать отказом.
4. Проверить, что именно делает галочка защиты WebRTC в вашем антидетекте: подменяет STUN-ответ или просто выключает объект.
5. Воспроизвести сценарий getUserMedia: дать профилю доступ к микрофону и посмотреть, не всплыл ли локальный IP после отключения mDNS-маскировки.
6. Составить список сервисов, где вы работаете, и отметить те, что реально смотрят ICE-кандидаты.
7. Зафиксировать baseline: сколько блокировок за месяц до правок. Без этой цифры через месяц вы не отличите эффект от совпадения.

FAQ

Если я вообще не пользуюсь звонками, WebRTC мне вредит?

Да, потому что браузер отправляет STUN-запросы и для фоновых сетевых тестов. Отсутствие звонков не выключает механику.

Плагин-блокировщик решает проблему?

Он убирает утечку и добавляет новую проблему. Подмена интерфейса на уровне расширения определяется проверкой нативных прототипов.

Достаточно купить прокси с UDP?

Закрывает транспортную часть. Локальные адреса и mDNS-кандидаты остаются на стороне браузера, ими занимается антидетект.

mDNS-подмена в Chrome — это защита?

Маскировка по умолчанию. Снимается выдачей доступа к камере или микрофону через getUserMedia. На неё нельзя рассчитывать как на постоянную.

Как понять, что антидетект врёт про защиту?

Сравнить кандидатов в SDP с адресом прокси. Если srflx не совпадает с выходным IP — подмена декоративная.

Что делать дальше

Возьмите один рабочий профиль и один тестовый. Прогоните оба по чек-листу выше, запишите кандидатов, сравните с выходным адресом прокси. Полчаса работы — и у вас есть факт вместо веры в галочку. Дальше решение принимается по цифрам: сколько профилей, какие сервисы, что с прокси. Всё остальное — покупка файла с настройками, а не решения.