---
description: Принцип работы WebRTC
icon: wave-square
---

# Как работает утечка через WebRTC

Антифрод не «узнаёт» ваш настоящий IP каким-то отдельным запросом. Он **сравнивает два адреса**: тот, с которого пришла TCP-сессия, и тот, который браузер сам сообщает через WebRTC поверх UDP. Расхождение между ними и есть сигнал.

### Механика проверки

Одинакова для всех трёх сценариев:

1. Браузер открывает страницу через SOCKS5-прокси. Весь HTTP/HTTPS идёт по TCP, сайт видит IP прокси.
2. Антифрод отдаёт странице скрипт, который создаёт `RTCPeerConnection` и указывает свой STUN- или TURN-сервер в `iceServers`.
3. Браузер начинает собирать ICE-кандидатов и шлёт на этот сервер **STUN Binding Request по UDP**.
4. STUN-сервер отвечает `Binding Response` с атрибутом `XOR-MAPPED-ADDRESS`. В нём указан публичный адрес источника пакета. Браузер превращает его в **srflx-кандидата**.
5. Скрипт ловит кандидата в `onicecandidate`, вытаскивает из него IP и сравнивает с адресом TCP-сессии.

Ключевой момент - **шаг 3**. Пойдёт ли этот UDP-пакет через прокси или мимо него, решают две вещи: поддерживает ли прокси UDP и умеет ли браузер туда UDP отдавать. Отсюда и три исхода.

<br>

<figure>
  <picture>
    <source srcset="../../.gitbook/assets/webrtc-leak_black.svg" media="(prefers-color-scheme: dark)">
    <img src="../../.gitbook/assets/webrtc-leak_white.svg" alt="Сценарии работы WebRTC через прокси">
  </picture>
</figure>

### Сценарий 1. Прокси передаёт UDP, адреса совпадают

1. TCP-сессия идёт через SOCKS5-прокси, сайт видит `198.51.100.7`.
2. Антифрод подсовывает скрипт со своим STUN-сервером.
3. Браузер открывает UDP-ассоциацию через тот же прокси (`UDP ASSOCIATE`, RFC 1928) и отправляет Binding Request уже из него.
4. STUN видит адрес прокси и возвращает его же в `XOR-MAPPED-ADDRESS`: `198.51.100.7`.
5. Скрипт сравнивает: IP TCP-сессии и srflx-кандидат совпали.

**Итог:** WebRTC работает штатно, кандидаты есть, адреса одинаковые. Профиль выглядит как обычный пользователь, потому что он им и выглядит на уровне сети.

Для этого нужны две вещи одновременно: прокси с поддержкой `UDP ASSOCIATE` и клиент (браузер или антидетект), который реально маршрутизирует WebRTC-трафик в прокси, а не в обход.

***

### Сценарий 2. UDP обходит прокси и раскрывает реальный адрес

1. TCP-сессия идёт через прокси, сайт видит `198.51.100.7`.
2. Антифрод подсовывает скрипт со своим STUN-сервером.
3. Браузер шлёт Binding Request **напрямую с сетевого интерфейса**, минуя прокси.
4. STUN видит настоящий адрес `113.22.13.2` и возвращает его как srflx-кандидата.
5. Скрипт сравнивает: `113.22.13.2` ≠ `198.51.100.7`. Прокси обнаружен, настоящий IP получен.

**Итог:** утечка. Причём антифрод получает не просто «подозрительный» признак, а конкретный адрес.

Почему UDP уходит мимо:

* прокси поддерживает **только TCP**: HTTP-прокси через `CONNECT` умеет передавать только TCP, как и SOCKS5 без `UDP ASSOCIATE`;
* прокси поддерживает UDP, но **браузер не направляет в него UDP**: Chrome по умолчанию не передаёт WebRTC-трафик через настроенный прокси и отправляет его напрямую;
* прокси поднят только для конкретного профиля/расширения, а WebRTC работает на уровне всего процесса.

Если STUN/TURN-сервер в `iceServers` контролирует сам антифрод, ему даже не нужен шаг 5. Он видит настоящий адрес непосредственно в адресе источника входящего UDP-пакета.

Локальные адреса (`192.168.*`, `10.*`) здесь почти не играют роли. Начиная с Chrome 80 host-кандидаты передаются как mDNS-имена вида `<uuid>.local`, поэтому получить данные о локальной сети через WebRTC стало сложнее. В этом сценарии раскрывается именно публичный srflx-адрес.

***

### Сценарий 3. Браузер блокирует WebRTC: утечки нет, но это заметно

1. TCP-сессия идёт через прокси, сайт видит `198.51.100.7`.
2. Антифрод подсовывает скрипт со своим STUN-сервером.
3. `RTCPeerConnection` заблокирован расширением, флагом браузера или подменённым API в антидетекте. STUN-запрос не уходит ни через прокси, ни напрямую.
4. Отвечать некому: `onicecandidate` не срабатывает, сбор кандидатов заканчивается пустым списком.
5. Скрипту нечего сравнивать.

**Итог:** настоящий IP не утёк. Однако антифрод видит другую аномалию: современный Chrome на настольном компьютере, в котором **WebRTC полностью отсутствует**. У большинства обычных пользователей он включён, поэтому пустой список кандидатов повышает оценку риска, как и любое другое несоответствие заявленного user-agent реальному поведению API.

То есть выключение WebRTC меняет утечку адреса на аномалию отпечатка. Иногда это приемлемый размен, но это именно размен, а не решение.