<b>WebRTC раскрывает реальный IP даже через прокси: где именно ломается маска</b>

<b>WebRTC раскрывает реальный IP даже через прокси: где именно ломается маска</b>

WebRTC — это не «магия звонков», а набор API поверх ICE/STUN/TURN. И если браузер получает кандидаты для связи, он может отдать локальные и, при определённой топологии, публичные адреса в JS-слой. Разберем энтропию данного параметра: антифрод смотрит не на факт наличия WebRTC, а на несоответствие между сетевым стеком, DNS и тем, что возвращает браузер.

Типовые точки утечки:
— RTCPeerConnection формирует host/srflx candidates и их видно через getStats или события ICE.
— STUN-запрос уходит мимо ожиданий пользователя, если прокси не перехватывает UDP.
— Локальные интерфейсы с IPv6/IPv4 всплывают в сигналах, даже когда внешний IP замаскирован.
— В некоторых сценариях WebRTC выдает маршрутизируемый адрес через SDP-обмен, а не только через DOM.

Защита строится не на «выключить всё», а на контроле поверхности: ограничить policy для WebRTC, отключить UDP-трафик на уровне профиля или контейнера, проверить, чтобы прокси реально закрывал оба стека. На практике полезно сравнивать результаты в BrowserLeaks, CreepJS и по дампу трафика: если STUN-пакет ушел наружу, маска уже с дырой. Анализ структуры TLS Client Hello здесь тоже помогает: антифрод любит корреляцию WebRTC-следов с сетевым отпечатком.

Если нужен чистый профиль, проверяйте не только visible IP, но и ICE-candidates, IPv6 и поведение при недоступном STUN. Иначе спуфинг через инъекцию JS-кода даст косметику, а реальный адрес останется в сигнализации.