Почему браузер показывает реальный IP при включённом прокси: разбор утечек DNS и WebRTC

Корень проблемы: прокси не равен анонимности

Включил прокси в настройках системы — и думаешь, что всё. Через пять минут заходишь на 2ip.ru, а там твой реальный адрес. Знакомая картина?

Дело в том, что системный прокси — это не VPN. Он не перехватывает весь трафик. Он лишь говорит приложениям: "ходи через этот адрес". Но не все приложения слушаются. Браузеры — особенно.

HTTP-прокси работает на уровне прикладного протокола. Он обрабатывает только те запросы, которые явно через него отправлены. Всё остальное — DNS-запросы, WebRTC-соединения, QUIC-трафик — уходит напрямую, минуя прокси.

Утечка DNS: когда браузер спрашивает дорогу напрямую

DNS — это телефонная книга интернета. Вы вводите `example.com`, браузер спрашивает у DNS-сервера: "где живёт этот сайт?" Если этот запрос идёт мимо прокси — утечка.

Большинство прокси передают DNS-запросы через туннель. Но есть нюанс: если в настройках системы прописан DNS-сервер провайдера, браузер может обратиться к нему напрямую. Особенно это касается Chrome и Firefox с включённой опцией "использовать системный DNS".

Проверить просто:

```bash

dig +short example.com

```

Если ответ приходит от адреса, который не принадлежит прокси — утечка.

WebRTC: дыра, о которой все забыли

WebRTC — технология для браузерных звонков и видеоконференций. Она устанавливает P2P-соединения напрямую между браузерами. Для этого браузер собирает все доступные IP-адреса устройства — включая реальный — и отправляет их на сервер.

Даже если весь HTTP-трафик идёт через прокси, WebRTC-запросы летят напрямую. Браузер считает: "это медиатрафик, ему нужна низкая задержка, прокси будет мешать".

Пример: открываете `browserleaks.com/webrtc` — и видите свой реальный IP, хотя прокси включён. Это не баг, это архитектура.

Как устроен механизм утечки: технические детали

Когда вы включаете прокси в настройках браузера, происходит следующее:

1. Браузер получает список адресов прокси (HTTP, HTTPS, SOCKS).

2. Для каждого запроса он решает: идти через прокси или напрямую.

3. DNS-запросы обрабатываются отдельно — часто системным резолвером.

4. WebRTC использует STUN-серверы для определения внешнего адреса.

STUN-сервер — это специальный сервис, который говорит браузеру: "твой внешний адрес — такой-то". Браузер отправляет STUN-запрос напрямую, не через прокси. Ответ содержит реальный IP.

```javascript

// Пример кода для проверки утечки WebRTC

const pc = new RTCPeerConnection({

iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]

});

pc.createDataChannel('test');

pc.onicecandidate = e => {

if (e.candidate) {

console.log(e.candidate.candidate);

}

};

pc.createOffer().then(o => pc.setLocalDescription(o));

```

Запустите это в консоли браузера — и увидите список адресов, включая реальный.

QUIC и HTTP/3: новый протокол — новые дыры

Протокол QUIC работает поверх UDP. Он не использует TCP-соединения, поэтому классические прокси его не обрабатывают. Если сайт поддерживает HTTP/3, браузер может переключиться на QUIC и отправить запрос напрямую.

Это особенно актуально для Chrome — он активно продвигает HTTP/3. Firefox тоже поддерживает, но менее агрессивно.

Решение: отключить QUIC в браузере или использовать прокси, который поддерживает UDP-туннелирование.

IPv6: двойной стек — двойные проблемы

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

Особенно хитро это работает в Chrome: он может одновременно использовать IPv4 через прокси и IPv6 напрямую. Внешний сервис увидит оба адреса.

Реальный кейс: сервер на nginx 1.24 с `listen [::]:443;` и `listen 443 ssl;`. Клиент с включённым прокси подключается по IPv6 напрямую — nginx видит реальный IP. Адрес прокси даже не фигурирует в логах.

Расширения и плагины: дыры в дыре

Некоторые расширения обходят прокси по своей инициативе. Например, VPN-расширения, которые работают только для определённых сайтов. Или блокировщики рекламы, которые обращаются к своим серверам напрямую.

Пример: расширение для блокировки рекламы uBlock Origin отправляет запросы к спискам фильтров напрямую, не через прокси. Если эти запросы содержат ваш IP — утечка.

Как проверить утечки: пошаговая инструкция

Сначала проверьте DNS:

```bash

curl --proxy http://proxy.example.com:8080 https://api.ipify.org

```

Если ответ содержит IP прокси — HTTP-трафик идёт правильно. Теперь DNS:

```bash

dig @8.8.8.8 example.com

```

Если запрос уходит напрямую — утечка. Проверьте WebRTC через browserleaks.com или вручную через консоль. Проверьте IPv6:

```bash

curl -6 --proxy http://proxy.example.com:8080 https://api.ipify.org

```

Если ответ не приходит — прокси не поддерживает IPv6, и трафик уходит напрямую.

Настройка браузера: что можно сделать

В Firefox отключите WebRTC через `about:config`:

```

media.peerconnection.enabled = false

```

В Chrome это сложнее — придётся использовать расширения или политики. Для DNS в Firefox:

```

network.proxy.socks_remote_dns = true

```

Это заставит браузер отправлять DNS-запросы через SOCKS-прокси. В Chrome такой опции нет — только через флаги.

Прокси vs VPN: почему VPN надёжнее

VPN работает на сетевом уровне. Он перехватывает весь трафик — включая DNS, WebRTC, QUIC. Прокси работает на прикладном уровне — он видит только то, что ему явно передали.

Разница видна на цифрах: VPN добавляет 5-15 мс задержки из-за инкапсуляции. Прокси — 1-3 мс. Но VPN не пропускает утечки. Прокси — пропускает.

Исключение: SOCKS5-прокси с поддержкой UDP и удалённого DNS. Он ближе к VPN по поведению, но всё равно не перехватывает WebRTC.

Настройка прокси для минимальных утечек

Если без прокси никак, настройте его правильно. Используйте SOCKS5 с удалённым DNS. В Firefox:

```

network.proxy.socks = "127.0.0.1"

network.proxy.socks_port = 1080

network.proxy.socks_remote_dns = true

network.proxy.type = 1

```

В Chrome — через командную строку:

```bash

google-chrome --proxy-server="socks5://127.0.0.1:1080" --host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE 127.0.0.1"

```

Это заставит Chrome использовать прокси для всех запросов, включая DNS.

Аппаратные и программные решения

Есть прокси-серверы, которые умеют обрабатывать UDP и перехватывать WebRTC. Например, 3proxy с модулем `udppm`. Но это редкость.

Более надёжный вариант — связка прокси + VPN. Трафик сначала идёт через VPN, потом через прокси. Утечки исключены, но скорость падает.

Или используйте прокси на уровне маршрутизации. Например, `redsocks` — утилита, которая перенаправляет весь TCP-трафик через SOCKS-прокси. Она работает на уровне iptables, поэтому перехватывает всё.

Разбор реальных кейсов

**Кейс: Chrome показывает реальный IP на 2ip.ru при включённом прокси**

Проблема: пользователь настроил HTTP-прокси в системных настройках. Chrome показывает реальный IP, Firefox — IP прокси.

Причина: Chrome использует системный DNS-резолвер, который обращается к DNS-серверу провайдера напрямую. Firefox с `network.proxy.socks_remote_dns = true` отправляет DNS через прокси.

Решение: переключить Chrome на SOCKS5 с `--host-resolver-rules`. Проверка: `curl --socks5-hostname 127.0.0.1:1080 https://api.ipify.org` — должен вернуть IP прокси.

**Кейс: WebRTC-утечка на сайте видеоконференций**

Проблема: сайт видеоконференций видит реальный IP, хотя прокси включён.

Причина: WebRTC использует STUN-серверы для определения внешнего адреса. STUN-запросы идут напрямую, минуя прокси.

Решение: отключить WebRTC в Firefox через `about:config`. В Chrome — использовать расширение WebRTC Leak Prevent. Проверка: browserleaks.com/webrtc — не должен показывать реальный IP.

**Кейс: IPv6-утечка при использовании прокси на IPv4**

Проблема: сайт показывает оба адреса — IPv4 через прокси и IPv6 напрямую.

Причина: прокси работает только на IPv4. Браузер видит AAAA-запись в DNS и подключается по IPv6 напрямую.

Решение: отключить IPv6 в настройках сети или настроить прокси на IPv6. Проверка: `curl -6 https://api.ipify.org` — не должен возвращать адрес.

Итог: что делать

Прокси — не анонимизатор. Это инструмент для обхода блокировок и кеширования. Если нужна анонимность — используйте VPN или Tor.

Если прокси обязателен — настройте его правильно. SOCKS5 с удалённым DNS, отключение WebRTC, отключение IPv6. Проверяйте утечки после каждой смены настроек.

И помните: на сайте lexic.ml можно найти прокси с поддержкой SOCKS5 и удалённого DNS. Это снижает риск утечек, но не устраняет их полностью.

Анонимность — это процесс, а не состояние. Проверяйте, настраивайте, проверяйте снова.