Почему правильно настроенный прокси всё равно сливает ваш настоящий IP через WebRTC
Прокси настроен правильно. Каждый HTTP-запрос уходит через нужный выходной IP, часовой пояс совпадает, DNS резолвится через туннель. И всё равно сайт читает настоящий публичный IP-адрес двумя строками JavaScript, ещё до того, как отработают проверки уровня HTTP. WebRTC вообще не пользуется путём HTTP- или SOCKS-прокси.
Почему WebRTC находится вне прокси
Настройка HTTP-прокси в браузере управляет трафиком HTTP и HTTPS. WebRTC - отдельная подсистема, сделанная для аудио, видео и данных в реальном времени, и медиапуть она устанавливает через ICE (Interactive Connectivity Establishment), договариваясь по UDP напрямую между узлами или между узлом и сервером STUN либо TURN. Chromium не пускает этот UDP-трафик через HTTP- или SOCKS-прокси, заданный на уровне браузера. Настройка прокси никогда и не проектировалась под это. Странице не нужно загружать картинку или вызывать API, чтобы получить ваш настоящий адрес. Ей достаточно открыть RTCPeerConnection.
Три типа кандидатов и что раскрывает каждый
ICE собирает список кандидатов, каждый из которых - возможный способ достучаться до вашей машины:
- host-кандидаты - адреса на ваших собственных сетевых интерфейсах, обычно приватные диапазоны вроде
192.168.x.xили10.x.x.x. Они раскрывают топологию локальной сети и могут намекнуть, сколько устройств стоит за одним роутером. - srflx-кандидаты (server reflexive) приходят из запроса STUN: браузер спрашивает публичный STUN-сервер, обычно что-то вроде
stun.l.google.com:19302, с какого адреса, по его мнению, пришёл запрос. Этот UDP-пакет уходит с машины напрямую, а не через настроенный прокси, поэтому ответом будет ваш настоящий публичный IP, а не адрес прокси. - relay-кандидаты приходят от сервера TURN, работающего ретранслятором. TURN сделан для приложений реального времени, где прямой путь невозможен, а не для веб-сёрфинга, поэтому он редко входит в обычную схему с прокси.
Именно srflx-кандидат сводит на нет в остальном верно настроенный прокси. Ему не нужно ни содействие сервера, ни сверка с базой отпечатков - только круг по UDP, которого прокси никогда не касается.
Как проверить самому
Откройте консоль разработчика на любой странице и выполните:
const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] })
pc.createDataChannel('')
pc.onicecandidate = e => e.candidate && console.log(e.candidate.candidate)
pc.createOffer().then(o => pc.setLocalDescription(o))
В выведенных строках кандидатов есть тип (host, srflx или relay) и адрес. Если строка srflx показывает IP, отличный от выходного IP вашего прокси, утечка подтверждена. Публичные инструменты вроде browserleaks.com/webrtc делают ту же проверку без консоли.
Почему отключение WebRTC - не чистое решение
Обычно чинят расширением, полностью блокирующим WebRTC, или флагом, отключающим API. И то и другое убирает утечку - и то и другое убирает настоящую возможность, которая есть у подавляющего большинства настоящих установок Chrome. Браузер, который на всех сайтах и всегда отвечает нулём ICE-кандидатов, - не нормальный браузер. Это машинный признак сам по себе, и на части систем детекта полностью отсутствующая поверхность WebRTC необычнее, чем корректно текущая, ведь настоящие пользователи иногда пользуются видеозвонками и голосовым чатом, построенными на том же API. Это та же задача согласованности, о которой мы пишем в материалах про отпечатки: убрать сигнал не значит закрыть дыру, значит переместить её, часто на более видное место.
Как выглядит правильная обработка
Здравое решение - пустить UDP-путь WebRTC через тот же выход, что и всё остальное, чтобы srflx-кандидат разрешался в тот же IP, что и HTTP-трафик, а не убирать кандидата вовсе. Обычно это означает принудительный сбор ICE через TURN-ретранслятор, привязанный к тому же выходу прокси, либо ограничение сбора кандидатов тем интерфейсом, которым реально пользуется туннель. У браузера остаётся работающая поверхность WebRTC, и каждый сообщаемый им кандидат согласуется с заявленным IP, вместо обмена утечки на аномалию.
Когда бесплатный подход - верный
Чтобы выяснить, течёт ли ваша текущая схема, хватит бесплатных browserleaks.com/webrtc и ipleak.net. Платный инструмент для диагностики не нужен. Если вы ходите в сеть руками, ничего не автоматизируете и не переживаете, что выглядите как автоматизированный профиль, флаг media.peerconnection.enabled в about:config у Firefox - разумное бесплатное решение для одной личной сессии. Компромисс начинает иметь значение только тогда, когда оценивается согласованность целого парка автоматизированных профилей, а это другая задача, нежели приватность одного человека на одной машине.
Честно о том, что мы измерили
В одном из опубликованных нами прогонов детекта разрешение STUN через определённый тип прокси не сработало вовсе, вместо того чтобы тихо утечь или тихо отработать. Кандидата srflx в той сессии не появилось совсем. Это другой вид отказа, чем утечка, и его стоит понимать именно так, а не подавать как чистое прохождение: отсутствующий кандидат сам по себе сигнал, за который часть систем может зацепиться. Датированные результаты - в нашем прогоне детекторов от августа 2026, он опубликован на английском.
Проверяйте, а не предполагайте
Прогоните фрагмент из консоли на своей схеме, прежде чем верить любому утверждению об обработке WebRTC, включая наше. Сравните адрес srflx с тем выходным IP, которым реально пользуется ваш HTTP-трафик, и считайте расхождение проблемой привязки прокси, а не JavaScript.
Про слой выше - в статье как работают антибот-системы, а про сторону прокси в согласованности личности - в статье резидентные и серверные прокси.
Попробуйте на бесплатном тарифе.
Неограниченное число локальных профилей, без карты. Проверьте результат детекторами сами.