Утечка IP через WebRTC: почему прокси не всегда защищает
Как WebRTC раскрывает реальный IP в обход прокси и VPN, почему это ломает мультиаккаунтинг и как антидетект-браузер закрывает эту дыру.
Команда настраивает прокси на каждый профиль, проверяет гео по IP-чекеру — всё совпадает, страна и город такие, как нужно. А через неделю аккаунт банят с формулировкой про подозрительную активность, или рекламный кабинет видит два разных IP у одной и той же учётки за одну сессию. Чаще всего причина — не прокси и не отпечаток браузера, а протокол WebRTC, который продолжает работать в фоне и честно сообщает сайту реальный IP-адрес машины, даже когда весь остальной трафик идёт через прокси.
Это одна из самых частых причин «необъяснимых» банов при мультиаккаунтинге, и её легко упустить, потому что обычный IP-чекер в браузере её не покажет — он просто проверяет IP, с которого пришёл HTTP-запрос, а не то, что происходит на уровне WebRTC-соединений.
Что такое WebRTC и зачем он вообще нужен
WebRTC (Web Real-Time Communication) — это браузерный API для видеозвонков, голосовой связи и передачи данных peer-to-peer без сервера-посредника. Его используют Zoom в браузерной версии, Google Meet, Discord-звонки в вебе, многие чаты поддержки с видеосвязью. Технология стандартная, встроена во все Chromium-браузеры и Firefox, и отключать её целиком — значит ломать часть сайтов, которые на неё рассчитывают.
Проблема в том, как WebRTC устанавливает P2P-соединение. Чтобы два браузера могли напрямую обменяться видео и голосом, каждый из них должен узнать реальный сетевой адрес собеседника — иначе пакеты некуда слать. Для этого WebRTC использует механизм ICE (Interactive Connectivity Establishment) и STUN-серверы: браузер спрашивает у STUN-сервера, какой у него внешний IP, и получает ответ напрямую, в обход прокси-туннеля, через который идёт весь остальной трафик страницы.
Как именно происходит утечка
Разберём на простом примере. Профиль настроен с прокси где-то в Германии, HTTP-заголовки, язык, таймзона и внешний IP в адресной строке — всё немецкое. Пользователь заходит на сайт, где есть скрытый WebRTC-скрипт (а такие скрипты легко встроить в рекламный баннер, трекер или даже невидимый iframe). Скрипт запускает RTCPeerConnection, браузер обращается к STUN-серверу напрямую через сетевой интерфейс операционной системы — не через прокси, а через реальное подключение компьютера к интернету, — и получает в ответ настоящий внешний IP, скажем, домашний адрес в Киеве.
Этот IP попадает в ICE-кандидаты, которые JavaScript на странице может прочитать и отправить на сервер сайта через обычный fetch-запрос. Для сайта это выглядит так: HTTP-соединение пришло с немецкого IP, а WebRTC сообщил украинский. Для антифрод-системы маркетплейса, рекламной платформы или банка это прямой сигнал: прокси, несовпадение гео, подозрительная активность. Дальше — теневой бан, запрос документов, заморозка баланса.
Хуже то, что утечка происходит без всякого участия пользователя — не нужно разрешать доступ к камере или микрофону, достаточно, чтобы на странице выполнился JavaScript. Это не экзотика: по наблюдениям специалистов по антифроду, WebRTC-детекция встроена в большинство серьёзных систем проверки аккаунтов — от рекламных кабинетов до бирж и банков.
Почему прокси и VPN это не чинят
Здесь кроется частая путаница: кажется, что раз трафик идёт через прокси или VPN, то скрыто всё. На деле прокси на уровне приложения (HTTP/SOCKS5) туннелирует только HTTP(S)-запросы браузера, а WebRTC работает на уровне сокетов операционной системы и STUN-протокола — он может полностью обойти этот туннель, если браузер не настроен иначе. VPN с системным уровнем перехвата трафика справляется лучше, потому что заворачивает весь исходящий трафик машины, включая UDP-пакеты STUN-запросов. Но и тут есть нюансы: часть VPN-клиентов не перехватывает весь UDP-трафик по умолчанию, а split-tunneling (режим, когда часть приложений работает в обход VPN) может случайно включать браузер в исключения.
Подробнее о том, чем в принципе отличается смена IP через VPN от управления отпечатком в антидетект-браузере, разобрано в материале VPN или антидетект-браузер: что меняет IP, а что — отпечаток — WebRTC как раз хорошая иллюстрация того, что смены IP недостаточно, если утекает реальный адрес в обход этой смены.
Как антидетект-браузер закрывает эту дыру
Правильный подход — управлять поведением WebRTC на уровне браузера, а не полагаться только на прокси-туннель. Есть три рабочих режима, и важно понимать разницу между ними, потому что выбор не универсален.
Полное отключение WebRTC. Самый грубый, но надёжный вариант: браузер вообще не отвечает на RTCPeerConnection. Утечки нет физически, потому что нечему течь. Минус — ломаются сайты, которым WebRTC реально нужен: видеозвонки в CRM, встроенные чаты поддержки с видео, некоторые стриминговые сервисы. Для профилей, где видеосвязь не нужна (большинство рекламных кабинетов, маркетплейсов, соцсетей без видеозвонков), это самый простой и безопасный вариант.
Подмена IP в WebRTC на адрес прокси. Браузер отвечает на запросы STUN, но вместо реального IP машины подставляет тот же адрес, что виден через прокси. Сайт получает согласованную картину: HTTP-IP и WebRTC-IP совпадают, видеозвонки продолжают работать. Это более аккуратное решение для профилей, где сайт реально использует видео или голос.
Разрешить только публичный IP без STUN-утечки локальных адресов. Отдельная проблема — WebRTC может раскрывать не только внешний, но и локальные IP-адреса машины в сети (192.168.x.x и подобные), что тоже служит сигналом для антифрода, особенно когда несколько профилей запущены с одного устройства и у всех совпадает локальный IP — это прямая связка аккаунтов между собой, даже если внешние IP у них разные.
В GetAntik WebRTC-политика настраивается для каждого профиля в разделе отпечатка — вместе с остальными параметрами: ОС, версией браузера, экраном, GPU, шрифтами и шумом canvas/WebGL/audio. Это важно именно потому, что WebRTC нельзя рассматривать отдельно от остального отпечатка: таймзона, язык и геолокация в GetAntik подтягиваются с exit IP прокси, и WebRTC-адрес должен укладываться в ту же логичную картину, а не противоречить ей.
Проверка: как убедиться, что утечки нет
Полагаться на глаз нельзя — утечку нужно проверять инструментально, при настройке каждого нового типа профиля или прокси.
- Откройте профиль и зайдите на любой публичный WebRTC-leak-тест (их много, в том числе встроенных в сервисы проверки прокси).
- Сравните три значения: IP в адресной строке браузера (должен быть IP прокси), IP, который показывает сам тест через обычный HTTP-запрос (тоже должен быть IP прокси), и IP, который тест вытаскивает через WebRTC ICE-кандидаты.
- Если третье значение отличается от первых двух — утечка есть, и профиль нужно донастроить до того, как с него начнут работать на реальном аккаунте.
- Отдельно проверьте локальные IP-адреса в выводе теста — если видно что-то вроде
192.168.0.105, при параллельной работе нескольких профилей с одной машины это может стать связующим звеном между ними для внимательной антифрод-системы.
Эту проверку стоит делать не разово, а включить в чек-лист прогрева нового профиля — вместе с проверкой таймзоны, языка и соответствия user-agent реальной версии браузера. Логика та же, что и при работе с прокси-ротацией: описано в материале Ротация IP для профилей: когда менять прокси, а когда нет — WebRTC-настройки нужно перепроверять при каждой смене прокси, потому что новый прокси означает новый «правильный» IP, который должен совпасть с тем, что отдаёт WebRTC.
Частые ошибки команд
Проверяют IP только через IP-чекер, не через WebRTC-тест. Обычный «какой у меня IP» сайт не видит WebRTC-запросы, поэтому всё выглядит идеально до первого реального бана.
Отключают WebRTC глобально на уровне ОС или роутера, а не на уровне профиля. Это ломает видеозвонки сразу во всех профилях и в личном браузере, вместо точечной настройки там, где это нужно.
Используют один и тот же режим WebRTC для всех профилей без разбора задач. Для профиля, где нужна видеосвязь с клиентом через встроенный чат, полное отключение WebRTC означает, что чат просто не заработает — там нужна подмена IP, а не блокировка.
Забывают про локальные IP при параллельном запуске профилей. Несколько браузерных окон с одного ПК почти всегда сидят в одной локальной сети, и если WebRTC отдаёт локальный адрес, это создаёт связку между формально независимыми аккаунтами — даже при разных внешних прокси. Если на одной машине одновременно открыто много профилей, стоит заодно свериться с тем, сколько вообще можно запускать одновременно без деградации по ресурсам — это разобрано в материале Сколько профилей можно открыть одновременно: ресурсы ПК.
Считают, что мобильный прокси или резидентный IP сами по себе решают проблему. Тип прокси определяет только внешний IP и его репутацию, а WebRTC-утечка происходит независимо от того, residential это IP или дата-центровый — протокол просто не в курсе, что прокси вообще существует, если браузер не настроен его учитывать.
Сравнение режимов WebRTC
| Режим | Что видит сайт | Когда применять | Риск |
|---|---|---|---|
| WebRTC отключён | Нет WebRTC-соединений вообще | Рекламные кабинеты, маркетплейсы, соцсети без видео | Не работают видеозвонки и голосовые чаты на сайте |
| Подмена на IP прокси | IP совпадает с HTTP-IP | Сайты со встроенной видеосвязью, саппорт-чаты | Нужно следить, чтобы подмена срабатывала при каждом новом прокси |
| Без ограничений (по умолчанию) | Реальный IP машины | Практически никогда не рекомендуется для мультиаккаунтинга | Прямая утечка, связывающая аккаунты между собой и с реальным адресом |
Почему это не отдельная «фича», а часть общей логики отпечатка
WebRTC стоит воспринимать не как изолированную настройку, а как ещё один параметр, который должен быть согласован с остальными: прокси задаёт внешний IP, таймзону и язык, отпечаток браузера задаёт ОС, экран и параметры рендеринга, а WebRTC-политика должна укладываться в ту же картину и не противоречить ей ни одним байтом. Сайты, которые серьёзно относятся к антифроду, сверяют не одно значение, а десятки, и WebRTC — просто ещё один источник правды, который либо подтверждает легенду профиля, либо её разваливает.
Это же касается истории выбора между обычными профилями Chrome и специализированным инструментом — Chrome из коробки не даёт управлять WebRTC-политикой профиля так тонко, как это нужно для серьёзной работы с несколькими аккаунтами; разница разобрана в материале Профили Chrome или антидетект-браузер: когда хватит обычных.
В GetAntik WebRTC-политика настраивается вместе со всем остальным отпечатком в редакторе профиля, а проверить, что внешний IP профиля действительно соответствует купленному прокси, можно сразу через встроенный менеджер прокси — с проверками и ссылками на ротацию, без переключения между сторонними сервисами. Если нужно быстро поднять десятки профилей с правильными настройками с нуля, стоит посмотреть возможности профилей и раздел скачивания приложения для macOS и Windows.
FAQ
Если отключить WebRTC полностью, что-то сломается в обычной работе с аккаунтом? Сломается только то, что реально использует видео- или голосовую связь через браузер: встроенные видеозвонки, некоторые live-чаты поддержки. Обычный просмотр страниц, формы, загрузка файлов, работа с рекламными кабинетами и маркетплейсами на WebRTC не завязаны и продолжат работать как обычно.
Можно ли проверить WebRTC-утечку без специальных сервисов? Частично да — через консоль разработчика можно вручную выполнить RTCPeerConnection и посмотреть ICE-кандидаты, но это требует базового понимания JavaScript. Для ежедневной практики проще использовать готовые публичные WebRTC-leak-тесты, они дают результат за секунды.
WebRTC-утечка — это то же самое, что утечка DNS? Нет, это разные механизмы с похожим эффектом. DNS-утечка происходит, когда запросы на резолв доменов уходят мимо прокси через системный DNS-резолвер, и провайдер видит, какие сайты вы посещаете. WebRTC-утечка — это раскрытие IP-адреса через P2P-протокол внутри самой страницы. Обе проблемы нужно закрывать отдельно, одна не решает другую.
Нужно ли менять настройку WebRTC при каждой смене прокси? Если выбран режим подмены на IP прокси — да, нужно убедиться, что браузер подставляет актуальный адрес нового прокси, а не закэшированный старый. Если выбран режим полного отключения — ничего менять не нужно, он не зависит от конкретного прокси.