- Почему IPv6-прокси «протекает» через WebRTC при работе с TikTok: диагностика утечек в браузере

Почему WebRTC игнорирует настройки прокси

Браузер с настроенным SOCKS5 или HTTP-прокси всё равно отправляет STUN-запросы напрямую через UDP. Это поведение спецификации WebRTC: ICE-кандидаты собираются на уровне сетевого стека ОС, а не через прокси-слой. Прокси перехватывает TCP-трафик, но UDP идёт мимо.

С TikTok ситуация усугубляется. Платформа активно использует WebRTC для стриминга, аналитики и антифрод-проверок. При загрузке ленты браузер открывает несколько RTCPeerConnection к серверам ByteDance. STUN-пакеты уходят с реального IPv6-адреса, даже если HTTP-трафик идёт через прокси.

Что видит TikTok: HTTP-запросы приходят с одного IPv6, ICE-кандидаты — с другого. Расхождение фиксируется на стороне антифрода. Дальше — теневой бан, капча или полная блокировка аккаунта.

```bash

Проверка утечки через chrome://webrtc-internals

Или быстрый тест через curl — какой IP видит внешний сервис

curl -6 --socks5-hostname 127.0.0.1:1080 https://ifconfig.co

curl -6 https://ifconfig.co

```

Если два адреса различаются — утечка есть. Второй запрос идёт напрямую, первый через прокси.

Анатомия ICE: где именно рвётся цепочка

WebRTC использует ICE (Interactive Connectivity Establishment) для поиска путей между пирами. Процесс: сбор кандидатов, обмен через signaling, проверка связности. На этапе сбора браузер опрашивает все сетевые интерфейсы — Ethernet, Wi-Fi, VPN-туннели, loopback.

STUN-сервер (обычно `stun.l.google.com:19302` или серверы ByteDance) возвращает кандидату его публичный адрес. Этот адрес попадает в SDP-описание сессии и уходит второй стороне. Прокси в этой схеме не участвует вообще — UDP-пакеты идут через дефолтный маршрут ОС.

Дальше — хуже. Если машина имеет IPv6, браузер собирает host-кандидаты вида `[2a00:...]:54321`. Эти адреса тоже попадают в SDP. Даже без STUN достаточно host-кандидата, чтобы определить реальную сеть.

```python

Минимальный пример: сбор ICE-кандидатов через aiortc

import asyncio

from aiortc import RTCPeerConnection

async def dump_candidates():

pc = RTCPeerConnection()

await pc.setLocalDescription(await pc.createOffer())

Ждём завершения сбора

while pc.iceGatheringState != "complete":

await asyncio.sleep(0.1)

for line in pc.localDescription.sdp.splitlines():

if line.startswith("a=candidate"):

print(line)

asyncio.run(dump_candidates())

```

В выводе будут адреса всех интерфейсов. Если среди них есть ваш реальный IPv6 — прокси не помогает.

Как TikTok использует эти данные

ByteDance не раскрывает алгоритмы антифрода. Но поведение платформы говорит само: расхождение IP между HTTP-слоем и WebRTC-слоем — сильный сигнал. Особенно когда адреса принадлежат разным AS (автономным системам) или разным странам.

TikTok собирает fingerprint из десятков параметров. WebRTC-кандидаты — один из них. Сюда же идут: разрешение экрана, список шрифтов, WebGL-рендерер, тайминги навигации. Расхождение хотя бы по одному параметру запускает цепочку проверок.

Пример: пользователь заходит через IPv6-прокси из Нидерландов, но WebRTC отдаёт московский IPv6 из сети МТС. Платформа видит несоответствие геолокации. Дальше — либо тихое понижение в ранжировании, либо требование верификации.

Есть нюанс с IPv6. Многие прокси-сервисы поддерживают только IPv4-выход. Если браузер предпочитает IPv6 (Happy Eyeballs, RFC 8305), он может пойти напрямую по IPv6, минуя IPv4-прокси. Это классическая утечка, которую ловят на тестах типа `ipleak.net`.

Диагностика: что смотреть в первую очередь

Открывайте `chrome://webrtc-internals` до загрузки TikTok. Вкладка покажет все созданные PeerConnection, собранные кандидаты, состояние ICE. Ищите строки `candidate` с типом `host` и `srflx`. Если там ваш реальный адрес — проблема подтверждена.

Второй инструмент — `about:networking#dns` в Firefox. Показывает, какие DNS-запросы уходят и через какой резолвер. Утечка DNS — частый спутник WebRTC-утечек. TikTok резолвит домены через локальный резолвер, а не через прокси.

```bash

tcpdump на интерфейсе — видим ли UDP на 3478 (STUN) мимо туннеля

sudo tcpdump -i eth0 -n 'udp port 3478 or udp port 19302' -c 20

```

Если пакеты идут через физический интерфейс, а не через tun0 (VPN) или loopback (локальный прокси) — утечка налицо. На нормальной конфигурации STUN-трафик должен либо блокироваться, либо идти через туннель.

Третий уровень — сравнение AS. Возьмите IP из HTTP-заголовков (через `ipinfo.io`) и IP из WebRTC-кандидатов. Если AS разные — антифрод это увидит. Даже одна и та же страна не спасает: разные провайдеры внутри страны тоже подозрительны.

Закрываем утечку на уровне браузера

Chrome и Firefox дают настройки для отключения WebRTC или ограничения сбора кандидатов. В Firefox: `about:config` → `media.peerconnection.ice.default_address_only` = `true`. Это заставит браузер использовать только дефолтный интерфейс. Но если дефолтный маршрут идёт мимо прокси — не поможет.

Жёстче: `media.peerconnection.enabled` = `false`. WebRTC отключается полностью. TikTok продолжит работать — видео идёт по HTTP/2, не по WebRTC. Но некоторые функции (звонки, live-комментарии) сломаются.

В Chrome флаг `--force-webrtc-ip-handling-policy=disable_non_proxied_udp` заставляет браузер не отправлять UDP мимо прокси. Комбинация с `--proxy-server` даёт предсказуемое поведение. Проверено на Chrome 120+, работает стабильно.

```bash

google-chrome \

--proxy-server="socks5://127.0.0.1:1080" \

--force-webrtc-ip-handling-policy=disable_non_proxied_udp \

--host-resolver-rules="MAP * ~NOTFOUND, EXCLUDE 127.0.0.1" \

--disable-features=WebRtcHideLocalIpsWithMdns

```

Последний флаг отключает mDNS-обфускацию. Без него Chrome прячет локальные IP за `.local`-именами — иногда это ломает сбор кандидатов у TikTok, и платформа падает в fallback-проверки.

Прокси-слой: где ломается IPv6

Прокси с поддержкой IPv6 — редкость. Большинство SOCKS5-серверов работают только по IPv4. Если браузер предпочитает IPv6, он может пойти напрямую, потому что прокси не поддерживает нужное семейство адресов.

Проверка простая: `curl -6 --socks5-hostname 127.0.0.1:1080 https://ifconfig.co`. Если команда падает с ошибкой `Could not resolve host` или `Network is unreachable` — прокси не тянет IPv6. Браузер в такой ситуации молча уходит напрямую.

Решение — либо прокси с полным IPv6-стеком, либо принудительное отключение IPv6 на уровне ОС. Второе грубее, но работает. На Linux: `sysctl -w net.ipv6.conf.all.disable_ipv6=1`. Минус — ломаются сервисы, которые без IPv6 не работают.

Сервисы вроде lexic.ml дают IPv6-выход с 2015 года — это как раз тот случай, когда нужен прокси, умеющий маршрутизировать оба семейства. Иначе браузер будет выбирать короткий путь и утекать.

Кейс: TikTok-аккаунт уходит в теневой бан за неделю

Проблема: пользователь настроил SOCKS5-прокси, заходит на TikTok через Chrome. Через 5-7 дней охваты падают до нуля. Новые видео не набирают просмотров.

Причина: WebRTC отдавал реальный IPv6 из домашней сети. HTTP-трафик шёл через прокси из Германии, ICE-кандидаты — из московского провайдера. TikTok фиксировал расхождение AS (AS24940 Hetzner vs AS25513 МТС).

Детали: `chrome://webrtc-internals` показал 4 host-кандидата, все с префиксом `2a00:1370::/32`. Прокси работал по IPv4, браузер предпочитал IPv6. Happy Eyeballs выбирал IPv6-путь напрямую.

Решение: флаг `--force-webrtc-ip-handling-policy=disable_non_proxied_udp` плюс прокси с IPv6-выходом. После смены конфигурации — новый аккаунт, старый уже помечен. Через две недели охваты вернулись к норме.

Кейс: Firefox и mDNS-обфускация ломают стрим

Проблема: live-трансляция в TikTok через Firefox обрывается через 30-40 секунд. В логах — ошибка ICE.

Причина: Firefox по умолчанию скрывает локальные IP за mDNS-именами вида `abc123.local`. TikTok не может резолвить эти имена, ICE-проверка проваливается. Стрим падает в fallback на TCP, но там таймауты.

Детали: `about:webrtc` показал кандидатов с типом `host` и адресом `*.local`. STUN-кандидаты (`srflx`) собирались нормально, но host-кандидаты были бесполезны для второй стороны.

Решение: `media.peerconnection.ice.obfuscate_host_addresses` = `false` в `about:config`. После перезапуска браузера стрим держится стабильно. Побочный эффект — локальные IP снова видны в SDP, но за прокси это не критично.

Кейс: IPv6-прокси без IPv6-маршрута

Проблема: сервис заявляет поддержку IPv6, но TikTok грузит ленту по 8-12 секунд. Видео буферизуется, комментарии не отправляются.

Причина: прокси принимал IPv6-соединения, но исходящий маршрут был только IPv4. Каждый запрос проходил через NAT64-трансляцию с потерей пакетов. MTU на туннеле — 1280 байт, фрагментация била по производительности.

Детали: `ping6` до прокси показывал 45 мс, но `curl -6` через прокси — таймауты на запросах больше 2 КБ. PMTUD (Path MTU Discovery) не работал, ICMPv6 `packet too big` блокировался файрволом.

Решение: сменили прокси на сервис с нативным IPv6-маршрутом. MTU 1500, без трансляций. Задержка упала до 60-80 мс на запросах к TikTok CDN. Проверка — `curl -w "%{time_total}" -6 --socks5-hostname ...` до и после.

Чеклист перед заходом в TikTok

Проверяйте три вещи. Первое: `ipleak.net` — совпадают ли HTTP-IP, WebRTC-IP и DNS-резолвер. Второе: `chrome://webrtc-internals` — нет ли host-кандидатов с реальным адресом. Третье: `curl -6` через прокси — работает ли IPv6-маршрут вообще.

Если хоть один пункт провален — TikTok это увидит. Антифрод не спит, и расхождение адресов — первый сигнал. Лучше потратить 10 минут на диагностику, чем неделю на восстановление аккаунта.

Отдельно про DNS. Утечка резолвера — тоже маркер. TikTok резолвит свои домены через CDN с геопривязкой. Если DNS-запрос уходит через локальный провайдер, а HTTP — через прокси из другой страны, CDN отдаст сервер не из того региона. Задержки вырастут, а платформа заметит несоответствие. Настройте DNS через прокси или DoH с привязкой к выходному узлу.