WebRTC часто сдаёт реальный IP даже при прокси: где течёт и как закрыть канал

WebRTC часто сдаёт реальный IP даже при прокси: где течёт и как закрыть канал

Разберем энтропию данного параметра: утечка идёт не через «магический баг», а через архитектуру WebRTC. Браузер поднимает ICE-кандидаты, а через STUN может выдать локальные и публичные адреса, минуя то, что вы считали маской прокси. Для антифрода это удобный сигнал корреляции: IP в HTTP, IP в WebRTC и сетевой стек начинают расходиться.

Проверять нужно не только страницу с тестом, а сам механизм:
— RTCPeerConnection и сбор ICE-кандидатов;
— mDNS-обфускацию локальных адресов;
— поведение при отключённом UDP;
— наличие проксирования на уровне браузера, а не только системы.
Если WebRTC работает, но ICE по-прежнему видит внешний адрес, проблема не в «утечке DNS», а в том, как Chromium строит маршрут до STUN-сервера.

Предотвращение сводится к трем слоям. Первый — отключить WebRTC там, где он не нужен. Второй — запретить UDP-канал или принудить маршрут через однотипный сетевой контур, иначе детект на уровне сетевого стека останется валидным. Третий — не полагаться на расширения: инъекция JS-кода может скрыть API в DOM, но не меняет поведение ICE-агента под капотом Chromium API.

Практический чек: откройте браузерный дамп, сравните адреса в SDP, ICE и в исходящем трафике. Если хотя бы один слой показывает реальный адрес, профиль уже не выглядит цельным.