> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/knowledge-base/ru/concepts/what-is-webrtc.md).
# Что такое WebRTC?
Видеозвонки раньше требовали загруженного приложения. Теперь достаточно ссылки в браузере. Что изменилось — и почему это важно для инструмента конфиденциальности?
## Мультимедиа в реальном времени, встроенное в браузер
**WebRTC** Расшифровывается как Web Real-Time Communication. Это набор возможностей, встроенный в каждый распространённый браузер, который позволяет веб-странице отправлять и получать аудио, видео и данные в реальном времени.
Видеовстречи, голосовой чат в браузере, демонстрация экрана, звонки в поддержку прямо на странице, некоторые онлайн-игры и некоторые инструменты передачи файлов — всё это его использует. Без плагинов, без установки.
Ключевое решение в дизайне вот в чём: для медиапотоков в реальном времени WebRTC старается передавать данные **напрямую между двумя участниками** где только может, вместо того чтобы пропускать всё через серверы компании.
Такое решение имеет смысл. Прямой путь короче, поэтому у звонка меньше задержка. Кроме того, сервису это обходится гораздо дешевле, потому что ему не приходится оплачивать передачу каждой секунды каждого звонка.
Но для прямого соединения нужна вещь, которая обычному веб-сёрфингу никогда не требуется: каждая сторона должна знать, как можно добраться до другой стороны.
## Почему ему приходится искать адреса
Вот в чём проблема. Почти никто не находится напрямую в интернете. Как объясняется в [Публичные, частные и CGNAT-адреса](/knowledge-base/ru/concepts/public-private-cgnat.md), ваше устройство находится за маршрутизатором с частным адресом вроде `192.168.1.14`, который ничего не значит для кого-либо за пределами вашего дома. Ваш провайдер может добавить к этому ещё один уровень.
Итак, ваш браузер по-настоящему не знает свой собственный публичный адрес, и уж тем более не знает, на какой комбинации адреса и порта другая сторона может до него достучаться.
WebRTC решает это, собирая варианты.
* Он перечисляет адреса, которые видит локально — частный адрес в вашей сети и любой IPv6-адрес.
* Он обращается к вспомогательному серверу в интернете, называемому **STUN-сервер**, с простым вопросом: «какой адрес вы видите у этого сообщения?» Ответ сообщает ему публичный адрес и порт, с которых, по всей видимости, идёт его трафик после прохождения через NAT.
* Если прямое соединение оказывается невозможным, он переходит к **серверу-ретранслятору** (TURN), который пересылает медиаданные. Это работает везде, но обходится дороже и добавляет задержку.
Каждый собранный им вариант называется **кандидатом**. Обе стороны обмениваются списками кандидатов, затем систематически перебирают комбинации, пока какая-то не сработает. Весь этот процесс проб и ошибок называется **ICE** — Interactive Connectivity Establishment. Это формальный способ сказать: соберите все возможные способы связи, обменяйтесь списками и используйте ту пару, которая сработает первой.
```mermaid
flowchart LR
Y["Ваш браузер"] -->|"какой адрес
вы видите?"| S["STUN-сервер"]
S -->|"203.0.113.42:54321"| Y
Y -->|"список кандидатов"| P["Другой участник"]
P -->|"список кандидатов"| Y
Y -.->|"прямой медиапоток, если возможно"| P
```
## Почему это может раскрыть ваш IP за VPN
Теперь последствия для конфиденциальности становятся очевидны.
VPN работает так: он перехватывает ваш трафик и отправляет его через зашифрованный туннель. Затем сайты видят адрес VPN вместо вашего. Это хорошо работает для обычного веб-сёрфинга, где весь трафик идёт по тому же маршруту, который указала ваша операционная система.
WebRTC не просто следует по одному этому маршруту. Он намеренно перечисляет каждый адрес и каждый путь, который может использовать, потому что вся его задача — найти способ пройти. В зависимости от того, как настроены ваша система и VPN, такое перечисление может обнаружить:
* ваш реальный публичный адрес, если часть вашего трафика выходит из туннеля — это **раздельный туннель** конфигурация, или VPN-расширение браузера, которое охватывает только запросы страниц браузера
* ваш **IPv6** адрес, если VPN передаёт только IPv4 и оставляет IPv6 без внимания; это очень распространённая причина
* ваш **локальный сетевой адрес**, который не идентифицирует вас глобально, но раскрывает подробности о вашей сети
Страница может прочитать эти варианты с помощью небольшого количества JavaScript. Ей не нужны разрешения, и ей не нужно включать вашу камеру или микрофон. Вот что люди имеют в виду под «утечкой WebRTC»: не недостаток WebRTC, а несоответствие между тем, что WebRTC предназначен делать, и тем, что пользователь VPN считает происходящим.
## Чтение адресов, которые показывает тест
Тест WebRTC обычно сразу перечисляет несколько кандидатов. Они не одинаково значимы.
| Что вы видите | Что это означает |
| --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| Что-то, оканчивающееся на `.local` | Заглушка конфиденциальности браузера для вашего локального адреса. Нормально и работает как задумано. |
| `192.168.x.x`, `10.x.x.x`, `172.16–31.x.x` | Реальный локальный сетевой адрес. Раскрывает структуру вашей сети, а не вашу личность. |
| Публичный адрес, совпадающий с адресом вашего VPN | Верно. Туннель покрывает WebRTC. |
| Публичный адрес, который является *не* адресом вашего VPN | Утечка. Вот это и важно. |
| Адрес IPv6, когда ваш VPN показывает IPv4 | Самая распространённая утечка из всех — ваш VPN не передаёт IPv6. |
Полезное сравнение всегда идёт между адресами, которые находит WebRTC, и адресом, который показывает обычный веб-запрос. Если они не совпадают, что-то утекает из туннеля.
## Что браузеры делают с этим
Браузеры со временем ужесточили это.
* **Локальные адреса скрыты по умолчанию.** Вместо того чтобы раскрывать ваш реальный приватный адрес, браузеры теперь подставляют рандомизированную заглушку — имя mDNS, оканчивающееся на `.local` — если только странице уже не предоставлен доступ к камере или микрофону.
* **Сразу собирается меньше адресов.** Современные браузеры собирают более узкий набор кандидатов, пока звонок действительно не начинает настраиваться.
* **Существуют настройки политики.** Некоторые браузеры и расширения позволяют ограничить WebRTC только маршрутом по умолчанию или полностью отключить его.
Это помогает, но проблему не закрывает. Публичный адрес, обнаруженный через STUN, всё равно остаётся публичным адресом, а отсутствие IPv6 — это проблема конфигурации на вашей стороне, а не то, что браузер может исправить за вас.
Полностью отключить WebRTC — тоже вариант, но с очевидной ценой: видеозвонки в вашем браузере перестают работать. Большинству людей лучше исправить саму утечку — использовать VPN, который работает с IPv6, или VPN, работающий на уровне системы, а не только внутри браузера.
## Распространённые заблуждения
**"WebRTC — это шпионское ПО."** Это стандартная функция для мультимедиа в реальном времени, используемая инструментами, на которые вы полагаетесь. Обнаружение адреса необходимо, чтобы соединение вообще состоялось.
**"Утечка WebRTC означает, что мой VPN сломан."** Чаще это означает, что ваш VPN неполный — обычно не поддерживает IPv6 или покрывает только загрузки страниц в браузере.
**"Если тест показывает `.local` адрес, значит у меня утечка."** Нет. Это заглушка конфиденциальности браузера, работающая правильно. Важно, появляется ли реальный публичный адрес, который не принадлежит вашему VPN.
**"Режим инкогнито это останавливает."** Не останавливает. Инкогнито влияет на хранилище и историю, а не на сетевое поведение.
{% hint style="info" %}
**Посмотрите сами в MyIP**
Инструмент **Теста на утечку WebRTC** на панели управления выполняется именно этот процесс обнаружения и показывается каждый адрес, который находит WebRTC. Если ваш VPN включён и один из этих адресов не принадлежит вашему VPN, ваши настройки прокси не охватывают эти соединения. Он также оценивает ваш тип NAT — полезный контекст для игр и звонков, хотя обнаружение здесь является лишь наилучшим предположением, а не гарантией.
Полный разбор: [Тест WebRTC](/knowledge-base/ru/connection-tools/webrtc-test.md).
{% endhint %}
## Связанные понятия
* [Публичные, частные и CGNAT-адреса](/knowledge-base/ru/concepts/public-private-cgnat.md) — слои NAT, которые WebRTC обходит
* [IPv4 против IPv6](/knowledge-base/ru/concepts/ipv4-vs-ipv6.md) — почему IPv6 — обычный путь утечки
* [Задержка, джиттер и потеря пакетов](/knowledge-base/ru/concepts/latency-jitter-packet-loss.md) — метрики, которые определяют, будет ли звонок звучать хорошо
* [Утечка ли мой реальный IP?](/knowledge-base/ru/diagnose/am-i-leaking-my-real-ip.md) — полный чек-лист утечек
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.ipcheck.ing/knowledge-base/ru/concepts/what-is-webrtc.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.