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

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

WebRTC — это не «магический обход защиты», а набор API поверх ICE/STUN/TURN, который помогает браузеру строить peer-to-peer маршрут. Внутри Chromium локальные и, при определенных условиях, публичные адреса попадают в candidate list, а затем становятся доступны JS через RTCPeerConnection и getStats(). Если фильтрация не настроена, антифрод видит не только внешний IP, но и сетевую топологию.

Разберем энтропию данного параметра: утечка обычно идет через три слоя:
• host-candidates — локальные интерфейсы;
• srflx-candidates — адрес, полученный от STUN-сервера;
• mDNS-обфускация — частично скрывает LAN-адрес, но не заменяет сетевую гигиену.
Если браузер разрешает WebRTC, один только прокси не гарантирует изоляцию транспортного уровня.

Практика защиты сводится к контролю именно candidate generation. Нужен режим, где WebRTC либо полностью отключен, либо ограничен политикой без host-кандидатов и с принудительным relay-only. В антидетект-профилях важно, чтобы спуфинг через инъекцию JS-кода не расходился с нативным поведением: CreepJS и BrowserLeaks отлично ловят несостыковки между navigator, ICE и сетевым стеком. Детект на уровне сетевого стека здесь часто точнее, чем по Canvas.

Проверьте связку целиком: прокси, DNS, WebRTC, WebGL и разрешения медиоустройств. Если один слой «чистый», а второй отдает адреса в SDP-оbject, вся маскировка ломается. Минимально надежная схема — блокировать утечку на уровне браузерной политики, а не полагаться на расширение или косметическую подмену.