Утечка WebRTC: как проверить и закрыть в браузере

Утечка WebRTC — это когда браузер раскрывает ваш реальный IP-адрес через протокол WebRTC, даже если вы работаете через VPN или прокси. WebRTC использует механизм ICE/STUN, который отправляет запросы по UDP напрямую — в обход HTTP-туннеля. Проверить утечку можно за 30 секунд, закрыть — за 2–5 минут, в зависимости от браузера.

Что такое утечка WebRTC

WebRTC (Web Real-Time Communication) — протокол, встроенный во все современные браузеры. Его задача — обеспечивать прямую передачу аудио, видео и данных между пользователями без промежуточного сервера: именно WebRTC работает под капотом Google Meet, Zoom в браузере и браузерных мессенджеров.

Для установки прямого соединения WebRTC использует механизм ICE (Interactive Connectivity Establishment). ICE собирает «кандидатов» — адреса, по которым можно достучаться до устройства. Один из способов найти публичный IP — обратиться к STUN-серверу. STUN-сервер отвечает: «ваш внешний IP вот такой». Браузер получает ответ и добавляет этот адрес в список кандидатов.

Проблема в том, что STUN-запрос уходит по UDP напрямую — не через настроенный HTTP-прокси. Если на странице есть JavaScript, который создаёт объект RTCPeerConnection и читает список ICE-кандидатов, он получает в том числе публичный IP из STUN-ответа. Этот IP — ваш реальный адрес, а не адрес прокси.

Так работает утечка: страница получает одновременно IP прокси (через HTTP) и реальный IP (через WebRTC/STUN). Браузерный отпечаток дополняется реальным адресом — и расхождение между двумя IP становится сигналом для антифрод-систем. Для тех, кто ведёт несколько аккаунтов с разных адресов, это создаёт прямой риск: платформа видит несоответствие и может связать профили или заблокировать их.

Почему прокси не закрывает WebRTC

Прокси работает на уровне HTTP и HTTPS: он перехватывает запросы браузера и отправляет их со своего адреса. Именно поэтому сайты видят IP прокси, а не ваш. Но WebRTC устроен принципиально иначе.

!Схема двух каналов трафика: один проходит через прокси, второй обходит его напрямую.

Прокси закрывает HTTP-трафик. WebRTC идёт по UDP в обход прокси — это два разных канала. Скрыть один, не тронув другой, не получится.

WebRTC отправляет UDP-пакеты напрямую из браузера в сеть. HTTP-прокси не обрабатывает UDP — он понимает только HTTP/HTTPS. Поэтому STUN-запрос уходит с реального IP устройства, STUN-сервер возвращает реальный публичный адрес, и этот адрес попадает в список ICE-кандидатов. Страница его читает — утечка состоялась.

С VPN ситуация немного другая. Хороший VPN-клиент, установленный на уровне операционной системы, заворачивает весь IP-трафик в туннель, включая UDP. В этом случае WebRTC пойдёт через VPN и покажет IP VPN-сервера. Но если VPN работает как браузерное расширение — он перехватывает только HTTP, а UDP остаётся снаружи. То же при split tunneling: если браузер вынесен за пределы туннеля в настройках VPN-клиента, WebRTC уйдёт напрямую.

Вывод простой: закрыть утечку WebRTC через настройки прокси невозможно по архитектурным причинам. Нужно либо отключить WebRTC в браузере, либо настроить его так, чтобы он не использовал STUN, либо работать в среде, где UDP полностью заворачивается в туннель на уровне ОС.

Как проверить утечку WebRTC

Проверка занимает меньше минуты. Выполняйте её с тем подключением, которое используете в работе — уже через прокси или VPN, в том профиле браузера, через который работаете с аккаунтами.

!Лупа над абстрактным окном браузера выявляет аномальную метку — проверка утечки WebRTC.

Откройте один из тестовых сервисов:

• browserleaks.com/webrtc — показывает все ICE-кандидаты с типами, наглядно и подробно.
• ipleak.net — комплексная проверка: IP, DNS и WebRTC на одной странице.
• whoer.net — добавляет оценку анонимности по совокупности параметров.

Страница сама запрашивает ICE-кандидатов через JavaScript и выводит результат — никаких плагинов устанавливать не нужно. Дождитесь завершения теста (5–10 секунд) и посмотрите на раздел WebRTC или IP Addresses.

Для чистоты сравнения полезно сделать два теста: сначала без прокси — зафиксировать реальный IP; потом с прокси — сравнить с тем, что показывает WebRTC. Если адреса совпадают, утечки нет. Если в результатах теста с прокси виден IP из первого теста — утечка есть и её нужно закрыть.

Если у вас несколько профилей в антидетект-браузере, проверяйте каждый отдельно: настройки WebRTC задаются на уровне профиля, и результат для одного ничего не говорит об остальных.

Как читать результаты теста

Тест выводит несколько строк с IP-адресами и типами кандидатов. Не все из них опасны — важно понимать, что означает каждый тип.

Критический сигнал — srflx с вашим реальным публичным IP при подключённом прокси. Это прямая утечка, которую нужно закрыть.

Локальный host-кандидат (192.168.x.x) не раскрывает вас напрямую: этот адрес есть у каждого устройства за NAT, он не уникален. Но в сочетании с другими данными — временной зоной, разрешением экрана, браузерным отпечатком — он может помочь платформе связать разные профили. Подробнее о том, как антифрод-системы используют совокупность сигналов, — в материале об отпечатках браузера и геолокации.

Если тест показывает только host-кандидаты с локальными адресами и никаких srflx — WebRTC не утекает. Если srflx совпадает с IP прокси — всё в порядке, подмена работает. Если srflx показывает другой публичный IP — это именно то, что нужно закрыть.

Как отключить WebRTC в Chrome

В Chrome нет кнопки «выключить WebRTC» в настройках. Google убрал соответствующий флаг из chrome://flags несколько версий назад. Полностью отключить WebRTC без расширения нельзя, но можно частично ограничить политику сбора IP.

Откройте chrome://flags и найдите параметр #anonymize-local-ips-with-mdns. Если он включён (Enabled), Chrome заменяет локальные IP на mDNS-имена вида xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.local. Host-кандидаты перестают раскрывать реальный локальный адрес, но srflx с публичным IP всё равно может появиться. Это частичная мера, не полная блокировка.

Для надёжной защиты на уровне движка используйте Brave. В brave://settings/privacy есть пункт WebRTC IP handling policy с вариантом Disable non-proxied UDP. Он запрещает WebRTC отправлять UDP напрямую и пускает трафик только через прокси. Это работает на уровне движка, надёжнее любого расширения.

Edge предлагает аналогичную настройку через групповые политики (WebRtcIPHandling), но без графического интерфейса — только через реестр или файл политик. Для большинства пользователей проще перейти на Brave или Firefox, чем редактировать реестр.

На Android Chrome не поддерживает расширения, а флаги в chrome://flags на мобильном ограничены. Если нужна защита от WebRTC-утечки на телефоне — рассмотрите Firefox for Android, где about:config доступен полностью.

Как отключить WebRTC в Firefox

Firefox — единственный из распространённых браузеров, где WebRTC можно выключить полностью без расширений, через встроенную страницу настроек.

Откройте about:config в адресной строке и согласитесь с предупреждением («Принять риск и продолжить»). Затем найдите и настройте три параметра:

• media.peerconnection.enabled — при значении false полностью отключает WebRTC. Браузер перестаёт создавать RTCPeerConnection, STUN-запросы не уходят. Используйте, если видеозвонки в браузере вам не нужны.
• media.peerconnection.ice.default_address_only — при значении true Firefox передаёт только один ICE-кандидат: тот IP, через который установлено HTTP-соединение. Если это IP прокси — WebRTC тоже покажет IP прокси. WebRTC продолжает работать, но без утечки.
• media.peerconnection.ice.no_host — при значении true скрывает host-кандидаты с локальными адресами.

Если вам нужны видеозвонки, но хочется закрыть утечку — комбинируйте второй и третий параметр. Если звонки не нужны — выключайте первым. Перезапускать браузер после правки about:config не нужно — изменения применяются сразу.

Полное отключение WebRTC в Firefox — одна правка в about:config, без расширений. Проверьте результат сразу после изменения на browserleaks.com/webrtc — в разделе WebRTC появится пометка «disabled» или исчезнут все кандидаты.

После изменений проверьте результат тестом. Если всё сделано правильно, раздел WebRTC покажет либо «disabled», либо только IP прокси без srflx с реальным адресом.

Расширения для блокировки WebRTC

Для Chrome и других Chromium-браузеров без встроенных настроек WebRTC расширения — основной доступный инструмент. Механизмы работы у них разные, и надёжность тоже отличается.

Расширение добавляет слой защиты, но не заменяет настройку на уровне движка. При определённых условиях оно может не успеть перехватить запрос до того, как STUN уже ушёл.

WebRTC Leak Prevent устанавливает через Chrome Extension API политику disable_non_proxied_udp или default_public_interface_only — это закрывает большинство утечек. Но если сайт вызывает низкоуровневые методы напрямую раньше, чем расширение успело применить настройки, оно не поможет. Поэтому расширение — хороший первый шаг, но не окончательное решение там, где важна надёжность.

Устанавливайте расширения только из официальных магазинов: Chrome Web Store для Chrome и Edge, Firefox Add-ons для Firefox. Поддельные копии популярных блокировщиков с похожими названиями встречаются регулярно — перед установкой проверяйте число пользователей и дату последнего обновления.

Как антидетект-браузеры решают проблему

В антидетект-браузере управление WebRTC встроено в логику профиля. Не нужно устанавливать расширения или редактировать флаги — настройка задаётся один раз при создании профиля и применяется автоматически к каждому сеансу.

!Матовая маска полностью закрывает светящийся цифровой силуэт — антидетект-браузер управляет отпечатком без утечек.

Антидетект-браузер не просто блокирует WebRTC — он подменяет IP на адрес прокси. Расхождение между WebRTC и HTTP исчезает, и антифрод-система не видит сигнала несоответствия.

Когда вы привязываете прокси к профилю, браузер автоматически пробрасывает WebRTC через тот же IP. Это принципиально важно: полное отключение WebRTC само по себе может быть сигналом для некоторых антифрод-систем — слишком нетипичная конфигурация на фоне миллионов обычных пользователей, у которых WebRTC включён. Подмена IP на IP прокси выглядит органично: WebRTC работает, показывает IP прокси, HTTP тоже показывает IP прокси, расхождений нет.

Большинство антидетект-браузеров предлагают три варианта поведения WebRTC:

• Отключить — WebRTC не работает совсем.
• Настоящий IP — WebRTC показывает реальный IP (небезопасно при работе через прокси).
• IP прокси — WebRTC показывает IP прокси (оптимально для мультиаккаунтинга).

Третий вариант — стандартный выбор для работы с несколькими аккаунтами. Подробнее о том, как устроена изоляция профилей и зачем она нужна, — в материале об антидетект-браузерах для арбитража. Если выбираете конкретный инструмент — смотрите сравнение Dolphin, Octo и других: там разобраны параметры, включая управление WebRTC. Подключение прокси к профилю — базовый шаг, без которого WebRTC-защита не работает в принципе. Полная инструкция — в руководстве по подключению прокси к браузеру.

Типичные ошибки при закрытии утечки

Настроить защиту от WebRTC-утечки несложно, но несколько ошибок встречаются регулярно. Прежде чем считать задачу выполненной, пройдитесь по этому списку:

• Проверять IP только на обычных сайтах. Сервисы вроде «что мой IP» показывают HTTP-адрес и не видят WebRTC. Нужен специализированный тест: browserleaks.com/webrtc или ipleak.net.
• Не проверять результат после установки расширения. Расширение могло установиться, но не применить настройки — особенно после обновления браузера или перезагрузки. Тест обязателен после каждого изменения.
• Не перепроверять после обновления браузера. Chrome и Edge периодически убирают или переименовывают флаги; расширения иногда сбрасываются при обновлении. Проверяйте настройки WebRTC после каждого крупного обновления.
• Проверять один профиль и считать, что всё закрыто. В антидетект-браузере настройки WebRTC задаются на уровне профиля. Изменение в одном профиле не переносится на остальные автоматически.
• Надеяться только на прокси. Прокси не перехватывает UDP. Пока WebRTC не настроен отдельно — утечка сохраняется, даже если HTTP-подключение через прокси работает корректно.
• Игнорировать мобильный браузер. Chrome на Android без расширений уязвим по умолчанию. Если вы заходите в рабочие аккаунты с телефона — проверьте WebRTC и там.
• Полностью отключать WebRTC без понимания последствий. Некоторые антифрод-системы фиксируют полное отсутствие WebRTC как нетипичную конфигурацию. В антидетект-браузере лучше подменять IP на IP прокси, а не отключать протокол совсем.

Частые вопросы

WebRTC-утечка опасна, только если я использую прокси?

Нет. Утечка раскрывает реальный IP в любом случае — если вы пытаетесь его скрыть. Если прокси нет и вы работаете с одного адреса, утечка ничего не меняет. Но как только появляется задача скрыть настоящий IP — WebRTC нужно настраивать отдельно.

Достаточно ли отключить WebRTC полностью?

Для скрытия IP — да, но с оговоркой. Некоторые платформы используют наличие WebRTC как параметр браузерного отпечатка. Полное отключение может выглядеть подозрительно на фоне обычных пользователей, у которых WebRTC включён. В антидетект-браузере правильнее подменять IP на IP прокси, а не отключать протокол.

Помогает ли режим инкогнито против утечки WebRTC?

Нет. Режим инкогнито не меняет поведение WebRTC. Браузер по-прежнему отправляет STUN-запросы и раскрывает реальный IP. Инкогнито удаляет историю и куки после закрытия сессии, но не затрагивает сетевые параметры.

Нужно ли закрывать WebRTC, если VPN включён?

Зависит от типа VPN. Если клиент установлен на уровне ОС и заворачивает весь трафик включая UDP — WebRTC пойдёт через VPN и утечки нет. Если VPN работает как браузерное расширение или настроен split tunneling — утечка возможна. Проверьте тестом с включённым VPN.

Можно ли проверить WebRTC через DevTools браузера?

Частично. В Chrome откройте chrome://webrtc-internals/ — там отображаются активные RTCPeerConnection и ICE-кандидаты для текущей сессии, но только если WebRTC уже используется на открытой странице. Для полноценного теста утечки нужна страница, которая намеренно инициирует соединение, — как browserleaks.com/webrtc.

Источники

• WebRTC API — документация — Mozilla MDN
• WebRTC 1.0: Real-Time Communication Between Browsers — W3C
• RFC 5389: Session Traversal Utilities for NAT (STUN) — IETF

Если вы работаете с несколькими аккаунтами и хотите, чтобы WebRTC автоматически показывал IP прокси без ручной настройки в каждом профиле, — посмотрите на антидетект-браузеры с встроенным управлением WebRTC: там это настраивается один раз при создании профиля.