WebRTC может выдать реальный IP даже при идеальном прокси — разбираем механизм утечки

WebRTC может выдать реальный IP даже при идеальном прокси — разбираем механизм утечки

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

Разберем энтропию данного параметра: утечка идет через JavaScript API, а не через сам TLS. Поэтому блокировка на уровне прокси не помогает, если браузер продолжает отдавать кандидаты ICE. В логах это видно как host/srflx candidates, где второй тип часто фиксирует адрес, полученный через STUN.

Что проверять:
— отключен ли WebRTC или хотя бы ограничен режим без локальных кандидатов;
— не светятся ли адреса в enumerated candidates;
— совпадает ли поведение в обычных вкладках и в iframe;
— не ломается ли связка с WebGL, Canvas и timezone: антифрод любит корреляции.

Если нужен минимум шума, лучше не «маскировать» WebRTC точечно, а выстраивать консистентный профиль браузера: сетевой стек, DNS-резолв, прокси-цепочка и JS-отпечаток должны быть согласованы. Иначе детект на уровне сетевого стека быстро свяжет псевдоанонимность с реальным интерфейсом.