Обзор: Когда при проверке WebRTC обнаруживается утечка, следует немедленно прекратить вход в важные аккаунты и закрыть текущую среду. Затем проверьте подключение прокси, режим WebRTC, IPv6 и правила обхода прокси. Для пользователей MostLogin стандартные действия: убедитесь, что прокси определён корректно, установите WebRTC среды в режим Private (Приватный); если бизнесу не нужны аудио/видео или P2P-соединения, можно выбрать Disabled (Отключено); также включите правило запрета открытия среды при сбое прокси.
Обратите внимание: наличие нескольких адресов на тестовой странице не обязательно означает утечку. Только когда страница раскрывает ваш реальный публичный IPv4, реальный публичный IPv6 или показывает сетевые выходы, не связанные с данной средой, это является серьёзной проблемой, требующей немедленного решения.
Что такое WebRTC? Почему он может обходить обычные настройки прокси?
WebRTC расшифровывается как Web Real-Time Communication — «веб-коммуникации в реальном времени». Эта технология позволяет браузерам напрямую осуществлять голосовые звонки, видеоконференции, демонстрацию экрана и передачу данных между устройствами. Многие инструменты для онлайн-совещаний, клиентской поддержки и совместной работы используют WebRTC.
Для поиска доступного пути соединения между двумя устройствами WebRTC через ICE собирает несколько «кандидатских адресов». Эти адреса могут включать адреса сетевых интерфейсов устройства, публичные адреса, обнаруженные через STUN-сервер, и адреса, ретранслируемые через TURN-сервер. Согласно документации MDN по типам ICE-кандидатов, host-кандидат представляет прямой адрес устройства, srflx-кандидат генерируется в результате взаимодействия STUN/TURN, а relay-кандидат проходит через ретрансляцию TURN. Описание подключения WebRTC на MDN
Это и есть корневая причина утечки WebRTC: веб-страница через JavaScript создаёт WebRTC-соединение и считывает ICE-кандидаты. Если браузер правильно не ограничивает эти адреса, страница может получить сетевую информацию, несовместимую с выходным IP прокси. MDN также прямо указывает, что адреса ICE-кандидатов могут раскрывать информацию о местоположении устройства и сетевой топологии, выходящую за рамки ожиданий пользователя, и могут использоваться для фингерпринтинга браузера. Описание безопасности RTCIceCandidate на MDN
Простыми словами: обычные запросы страниц могут идти через прокси, но WebRTC дополнительно ищет пути для связи в реальном времени. Когда эти два пути не согласованы, сайт может одновременно видеть «IP прокси» и «другую группу сетевых адресов».
Что считается утечкой WebRTC?
Для определения утечки недостаточно просто проверить, появился ли IP на тестовой странице. Нужно сравнить «что показывает страница» с тем, «что среда должна показывать».
| Результат теста | Утечка? | Оценка риска |
|---|---|---|
| Публичный IP WebRTC совпадает с IP прокси, определённым в MostLogin | Обычно нет | Норма. Продолжайте проверку DNS, часовой зоны и геолокации |
| Показан реальный публичный IP домашнего интернета, корпоративной сети или мобильной точки доступа | Да | Высокий риск. Немедленно прекратите операции с аккаунтами в текущей среде |
| Прокси — IPv4, но тестовая страница показывает реальный публичный IPv6 | Да | Высокий риск. IPv6, вероятно, не покрыт прокси |
Показаны приватные адреса 192.168.x.x, 10.x.x.x | Не обязательно | Это утечка информации о локальной сети. Обычно не является утечкой публичного выхода, но увеличивает сетевой фингерпринт |
Показаны случайные имена .local | Обычно нет | В большинстве случаев это результат использования mDNS для скрытия локальных адресов |
| Показано несколько адресов, но все принадлежат одному прокси или ретрансляционному выходу | Обычно нет | Возможно, это IPv4, IPv6 или разные типы ICE-кандидатов |
Современные браузеры могут заменять IP-адреса локальной сети именами mDNS. Поэтому появление на тестовой странице случайной строки с .local не означает раскрытия реального публичного IP. Действительно важно: появился ли реальный публичный адрес провайдера, который можно определить вне среды браузера.
Какие последствия у утечки WebRTC?
1. Конфликт между прокси-идентичностью и реальной сетевой идентичностью
Предположим, среда MostLogin настроена на прокси Нью-Йорка (США), и запросы страниц показывают IP Нью-Йорка, но WebRTC раскрывает публичный IP локальной сети пользователя. Платформа видит не естественную и стабильную среду просмотра, а два конфликтующих сигнала о местоположении или сетевом провайдере.
Это не доказывает автоматически, кто пользователь, но ослабляет изоляцию прокси и может стать одним из сигналов для дополнительной проверки风控, дополнительной верификации или проверки сессии.
2. Различные среды браузера могут быть связаны через один реальный IP
Команда создаёт несколько независимых сред для разных тестовых проектов, каждая с разным прокси. Если все эти среды через WebRTC раскрывают один и тот же публичный IP офиса, сайт может получить связующий сигнал, повторяющийся между средами. Даже если Cookie, Canvas и WebGL изолированы, повторяющийся реальный сетевой выход снижает независимость между средами.
3. Раскрытие приблизительного местоположения, провайдера и структуры сети
Публичный IP обычно позволяет определить страну, город, провайдера; адреса локальной сети, IPv6 или различные сетевые интерфейсы могут раскрывать дополнительные характеристики сетевой топологии. IP обычно не может самостоятельно определить точный адрес или реальное имя, но может использоваться в сочетании с аккаунтами, Cookie, фингерпринтами устройств и данными о поведении.
4. Видеоконференции и веб-звонки: компромисс между конфиденциальностью и функциональностью
Полное отключение WebRTC может уменьшить поверхность раскрытия, но видеоконференции, голосовая поддержка, демонстрация экрана или прямая передача файлов могут перестать работать. Поэтому правильное решение — не отключать WebRTC во всех сценариях, а выбирать между Private и Disabled в зависимости от потребностей бизнеса.
Утечка WebRTC в антидетект браузере: выполните эти 6 шагов
Шаг 1: Приостановите конфиденциальные операции в текущей среде
Если тестовая страница уже показала реальный публичный IP, не продолжайте вход, оплату, публикацию контента или переключение важных аккаунтов. Сначала запишите результаты теста, включая:
- Адрес, показанный при обычной проверке IP;
- IPv4 и IPv6, показанные при проверке WebRTC;
- Адрес прокси и страна/регион, настроенные в MostLogin;
- Время теста, название среды и использование VPN.
Запись информации нужна для локализации проблемы. Не рекомендуется сохранять на скриншотах пароли прокси, Cookie аккаунтов или другие учётные данные.
Шаг 2: Составьте сравнение «Реальный IP — IP прокси — WebRTC IP»
Не открывая бизнес-аккаунты, выполните три группы проверок:
- В обычном браузере без прокси определите текущие публичные IPv4 и IPv6 как базовую линию реальной сети.
- Во вкладке
ProxyMostLogin нажмите проверку IP прокси и запишите ожидаемый выход. - Откройте соответствующую среду и считайте кандидатские адреса на тестовой странице WebRTC.
Если результат WebRTC совпадает с первой базовой линией, а не со вторым выходом прокси, утечка подтверждена. Если результат совпадает с IP прокси, это скорее нормальное отображение ICE-кандидатов.
Шаг 3: Сначала исправьте прокси, затем настройте WebRTC
Настройки WebRTC не могут исправить уже отключённый, неавторизованный или неправильно настроенный прокси. Перейдите на страницу редактирования целевой среды, откройте вкладку Proxy, проверьте протокол, хост, порт, логин и пароль, затем выполните проверку IP прокси. Согласно официальному руководству MostLogin по созданию сред, можно настроить direct, http, https и socks5, а также проверить результат подключения через «Check proxy IP». MostLogin: Создание новой среды
Продолжайте только после успешной проверки прокси и подтверждения ожидаемой страны и города.
Шаг 4: Выберите подходящий режим WebRTC в MostLogin
Путь обычно:
Profiles (Список сред) → Выберите целевую среду → Edit (Редактировать) → Fingerprint (Фингерпринт) → WebRTC
Официальная документация MostLogin показывает настройки WebRTC в выпадающем списке: Private скрывает реальный IP при сохранении функциональности WebRTC, также доступны Public и Disabled. MostLogin: Описание настроек фингерпринта WebRTC
| Режим | Рекомендуемый сценарий | Примечания |
|---|---|---|
| Private | Повседневный сёрфинг, аудио/видео в браузере, клиентская поддержка или инструменты совместной работы | Рекомендуется в первую очередь; после сохранения обязательно перепроверьте, подтвердив совпадение с прокси |
| Disabled | Среды, где видеоконференции, аудио или P2P полностью не нужны | Более чёткие границы конфиденциальности, но функции сайта могут не работать |
| Public | Только для тестов разработки или совместимости, где требуется открытая сетевая информация | Не подходит для прокси-сред, где нужно скрывать реальный сетевой выход |
Для обычных прокси-сред рекомендуется Private. Тестируйте Disabled только если бизнес не зависит от WebRTC или режим Private не обеспечивает необходимую изоляцию. Не считайте утечкой просто потому, что тестовая страница показывает «WebRTC enabled»; важно, какой адрес она возвращает.
Шаг 5: Включите защиту при сбое прокси и проверьте список обхода прокси
Перейдите в глобальные настройки или настройки среды MostLogin и включите следующую защиту:
- Не открывать среду при сетевой ошибке прокси;
- Не открывать среду при изменении IP прокси;
- Не открывать среду при изменении страны или региона IP прокси;
- Не открывать среду при сбое синхронизации.
MostLogin описывает эти настройки как защитные меры перед запуском. Защита от сетевых ошибок прокси предотвращает случайное раскрытие реального IP провайдера при сбое прокси. MostLogin: Profile preferences
Также проверьте Settings → Proxy bypass. Домены, добавленные в список обхода, будут использовать локальную сеть напрямую, а не прокси текущей среды. Официальная документация MostLogin также указывает, что обходимые домены доступны через реальное локальное подключение. MostLogin: Proxy bypass Если тестовые сайты, домены аутентификации или их API/CDN находятся здесь, удалите ненужные исключения и сохраните.
Шаг 6: Полностью закройте и перезапустите среду для перекрёстной проверки
После сохранения настроек полностью закройте среду браузера и перезапустите её, не просто обновляйте тестовую страницу. Используйте как минимум две независимые тестовые страницы для проверки:
- Обычный публичный IP, видимый браузером;
- IPv4 среди кандидатов WebRTC;
- IPv6 среди кандидатов WebRTC;
- DNS, часовой пояс, язык и геолокация соответствуют региону прокси.
Критерии успешной повторной проверки: тестовая страница больше не показывает реальный публичный IPv4/IPv6 провайдера; публичные адреса WebRTC совпадают с прокси, ретрансляционным выходом или ожидаемым поведением продукта; результаты стабильны после перезапуска среды.
Пример использования MostLogin: среда с прокси Нью-Йорка обнаружена с реальным IPv6
Сценарий
Команда QA кросс-регионального сайта создала среду MostLogin US-NewYork-QA-01. Проверка HTTP-прокси показывает IPv4 Нью-Йорка (США). После открытия тестовой страницы обычный IP остаётся нью-йоркским, но в зоне WebRTC появляется публичный IPv6 от локального провайдера.
Диагностика
Это реальная утечка, а не обычный случай «нескольких IP». Причина: HTTP-прокси покрывает запросы IPv4, но сетевой путь IPv6 хоста не обрабатывается аналогично, и кандидаты WebRTC могут раскрыть этот адрес.
Решение
- Закройте среду, чтобы прекратить тесты входа.
- Проверьте, поддерживает ли прокси IPv6; если нет, используйте прокси-решение с полным покрытием IPv4/IPv6 или отключите незащищённый путь IPv6 на уровне системной сети.
- Отредактируйте среду, выберите Private в
Fingerprint → WebRTC. - Включите «Не открывать среду при сетевой ошибке прокси».
- Проверьте список обхода прокси, удалите исключения, связанные с тестовыми сайтами.
- Перезапустите среду и перепроверьте, подтвердив, что реальный IPv6 больше не появляется.
В этом сценарии смена режима WebRTC может временно скрыть обнаружение, но покрытие IPv6 прокси остаётся корневой проблемой, поэтому нужно проверять оба аспекта.
Пример использования MostLogin: тестовая страница показывает .local, но публичный IP совпадает с прокси
Сценарий
Пользователь использует британский прокси. Обычный IP и публичный адрес WebRTC показывают Великобританию. Тестовая страница также показывает случайную строку, оканчивающуюся на .local, что пользователь ошибочно принимает за утечку.
Оценка
.local — это обычно результат использования браузером имён mDNS для скрытия адресов локальной сети. Пока не появился реальный публичный IPv4/IPv6 провайдера и публичные кандидаты совпадают с британским прокси, нельзя считать .local доказательством утечки реального IP.
Решение
Сохраните текущую настройку Private, запишите результат и перепроверьте на другой тестовой странице. Частая смена прокси, рандомизация фингерпринтов или пересоздание среды, наоборот, могут внести ненужные изменения в стабильную тестовую среду.
Пример использования MostLogin: после отключения WebRTC видеоконференция не подключается
Сценарий
Команда удалённой поддержки установила WebRTC в Disabled, после чего веб-звонки клиентской поддержки и демонстрация экрана не могут установить соединение.
Решение
Переключите среду на Private, убедитесь, что прокси подключён, затем перепроверьте адреса WebRTC. Если реальный IP больше не появляется и аудио/видео работает, баланс между функциональностью и сетевой изоляцией достигнут. Если утечка продолжается в режиме Private, проверяйте протокол прокси, IPv6, разделение VPN и обходимые домены, а не переключайтесь на Public для восстановления звонков.
Если утечка сохраняется после исправления, в чём может быть проблема?
Если MostLogin настроен на Private, но тест всё ещё показывает реальный публичный IP, проверьте в следующем порядке:
- Прокси фактически не подключён. При ошибке учётных данных, истекшем узле или отключённом сервере прокси браузер не может получить ожидаемый выход.
- IPv6 не покрыт. Прокси обрабатывает только IPv4, хост может выходить в сеть через реальный IPv6.
- Правила обхода прокси. Тестовый сайт или связанные поддомены настроены на прямое подключение.
- Разделение VPN или конфликт системной маршрутизации. Одновременное использование VPN, системного прокси и прокси среды может создавать разные сетевые пути.
- Старый процесс среды всё ещё работает. Если среду не закрыли полностью после сохранения настроек, старый процесс продолжает использовать прежнюю конфигурацию.
- Расширения браузера изменяют сетевое поведение. Расширения VPN, прокси, конфиденциальности или WebRTC могут конфликтовать с настройками среды.
- Ложное срабатывание или кэш тестовой страницы. Используйте вторую тестовую страницу и перезапустите среду для проверки, не делайте выводов по одному результату.
Если две независимые тестовые страницы стабильно показывают один и тот же реальный публичный адрес, сохраните скриншоты без конфиденциальных данных, версию MostLogin, операционную систему, протокол прокси и шаги воспроизведения, затем обратитесь в поддержку MostLogin или к провайдеру прокси.
Контрольный список проверки защиты от утечек WebRTC
При первом использовании каждой новой среды, смене прокси, обновлении клиента или переключении сети выполняйте следующую проверку:
Часто задаваемые вопросы
Тест WebRTC показывает несколько IP — это обязательно утечка?
Не обязательно. Несколько результатов могут происходить из IPv4, IPv6, интерфейсов локальной сети, STUN-маппинга, TURN-ретрансляции или mDNS. Только появление реального публичного IP провайдера, несвязанного сетевого выхода или публичного адреса, явно конфликтующего с местоположением прокси, следует считать утечкой высокого риска.
Какой IP должен показывать WebRTC при использовании прокси?
В идеале страница не должна видеть ваш реальный публичный IP провайдера. В зависимости от браузера и политики продукта тестовая страница может показывать адрес прокси, ретрансляционный адрес, скрытый локальный кандидат или не показывать доступные адреса. Критерий не «должен быть только один IP», а «не должен появляться реальный публичный выход, который нужно изолировать».
Что выбрать в MostLogin: Private или Disabled?
Если нужны аудио/видео, клиентские звонки или демонстрация экрана, выбирайте Private и перепроверяйте. Если WebRTC не используется вообще, можно выбрать Disabled. Disabled может влиять на функции сайта, поэтому это не всегда оптимальное решение по умолчанию для всех сред.
Может ли утечка WebRTC раскрыть реальное имя и точный адрес?
Обычно одного IP недостаточно для получения реального имени или точного адреса, но публичный IP может раскрывать приблизительный регион и провайдера, а также может комбинироваться с аккаунтами, Cookie, фингерпринтами браузера и записями о поведении для формирования более сильных связующих улик.
После утечки достаточно ли просто исправить настройки?
Исправление предотвращает дальнейшее раскрытие, но не может отозвать данные, уже полученные сайтом. Для важного бизнеса следует проверить временной диапазон утечки, затронутые среды и журналы входа; при необходимости завершите старые сессии, обновите учётные данные и наблюдайте за появлением необычных проверок на платформе.
Заключение
Суть утечки WebRTC не в том, «включён ли WebRTC», а в том, раскрывает ли он реальные публичные адреса, несовместимые с текущей прокси-средой. При обнаружении аномалий сначала приостановите конфиденциальные операции, затем выполните сравнение по трём группам данных: реальный IP, IP прокси и WebRTC IP. Пользователи MostLogin обычно могут решить проблему, проверив подключение прокси, выбрав WebRTC Private, включив защиту при сбое прокси, очистив ненужные правила обхода прокси и проверив путь IPv6.
Включение проверки WebRTC в стандартный процесс перед запуском новой среды надёжнее, чем реагирование на аномалии аккаунта после их появления. Повторная проверка после каждой смены прокси, сети или версии клиента обеспечивает долгосрочную согласованность сетевого выхода и фингерпринта браузера.
