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

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

WebRTC — это не «дырка», а побочный эффект модели peer-to-peer: браузер через ICE собирает кандидаты, а затем отдает их в JS-слой. Если в системе есть активный сетевой интерфейс, в списке часто всплывают host/srflx-кандидаты, и антифрод видит не только адрес, но и топологию сети.

Разберем энтропию данного параметра: утечка идет не только через RTCPeerConnection, но и через mDNS-обход, неправильную изоляцию сетевого стека и несогласованность между внешним IP, DNS и WebRTC-отпечатком. На практике это проверяют в BrowserLeaks, CreepJS и через дамп ICE-candidate, а не по скриншотам из «антидетект» интерфейса.

Что реально работает:
— отключение WebRTC на уровне браузерного профиля, если бизнес-логика не требует звонков;
— принудительный прокси для UDP/ICE, если стек это поддерживает;
— блокировка host-candidates и подмена локальных интерфейсов;
— контроль совпадения: IP, timezone, locale, DNS и WebRTC должны описывать одну и ту же сеть.

Под капотом Chromium API важно помнить: спуфинг через инъекцию JS-кода лечит только поверхностный детект. Если утечка идет на уровне сетевого стека, нужен не косметический патч, а согласованная настройка всей связки браузер + ОС + маршрут. Иначе антифрод сравнит кандидаты с TLS Client Hello и поймает расхождение раньше, чем вы откроете вкладку.