Как отключить WebRTC? Устраняем утечку IP.

Коротко: если вам важна анонимность и согласованность сетевых сигналов в рекламных аккаунтах и трекинге, отключайте WebRTC полностью только там, где не нужны звонки и видеосвязь; в Chromium-браузерах включайте скрытие локальных IP через mDNS, в Firefox самым надежным способом остаётся переключатель media.peerconnection.enabled=false, а на мобильных — полагайтесь на продуманную конфигурацию мобильных прокси, пермишенов и чек-лист тестов. Теперь разберёмся, почему это работает и как сделать без потери качества трафика.

WebRTC — это набор веб-технологий для обмена аудио, видео и данными «напрямую» между браузерами через ICE-кандидаты (STUN/TURN). Красота WebRTC в низкой задержке, но у медали есть обратная сторона: механизм собирает сетевые кандидаты, в том числе локальные и публичные IP, и некоторые из них становятся доступны сайтам через JavaScript. Так происходит «утечка IP WebRTC», когда сайт узнаёт ваш реальный адрес, даже если вы работаете через прокси, и сопоставляет его с другими отпечатками: User-Agent, языки, часовой пояс, Canvas/WebGL, аудио-фингерпринт, TLS/JA3, DNS-паттерны.

Для арбитража трафика, e-commerce, парсинга, антифрода и управления рекламными кабинетами это критично: несовпадение сетевых сигналов снижает траст, повышает вероятность дополнительных проверок и скрыто режет конверсию. В моей практике (я — Стеценко Денис, партнер «NET-Mart» и основатель LTE CENTER) рациональная стратегия — не всегда «рубить с плеча», а гибко ограничивать WebRTC, чтобы не ломать нужные фичи (звонки в CRM, вебинарные платформы, чат-виджеты), при этом исключая утечки.

Задача — добиться трёх целей одновременно: 1) отсутствие утечки реального (публичного/локального) IP за пределами прокси; 2) сохранение работоспособности тех сайтов, где WebRTC нужен по делу (встречается в виджетах звонков, встраиваемых чатиках и некоторых сериях A/B-инструментов), 3) воспроизводимость профилей: чтобы один и тот же стенд отдавал одни и те же сигналы на разных машинах команды. В Chromium-браузерах (Chrome, Edge, Opera, Brave) базовый метод — включить mDNS-обфускацию локальных адресов и, по возможности, ограничить ICE-кандидаты правилом «только через прокси». Практические шаги: откройте chrome://flags и найдите “Anonymize local IPs exposed by WebRTC (mDNS ICE candidates)”, включите Enabled. Это сокращает экспозицию локальных адресов (RFC1918) и IPv6-вариантов. Далее — контролируйте UDP-трафик, потому что WebRTC предпочитает UDP для низких задержек; если ваш прокси стек работает только по TCP, часть кандидатов может попытаться «обойти» маршрут — это и есть классическая утечка. Подключаем расширение уровня “WebRTC Network Limiter” или актуальные аналоги (в 2026-м часть исторических расширений устарела — выбирайте те, что поддерживают манифест v3 и имеют открытые заметки о mDNS/ICE). Параллельно в uBlock Origin проверьте, чтобы не ломать медиапотоки на нужных доменах — добавьте исключения по списку доверенных сервисов.

В Firefox ключ к жёсткому контролю — about:config. Самый надёжный тумблер: media.peerconnection.enabled=false — полностью отключает WebRTC-стек, что устраняет утечки, но ломает любую веб-звонковую функциональность. Если нужен баланс, используйте связку: media.peerconnection.ice.default_address_only=true и media.peerconnection.ice.no_host=true — тогда браузер не будет отдавать хост-кандидаты и ограничится адресом по умолчанию (обычно прокси-маршрут), существенно снижая риск. Не забудьте протестировать в about:webrtc после перезапуска. Для Edge/Brave/Opera правила схожи с Chrome, включая mDNS-флаг и расширения. В Yandex Браузере отдельного «переключателя» в UI обычно нет, используйте экстеншены и тестируйте кандидаты.

В Safari (macOS/iOS) «полное» отключение для всех сайтов штатно не предусмотрено. Рабочая тактика — granular control: в Настройки сайта → Камера/Микрофон → Отклонять по умолчанию; в меню Разработка → Экспериментальные функции убедитесь, что включена маскировка mDNS ICE candidates для локальных IP. На iOS лучше использовать отдельные браузеры с упором на приватность (например, Firefox Focus) и строгую политику разрешений: без доступа к медиа WebRTC-поток не стартует.

Что важно сделать вне зависимости от браузера:
1) запретить доступ к микрофону/камере там, где они не нужны,
2) проверить IPv6 — он часто «пробивается» по другим интерфейсам,
3) сопоставить сетевые отпечатки: IP/ASN от прокси, DNS-резолвер, часовой пояс, язык, WebGL/Canvas. Утечка WebRTC редко идёт в одиночку: на стороне антифрода она соединяется с «мелочами» и выдаёт реальный контур пользователя. Мобильные прокси здесь стратегически сильны: CGNAT, динамическая адресация, реалистичный TTL/RTT и «человеческий» профиль трафика.

• Включите mDNS-обфускацию локальных IP в Chromium-браузерах и ограничьте ICE-кандидаты в Firefox.
• Тестируйте: chrome://webrtc-internals, about:webrtc и внешние страницы проверки WebRTC, включая IPv6.
• Документируйте профиль: разрешения, расширения, прокси, язык, часовой пояс — для воспроизводимости в команде.

Порядок действий:
1) Откройте chrome://flags и включите “Anonymize local IPs exposed by WebRTC”.
2) Установите расширение, ограничивающее WebRTC-кандидаты до «relay-only» или «default route only» (актуальные решения смотрите по свежим отзывам, избегая заброшенных).
3) Проверьте, что ваш прокси поддерживает UDP или принудительный перевод на TCP без сторонних «дыр».
4) В uBlock Origin или аналогах задайте исключения для рабочих доменов, где WebRTC требуется, иначе сломаете кнопку «Позвонить с сайта».
5) Прогоните тесты в chrome://webrtc-internals — убедитесь, что хост-кандидаты не светятся, а адрес совпадает с прокси/мобильным пулом.

Если вы работаете в команде и реплицируете стенды, Firefox удобен политиками. Базовый конфиг: media.peerconnection.enabled=false — «жёсткий» режим. Для мягкого режима: media.peerconnection.ice.default_address_only=true, media.peerconnection.ice.no_host=true — уменьшаем поверхность утечки. Добавочно: media.navigator.enabled=false (если не нужны устройства), dom.webaudio.enabled — по ситуации (смотрите, чтобы не сломать плееры). Профиль экспортируете, храните в Git, раскатываете скриптами. Тестируете в about:webrtc и на страницах диагностики. Важно: не ломайте нужные звонки в CRM — заведите отдельный профиль браузера «с разрешённым WebRTC» под доверенные домены.

Мобильные прокси — не просто «ещё один» слой, это среда. Сотовые сети (4G/5G, LTE) используют CGNAT и динамический пул адресов. Для антифрод-систем такой трафик выглядит естественно: типичные RTT, поведение TCP/UDP, частота смен IP. Именно поэтому в арбитраже и e-commerce мобильные прокси часто дают выше траст и конверсию, чем датацентровые. Но при «звенящем» WebRTC можно самострелом выдать реальный маршрут: браузер соберёт кандидаты и разотождествит сессии. Значит, надо увязать политику прокси и политику WebRTC.

• Настройте sticky-сессии, чтобы IP-адрес не скакал во время транзакций и авторизаций.
• Определите частоту ротации под задачу: парсинг — одна частота, рекламные аккаунты — другая.
• Подберите ASN/гео под сегмент аудитории, а Timezone/Accept-Language согласуйте с гео IP.

Sticky-сессия (закрепление IP на заданный период) — must-have для любых операций входа, платежей и долгих форм. В моей статистике по 38 проектам, «липкие» сессии на 30–60 минут снижали дополнительные проверки на 21–27% по сравнению с агрессивной ротацией. WebRTC здесь должен быть либо полностью отключён, либо ограничен так, чтобы кандидат всегда указывал на прокси-маршрут. Слишком частая ротация (менее 5 минут) в сочетании с активным WebRTC — прямой путь к деаутентификации сессии и падению LTV трафика.

Даже без WebRTC сайт видит много: Canvas/WebGL, AudioContext, Fonts, список плагинов, платформу, ширину экрана, частоту обновления, HTTP/2/TLS-отпечатки (JA3/JA4). В «серых» сценариях продвижения пытаются «скрыть» всё сразу, но переспам маскировками часто выглядит подозрительно. Задача — согласованность: IP из мобильного пула соответствует ASN оператора, часовой пояс соответствует городу, язык — локали, WebRTC либо выключен, либо отдаёт те же сетевые признаки через прокси. Тогда антифрод-системе просто не за что «зацепиться».

— Рекламные кабинеты и аналитика: используйте мобильные прокси со sticky-сессией 30–120 минут, WebRTC — ограничен (mDNS + no host). Это повышает стабильность верификаций и уменьшает «трение» при смене локаций. — Техподдержка и QA: два профиля браузера — «строгий» (WebRTC off) и «коммуникационный» (разрешён для внутренних доменов). — Парсинг и конкурентная разведка: ротация по расписанию, согласованные часовой пояс/локаль, WebRTC выключен, чтобы не разотождествлять потоки. — Контентные команды: если используются виджеты обратного звонка на собственном сайте, заведите allowlist доменов и убедитесь, что трафик идёт через мобильный прокси, а не прямиком.

Настроить — полдела. Важно встроить в процесс тесты, чтобы каждый профиль и каждая машина в отделе маркетинга/QA вели себя одинаково. Мы используем трёхступенчатый контроль: 1) внутренние страницы браузера (chrome://webrtc-internals, about:webrtc), 2) публичные проверки WebRTC/IPv6/DNS без сохранения логов, 3) автотесты в CI, которые запускают headless-браузер с вашим профилем и делают снимок/лог кандидатов. В чек-листе фиксируем: IP/ASN, наличие локальных кандидатов, IPv6, доступ к камере/микрофону, язык, часовой пояс, DNS-резолвер, веб-API (Canvas/WebGL). Это занимает 3–5 минут и экономит часы, когда «внезапно» начинаются повторные запросы проверок.

• Пример 1: после обновления браузера mDNS флаг сбросился — локальные IP снова видны в кандидатах.
• Пример 2: IPv6 включён у провайдера, а прокси его не туннелирует — сайт видит реальный v6.
• Пример 3: виджет звонка на лендинге не работает из-за блокирующего правил в uBlock Origin.

Соберите Docker-образ с нужной версией браузера и вашим профилем. В пайплайне прогоняйте скрипт: открыть диагностическую страницу, запросить разрешения (или отказать), дождаться сборки ICE-кандидатов, сохранить лог и скриншот. Пороговые условия: нет host-кандидатов, публичный кандидат совпадает с прокси-пулом, IPv6 отсутствует или соответствует политике, язык/таймзона соответствуют плану кампании. Если что-то ломается — билд краснеет, команда получает уведомление в чат.

— Проверка разрешений: камера/микрофон запрещены по умолчанию; — Сетевые отпечатки: IP/ASN, DNS-резолвер из пула, mDNS активен (Chromium), no_host (Firefox); — Геосогласованность: часовой пояс = гео IP, язык интерфейса = язык кампании; — Функциональность: виджеты звонка на доверенных доменах работают; — Логи: результаты тестов прикреплены к задаче/тикету, профиль зафиксирован в описании. Потратьте 5 минут на чек-лист — сэкономите сутки при масштабировании рекламных сетов.

Следите за:
1) Долей сессий с повторными проверками — цель < 3%.
2) Конверсией после авторизации — падение на 5–7 п.п. часто указывает на сетевой рассинхрон.
3) Количеством инцидентов с неработающими виджетами связи.
4) Расхождением IP/ASN с планируемыми гео. На моих проектах внедрение контроля WebRTC + мобильных прокси давало прирост стабильности конверсий на 9–14% и сокращало обращения в техподдержку на 18–25%.

WebRTC — не враг, его нужно дисциплинировать. Уберите утечки, не ломая процессы. Мой практический вывод: в 70–80% кейсов рекламных и продуктовых команд достаточно «мягкого» режима (mDNS + запрет host-кандидатов/ограничение ICE), что закрывает утечки и сохраняет работоспособность виджетов. В оставшихся 20–30% (парсинг, чувствительные входы, многопоток) лучше включать «жёсткий» режим (полное отключение) и держать отдельный профиль для коммуникаций. Мобильные прокси дают естественность трафика и заметный прирост стабильности: в наших замерах это +9–14% к конверсии на стабильных воронках и −18–25% к обращениям в поддержку благодаря согласованным сигналам. Работайте по чек-листу, фиксируйте профили, не забывайте про IPv6 и DNS — и WebRTC перестанет быть источником сюрпризов, а станет управляемым инструментом.

В: Полностью отключать WebRTC или ограничить?
О: Если у вас нет потребности в звонках/видео, отключайте. Если виджеты связи нужны, используйте mDNS и запрет host-кандидатов — это убирает утечки без поломок.

В: Даст ли мобильный прокси сам по себе защиту от утечек?
О: Нет. Он делает трафик правдоподобным, но без настроек браузера (mDNS/ICE) WebRTC может выдать адреса мимо прокси. Используйте оба слоя.

В: Насколько опасен IPv6 в контексте WebRTC?
О: Очень. Часто v6 идёт по другому интерфейсу. Если ваша политика не покрывает IPv6, вы получите утечку даже при «закрученном» v4. Либо туннелируйте v6 через прокси, либо отключайте.

В: Какие расширения выбрать для Chromium?
О: Те, что поддерживают актуальный манифест, явно управляют ICE (relay/default route) и регулярно обновляются. Избегайте заброшенных «Disable WebRTC» без поддержки mDNS.

В: Как часто пересматривать настройки?
О: После каждого крупного обновления браузера и при смене поставщика прокси. В идеале — автотест в CI раз в неделю, чтобы ловить регрессии заранее.