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

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

Разберем энтропию данного параметра: WebRTC не “обходит” антидетект, он лишь использует ICE/STUN для обмена кандидатами. Внутри браузера это выглядит как сбор local, srflx и relay-адресов; если в цепочке есть прямой STUN-ответ, внешний IP всплывает в JS-объектах RTCPeerConnection.

Типовые точки утечки:
— mDNS не включен или отключен, и локальный IP светится в кандидатах.
— Прокси не перехватывает UDP, а WebRTC уходит мимо через прямой сетевой стек.
— Браузер отдает host-candidates, даже если интерфейс уже замаскирован на уровне профиля.
— Расширение блокирует только медиапотоки, но не SDP-обмен и не ICE gathering.

Под капотом Chromium API это лечится не одним тумблером. Нужна связка: отключение ненужных WebRTC-маршрутов, контроль UDP, проверка SDP-логики и тест в Pixelscan/CreepJS. Если антидетект обещает “полную защиту”, но не трогает RTCPeerConnection и ICE policy — это маркетинг, а не защита. Спуфинг через инъекцию JS-кода здесь полезен только как слой контроля, но не как единственная мера.

Практика простая: после запуска профиля проверяйте candidate-цепочку, сравнивайте IP в WebRTC с IP прокси и смотрите, не утекает ли local address через браузерный стек. Если видите host-candidates — профиль нельзя считать изолированным.