Утечка WebRTC — нежелательное раскрытие адресов через функции связи браузера, например появление исходного публичного IP, когда вы намеревались использовать выход VPN. Частный адрес или имя mDNS — другое наблюдение: сначала классифицируйте кандидата, затем определите, противоречит ли поведение вашей политике.

Ключевые выводы:

Сравнивайте публичные кандидаты с исходным подключением и выходом VPN отдельно.

Частный адрес, имя mDNS и адрес ретранслятора имеют разные значения.

Ограничения браузера требуют компромисса между приватностью и качеством звонков.

После изменения проверьте настоящий звонок и восстановите настройку при отказе необходимой связи.

Что раскрывает утечка WebRTC?

WebRTC обеспечивает обмен аудио, видео и данными в реальном времени. Для поиска рабочего пути ICE собирает кандидатов возможных конечных точек. Сайт может получить адресную информацию сверх адреса обычного веб-запроса; набор зависит от браузера, разрешений, сети и политики.［1］

Кандидат — возможный путь, а не доказательство выбора для звонка. Диагностика может перечислять несколько кандидатов, даже когда медиапоток использует ретранслятор. «Адрес раскрыт странице» и «интерфейс передавал звонок» — разные вопросы: оба важны, но доказательства различаются.

Схема группирует кандидатов по их смыслу. Это концептуальная модель, а не снимок интерфейса или результат проверки VPN. Используйте ее для обозначения наблюдений до того, как назвать адрес утечкой.

Наблюдение	Что описывает	Интерпретация
Частный локальный адрес	Конечная точка за роутером или в частной сети	Локальные сведения, не автоматически исходный публичный IP
Имя mDNS	Имя, скрывающее локального host-кандидата	Само по себе не раскрытый числовой публичный адрес
Публичный адрес совпадает с исходным	Возможная точка исходного соединения	Исследуйте нежелательное раскрытие при активном VPN
Публичный адрес совпадает с выходом VPN	Возможная точка наблюдаемого выхода VPN	Соответствует наблюдению, но не доказывает покрытие устройства
Адрес ретранслятора	Конечная точка посредника как кандидат	Не автоматически адрес провайдера доступа

Что записать перед проверкой утечки WebRTC?

Используйте доверенную сеть и устройство, которое разрешено настраивать. Запишите браузер и версию, систему, VPN, прокси, активные интерфейсы и разрешение странице на микрофон или камеру. Разрешения могут влиять на раскрытие, поэтому их изменение посередине нарушает контролируемость сравнения.

Выберите диагностику с типами кандидатов, без посторонних учетных данных и загрузки файлов. Название «тест приватности» не требует автоматически давать доступ к камере. Если разрешение нужно для воспроизведения обычного звонка, примите решение сознательно и запишите его.

Отсутствие кандидатов может означать блокировку, неисправность или ограничение страницы. Это не доказательство защиты всех приложений. Для общего состояния начните с полной проверки VPN-соединения, а здесь разбирайте значение кандидатов.

Как проверить адреса и разделить их по категориям?

Запишите исходный публичный выход. Без VPN проверьте публичный IP и доступные семейства адресов. Запустите диагностику WebRTC в том же браузере и сохраните категории приватно. Не публикуйте полные адреса или идентификаторы устройства.
Создайте подключенный ориентир. Для сравнения с AethoVPN выберите доступное сейчас расположение, подключитесь и проверьте веб-выход до нового сбора кандидатов. Получатся два публичных ориентира для различения адресов; это не утверждение, что сервис фильтрует WebRTC. Конфигурация Mac, iPhone и iPad требует Pro или Premium.［6］ Если сравнение необходимо, начните 3-дневную пробу Pro, доступную один раз на пользователя.［6］
Повторите при прежних условиях. Оставьте неизменными браузер, сеть, разрешения и диагностику. Отнесите каждый результат к частному локальному, mDNS, публичному или ретранслируемому. Сопоставьте публичные адреса с исходным и VPN-выходом, отдельно по семействам, где данные доступны.
Исследуйте важное несовпадение. Исходный публичный адрес при подключении заслуживает проверки маршрута и политики браузера. Частный адрес или mDNS сами не подтверждают такую же экспозицию. Неизвестную категорию обозначьте неопределенной и найдите документацию вместо изменения всех параметров приватности.
Примените поддерживаемое ограничение. Запишите прежнее значение и область, измените один поддерживаемый контроль и перезапустите браузер, если требует инструкция. Используйте различия ниже: наличие переключателя в руководстве другой программы не доказывает его наличие у вас.
Повторите диагностику и связь. Соберите кандидаты заново и сделайте нечувствительный тестовый звонок в нужном сервисе. Проверьте аудио, видео, установление связи и стабильность. Если необходимая коммуникация нарушена, верните значение и обсудите поддерживаемую ретрансляцию или сетевую политику с администратором.

После обновления браузера или смены сети повторите соответствующее сравнение. Результат одного профиля или Wi-Fi не сертифицирует устройство целиком. Цель — воспроизвести определенное нежелательное раскрытие и показать действие конкретного поддерживаемого изменения.

Чем отличаются Chrome, Firefox, Edge и Safari?

Chrome предоставляет интерфейсы политики и расширений

Chrome описывает webRTCIPHandlingPolicy в privacy API, включая disable_non_proxied_udp. Это контроль для расширений, а не обещание одинакового флажка в настройках каждой сборки. Политика или другое расширение может управлять параметром, поэтому запрошенное значение отличается от действующего.［2］

Не устанавливайте неизвестный «блокировщик утечек» лишь ради переключателя. Проверьте издателя, разрешения, поддержку и текущую документацию. Ограничение непроксируемого UDP меняет доступные пути медиатрафика: проверяйте реальный звонок вместо доверия зеленому значку теста.

Firefox использует собственный сетевой privacy API

Mozilla документирует WebRTC-свойства для расширений, включая политику IP и управление peer connections. Это специфичные интерфейсы браузера; поддерживаемое поведение проверяется для установленной версии. Они не оправдывают недокументированные рецепты about:config или представление каждой настройки как стабильного пользовательского переключателя.［3］

Отключение peer connections шире сокрытия адреса: оно способно выключить звонок или браузерный канал данных. Выберите ограничение по нужной функции, сохраните прежнее значение и проверьте сервис после применения. Результат одного теста адресов не показывает, сохранились ли необходимые функции связи.

Управляемая политика Edge имеет платформенные границы

Microsoft описывает WebRtcIPHandlingUrl: администратор задает политику обработки IP для совпадающих URL. Поддержка указана для настольного Edge начиная с версии 135, но не для Android и iOS. Это управляемая настройка развертывания, а не универсальная инструкция для телефона.［4］

В браузере организации уточните действующую политику и сопоставление URL у администратора. Не обходите управление и не предполагайте, что каждый браузер семейства Chromium без изменений наследует все интерфейсы Chrome. Важна фактическая поддержка данной платформы и версии.

Safari требует данных установленного выпуска

Инженерная публикация WebKit 2017 года описывает подход к раскрытию кандидатов и различия, связанные с разрешениями. Это полезный исторический контекст, не доказательство любого современного поведения по умолчанию. Источник не устанавливает нынешний универсальный пользовательский переключатель, поэтому здесь такой переключатель не выдумывается.［5］

Проверяйте установленный Safari и фиксируйте состояние разрешений. При нежелательном публичном адресе ищите актуальные инструкции платформы или администратора. Отказ в доступе к камере не равен гарантированной блокировке всех кандидатов и не доказывает VPN-покрытие всего устройства.

Когда ограничить WebRTC, а когда сохранить звонки?

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

VPN и браузерная настройка работают на разных уровнях. Измененная политика браузера не доказывает функцию провайдера, а успешная проверка IP страницы не доказывает эту политику. Для резолверов используйте проверку пути DNS, для второго семейства адресов — проверки IPv6.

Сохраните небольшую запись: исходные публичные адреса, подключенные адреса, категории кандидатов, браузер и версию, разрешения, старую и новую настройку, результат звонка. Если страница не дает пригодных кандидатов, назовите тест неубедительным, а не успешным сокрытием адреса. Когда разрешенное исправление не найдено, остановитесь и запросите помощь.

Оцените оставшееся раскрытие в листе решения по пробному периоду. Связь туннеля, браузера и безопасности приложения объясняют основы VPN. В записи сохраняйте условия и область результата, чтобы он не превратился в обещание поведения всех программ на будущих сетях.

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

Сопоставляйте данные с собственным исходным публичным адресом, а не с произвольной географической меткой. Частный адрес и имя mDNS нужно классифицировать отдельно от публичного кандидата. Когда диагностика не создаёт кандидатов или не завершает проверку, запишите отсутствие достаточных данных, а не успешную защиту. Такой результат требует повторного наблюдения при известных условиях.

Итоги

Классифицируйте кандидатов до вывода о раскрытии исходного публичного адреса.
Сохраняйте браузер, разрешения и сеть неизменными при сравнении.
Используйте поддерживаемые настройки фактического браузера и платформы.
Проверьте кандидаты вместе с настоящим звонком и записанным откатом.

Часто задаваемые вопросы (FAQ)

Частный адрес означает утечку моего публичного IP?

Нет. Он может раскрыть локальные сведения, но это отличается от раскрытия публичного адреса исходного интернет-соединения; оценивайте эти наблюдения отдельно.

Имя mDNS раскрывает исходный публичный адрес?

Само по себе нет. Оно иначе представляет локального host-кандидата; до заявления о публичной утечке сравните публичные кандидаты отдельно.

Кандидат ретранслятора означает отказ VPN?

Нет. Адрес обозначает конечную точку ретранслятора. Определите тип и сравните соответствующие ориентиры, не считая каждый незнакомый адрес ошибкой.

Отказ камере устраняет любую утечку WebRTC?

Нет. Разрешения могут влиять на поведение, но не доказывают блокировку сбора кандидатов или всех сетевых путей во всех браузерах.

Следует полностью отключить WebRTC?

Только если поддерживаемый контроль и функциональная цена соответствуют потребностям. Полные ограничения могут нарушить совещания и каналы данных; сохраняйте откат.

Настройки приватности одинаковы на компьютере и телефоне?

Нет. API и управляемые политики ограничены платформой и версией. Следуйте документации установленного браузера, не перенося настольный рецепт на телефон.

Зачем проверять звонок после теста адресов?

Ограничение приватности может изменить медиапути или помешать соединению. Успех диагностики сам по себе не подтверждает работу необходимых аудио и видео.

Отказ от ответственности: Проверяйте только разрешенные устройства и сети. Результат браузера описывает записанные версию, разрешения и конфигурацию, а не каждое приложение устройства.

Источники

Sources checked 5 октября 2026 г.

Утечка WebRTC: как проверить адреса и ограничить браузер