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

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

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

Типовой сценарий проверки: JS вызывает RTCPeerConnection, получает candidates и парсит строки вида candidate:... typ host / srflx. Если в списке есть host-кандидаты, браузер уже отдал информацию о интерфейсах; если есть srflx, значит наружу ушёл STUN-запрос и сервер увидел ваш реальный исходящий IP. Это и есть детект на уровне сетевого стека, а не просто fingerprint в DOM.

Что реально снижает риск:
— отключить WebRTC там, где он не нужен;
— ограничить ICE candidates до проксируемых маршрутов;
— не полагаться на «скрытие локального IP» как на защиту: часть браузеров всё равно раскрывает публичный адрес через STUN;
— проверять поведение не одним сервисом, а несколькими тестами, включая логи candidate gathering.

Если нужен контроль, смотрите не на обещания интерфейса, а на фактический обмен ICE/STUN: пока браузер способен инициировать discovery, утечка возможна. Надёжная схема — либо жёстко отключать WebRTC, либо изолировать сетевой маршрут так, чтобы у движка Chromium не было способа увидеть ваш исходный адрес.