IP lookUp IP lookUp

Тест утечки WebRTC

Проба в браузере показывает собранные ICE-кандидаты и сравнивает каждый наблюдаемый глобально маршрутизируемый адрес со свежим IP вашего HTTP-запроса к этому сайту. Адреса интерфейсов (HOST) отмечаются отдельно от адресов, полученных через STUN. Сравнение возможно только для семейства базового адреса; отсутствие базового адреса, ошибка запроса или неполный сбор не позволяют сделать вывод.

Если STUN настроен, браузер обращается к ip2.xakki.pro: STUN-сервер видит исходный IP-адрес и порт. Кандидаты отображаются в браузере; эта страница не загружает их список на сервер.

Найденные ICE-кандидаты

Проба запускается автоматически при загрузке страницы и завершается примерно за 2 секунды — ничего нажимать и подтверждать не нужно.

Что эта страница может и не может сказать сегодня

Таблица показывает реально собранные ICE-кандидаты: скрытые через mDNS, локальные, адреса интерфейса и, при доступном STUN, публичные server-reflexive адреса.

Страница сравнивает все наблюдаемые глобальные ICE-адреса HOST и STUN со свежим IP вашего HTTP-запроса того же семейства. HOST — адрес интерфейса, а не подтверждение от STUN. При отсутствии базового адреса нужного семейства, ошибке HTTP или неполном сборе результат не определён; другой выход не доказывает утечку IP провайдера.

IP Версия IP Статус

Тест утечки WebRTC

«Утечка WebRTC» происходит, когда ICE-согласование (Interactive Connectivity Establishment) за WebRTC-соединением раскрывает IP-адрес, который сайт не должен был узнать — как правило, ваш реальный публичный адрес, даже если вы подключены через VPN. ICE собирает кандидатов трёх типов: host-кандидаты (считываются напрямую с локального сетевого интерфейса), server-reflexive кандидаты (узнаются через запрос к STUN-серверу о том, с каким публичным адресом ушёл ваш трафик), и relay-кандидаты (собственный адрес TURN-сервера, используется как последний вариант). Классический сценарий утечки — server-reflexive кандидат, проскальзывающий мимо туннеля VPN и раскрывающий назначенный провайдером публичный IP любой странице с несколькими строками JavaScript — без запроса разрешения, в отличие от доступа к камере или микрофону.

Защищает ли вас VPN, полностью зависит от его настройки, а не от самого WebRTC. Большинство современных VPN-клиентов теперь пропускают весь STUN/UDP-трафик через туннель, поэтому server-reflexive кандидат — если он вообще собирается — отражает выходной IP именно VPN, а не вашего провайдера. Старые или неправильно настроенные клиенты, а также некоторые режимы split-tunnel, всё ещё могут позволить сетевому стеку браузера обратиться к STUN-серверу напрямую, в обход туннеля, воспроизводя классическую утечку. Один лишь host-кандидат, без server-reflexive кандидата для сравнения, сам по себе мало о чём говорит — обычно это просто приватный адрес вашей локальной сети, присутствующий с VPN или без него, и сам по себе не признак чего-то неправильного.

Chrome, Firefox и Safari уже несколько лет по умолчанию используют mDNS-обфускацию для host-кандидатов: вместо раскрытия вашего настоящего приватного адреса (например, 192.168.1.42) браузер генерирует случайное имя-UUID с окончанием «.local» и разрешает его только в вашей собственной локальной сети. Это реальное улучшение приватности по сравнению со старым поведением, но его легко неправильно понять: имя «.local» означает, что браузер намеренно скрыл адрес от страницы — а не то, что адреса не существует, и не то, что «утечки нет». mDNS-обфускация и «здесь нечего смотреть» — два разных утверждения, и таблица кандидатов на этой странице всегда обозначает их по отдельности.

Совпадение адресов описывает только это завершённое наблюдение, а не доказывает безопасность VPN. Разные выходы могут отражать маршрутизацию или настройки VPN, а не обязательно утечку IP провайдера. Адрес без базового HTTP-адреса того же семейства, ошибка HTTP или неполный сбор ICE не позволяют сделать вывод.

Как пользоваться этим тестом

  1. Загрузите страницу

    Проба запускается автоматически. Если STUN настроен, браузер обращается к ip2.xakki.pro.

  2. Дождитесь завершения сбора ICE-кандидатов

    Сбор обычно завершается примерно за 2 секунды; страница показывает статус «Выполняется…», пока это не произойдёт.

  3. Изучите таблицу кандидатов

    Каждая строка — адрес, сообщённый при согласовании. Метка «Публичный (подтверждён STUN)» означает server-reflexive кандидата, но не готовый вердикт об утечке.

  4. Поймите границу метода

    Посмотрите базовый адрес и результат сравнения каждого адреса. Различие — наблюдение другого выхода, а не автоматический вердикт об утечке IP провайдера; отсутствие публичных наблюдений или базового адреса нужного семейства, а также неполный сбор не позволяют сделать вывод.

  5. При желании снизьте риск раскрытия

    Используйте шаги для браузера или VPN ниже, чтобы полностью отключить или ограничить сбор ICE-кандидатов WebRTC.

Как снизить раскрытие через WebRTC

Если вы не хотите, чтобы браузер вообще собирал ICE-кандидатов, вот реально существующие сегодня настройки:

Chrome / Edge / Brave
Установите расширение, блокирующее WebRTC — в Chrome нет встроенного переключателя для полного отключения WebRTC. В Brave также есть настройка «WebRTC IP handling policy» в разделе Настройки → Конфиденциальность и безопасность.
Firefox
Откройте about:config, найдите media.peerconnection.enabled и установите значение false — это полностью отключает WebRTC, включая его ICE-согласование.
Safari
В Safari WebRTC нельзя отключить через настройки; используйте расширение, блокирующее конкретно RTCPeerConnection, либо VPN-клиент с собственной защитой от утечек WebRTC.
VPN-клиенты
Большинство надёжных VPN-клиентов включают собственный переключатель «защита от утечек WebRTC» или «блокировать доступ к локальной сети» — обычно это проще и надёжнее, чем менять настройки на уровне браузера, поскольку работает независимо от того, каким браузером вы пользуетесь.

Глоссарий

ICE-кандидат
Сетевой адрес, который WebRTC обнаруживает при попытке установить прямое соединение между узлами — может быть host-, server-reflexive- или relay-кандидатом; см. определения ниже.
Host-кандидат
Адрес ICE-кандидата, считанный напрямую с локального сетевого интерфейса, без участия внешнего сервера — единственный тип, который проба этой страницы может собрать без STUN-сервера.
Server-reflexive кандидат
ICE-кандидат, полученный через запрос к STUN-серверу о том, с каким публичным IP и портом пришёл трафик. Эта страница может собрать его при включённом и доступном STUN, но не превращает в вердикт об утечке.
mDNS-обфускация
Функция приватности современных браузеров, заменяющая реальный приватный адрес host-кандидата на случайное одноразовое имя с окончанием «.local», разрешаемое только в вашей локальной сети.
STUN-сервер
Лёгкий сервер, единственная задача которого — сообщить клиенту, с каким публичным IP-адресом и портом ушёл его трафик — механизм, порождающий server-reflexive кандидатов.
WebRTC
API браузера для прямой аудио-, видео- и передачи данных между узлами в реальном времени, стандартизированный W3C/IETF — ICE отвечает именно за поиск рабочего сетевого пути между двумя узлами.

Аналог через API

Каждый запуск автоматически получает свежий IP вашего HTTP-запроса через API этого сайта /api/v1/ip. Ответ содержит одно семейство адресов; для наблюдений другого семейства результат остаётся неопределённым. Необязательный STUN обращается к ip2.xakki.pro, но список кандидатов сравнивается в браузере и не загружается на сервер. Ответ API также можно посмотреть отдельно:

curl 
curl "https://ip.xakki.pro/api/v1/ip"

Пример ответа (сокращённо):

{
  "schemaVersion": 15,
  "status": "ok",
  "ip": "203.0.113.42",
  "version": 4
}

Читать полную документацию API

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

Что такое утечка WebRTC?
Утечка WebRTC — это когда ICE-согласование за WebRTC-соединением раскрывает IP-адрес, который сайту не следовало бы узнавать — чаще всего ваш реальный публичный IP, даже при использовании VPN, через server-reflexive кандидата, полученного с помощью STUN-сервера.
Защищает ли меня от этого VPN?
Это зависит от настройки VPN-клиента, а не от самого WebRTC. Большинство современных VPN-клиентов пропускают STUN/UDP-трафик через туннель, поэтому любой server-reflexive кандидат отражает выходной IP именно VPN; более старые клиенты или некоторые режимы split-tunnel всё ещё могут допустить утечку в обход туннеля.
Почему эта страница не говорит мне, есть ли у меня утечка?
Страница уже сравнивает каждый наблюдаемый глобальный ICE-адрес, включая HOST и кандидатов STUN, со свежим базовым HTTP-адресом того же семейства. Совпадение не доказывает безопасность VPN, а другой выход не означает автоматически утечку IP провайдера. При отсутствии базового адреса нужного семейства, ошибке HTTP или неполном сборе результат не определён.
Что означает адрес «.local» в результатах?
Это значит, что встроенная mDNS-обфускация вашего браузера заменила реальный адрес на случайное одноразовое имя перед раскрытием — настоящая функция приватности. Это отличается от состояния «адрес не найден» и ещё сильнее отличается от «раскрыт настоящий приватный адрес» — эта страница всегда указывает, с каким именно случаем вы имеете дело.
Как отключить WebRTC в браузере?
В Firefox установите media.peerconnection.enabled в false в about:config. В Chrome, Edge и Brave нет встроенного полного отключения — используйте расширение, блокирующее WebRTC, либо собственную настройку Brave «WebRTC IP handling policy». В Safari нужно расширение для блокировки контента. Многие VPN-клиенты также предлагают собственный переключатель защиты от утечек WebRTC.
Это то же самое, что тест на утечку DNS?
Нет — тест на утечку DNS проверяет, какой DNS-резолвер реально обработал ваши запросы, а это невозможно узнать средствами JavaScript в браузере: нет API, который сообщил бы странице, какой резолвер обслужил конкретный запрос, поэтому настоящий тест на утечку DNS требует серверного компонента. Это отдельный инструмент, не этот.

Понравился инструмент? Бесплатный аккаунт нашего API даёт 1000 запросов в день.Смотреть документацию API →