# Как проверить прокси на утечки IP, DNS и WebRTC с помощью ToDetect

Source: https://ipvolt.com/ru/blog/proxy-leak-check-todetect
Markdown: https://ipvolt.com/ru/blog/proxy-leak-check-todetect.md
Language: ru

[ipvolt — главная](https://ipvolt.com/ru.md) / [Блог](https://ipvolt.com/ru/blog.md) / Проверка прокси на утечки IP, DNS и WebRTC с помощью ToDetect

Анализ
Опубликовано: 2026-10-23
Обновлено: 2026-10-23
Автор: ipvolt
8 мин чтения

Проверяем браузерный прокси на утечки IP, DNS, WebRTC и часового пояса бесплатными инструментами ToDetect. Пример — замеры на мобильной линии 4G.

Прокси в браузере меняет то, откуда приходят запросы страницы. Но DNS-запросы, соединения WebRTC и часовой пояс браузера всё равно могут указывать на собственную сеть машины. В этой статье показано, как проверить каждый из этих пунктов бесплатными инструментами ToDetect, как выглядят успешный и неудачный результат и какие исправления сработали в нашем тесте.

Пример основан на реальном тесте, который провёл ipvolt:

- **Когда:** 23 октября 2026 года, с 16:45 до 16:57 UTC.
- **Машина:** Mac с macOS 15.7.4.
- **Браузеры:** Chromium 153 и Firefox под управлением Playwright 1.63.0, в headless-режиме и в обычных окнах.
- **Прокси:** мобильный прокси 4G в сети Vodafone Germany, который мы используем для тестов до запуска; настроен как HTTP-прокси с логином и паролем. Контекст немецких мобильных сетей описан в статье [Прокси для Германии](/ru/guides/germany-proxies).
- **Собственное подключение машины:** выход коммерческого VPN в Таллине (Эстония), то есть адрес дата-центра.
- **Маскировка:** IP-адреса замаскированы на скриншотах и удалены из [файла результатов](/downloads/proxy-leak-check-todetect/results.json), где собраны счётчики и оценки по каждому прогону.

## 1. Запишите исходные значения без прокси

Сначала запустите каждый тест с выключенным прокси, чтобы знать, как выглядит ваше собственное подключение. Наши исходные значения в [IP Quality Check от ToDetect](https://www.todetect.net/ip/): местоположение Таллин, тип IP Datacenter, организация ASN с меткой HOSTING и IP Quality Score 68%. [DNS Leak Test](https://www.todetect.net/dns-leak/) показал один резолвер — резолвер VPN в Эстонии.

## 2. Проверьте IP, который видит сайт

Включите прокси и перезагрузите [IP Quality Check](https://www.todetect.net/ip/). Сверьте с ожидаемыми для прокси значениями четыре поля: местоположение, ISP и ASN, тип IP и часовой пояс.

Через мобильный прокси страница показала Berlin, ISP D2VODAFONE, ASN 3209 (Vodafone GmbH), тип IP Mobile, IP Abuse «No», часовой пояс Europe/Berlin и язык German.

![IP Quality Check от ToDetect через мобильный прокси: Berlin, D2VODAFONE, тип IP Mobile, IP Quality Score 94%](/media/blog/proxy-leak-check-todetect/leak-ip.png)
*IP Quality Check от ToDetect через тестовую линию 4G, 23 октября 2026 года. IP-адрес и префикс замаскированы.*

Оценка складывается из перечисленных вычетов; их можно раскрыть и посмотреть, почему она изменилась:

| Подключение | Тип IP | Оценка | Показанные вычеты |
| --- | --- | ---: | --- |
| Собственное подключение машины (VPN, Эстония) | Datacenter | 68% | IP Usage Frequency -3%, VPS/IDC Provider -25%, Occasional ASN Organization Change -4% |
| Мобильный прокси 4G (Vodafone Germany) | Mobile | 94% | IP Usage Frequency -3%, Regional ISP -3% |

Большая часть разницы приходится на вычет VPS/IDC Provider. Успешный результат означает, что местоположение, ISP и тип IP совпадают с настроенным прокси; часовой пояс с браузером сравнивается на шаге 5. Если вы всё ещё видите свой ISP или город, браузер не использует прокси, и остальные тесты мало что скажут, пока это не исправлено. Оценка отражает собственные базы данных ToDetect; считайте её одним из сигналов.

## 3. Проверьте, где разрешаются DNS-имена

Запустите [DNS Leak Test](https://www.todetect.net/dns-leak/) с включённым прокси. Он показывает DNS-резолверы, которые ответили на DNS-запросы вашего браузера. Успешный результат — список резолверов, принадлежащих сети прокси, или резолвер, выбранный вами намеренно. Неудачный — резолвер вашего провайдера или вашей собственной сети.

Через прокси резолверами были 139.7.74.9 и 139.7.74.10, оба «Vodafone Germany, Germany». Эстонский резолвер из исходной проверки исчез.

![DNS Leak Test от ToDetect через прокси: два резолвера Vodafone Germany](/media/blog/proxy-leak-check-todetect/leak-dns-leak.png)
*Оба резолвера принадлежат Vodafone Germany. IP клиента вверху замаскирован.*

Для HTTP-прокси в Chromium это ожидаемо: в его документации сказано, что «name resolution is always deferred to the proxy» (разрешение имён всегда передаётся прокси) — имя хоста передаётся в запросе CONNECT. Утечки DNS возможны с SOCKS4 или с клиентами SOCKS5, которые разрешают имена локально перед подключением, например curl с `socks5://` вместо `socks5h://`. Этот случай разобран в статье [SOCKS5 и SOCKS5h](/ru/blog/socks5-vs-socks5h).

## 4. Проверьте WebRTC

Откройте [WebRTC Leak Test](https://www.todetect.net/webrtc/). Он спрашивает у 17 STUN-серверов, с какого публичного адреса, по их данным, приходит ваш браузер. Успешный результат — «Not detected» или адрес прокси для каждого сервера. Неудачный — красный баннер «WebRTC IP Exposure Detected» и ваш собственный адрес в полях Public IP.

С настройками по умолчанию оба браузера тест провалили:

- **Chromium по умолчанию:** 13 из 17 STUN-серверов вернули собственный адрес машины (11 или 12 как IPv4, 1 или 2 как IPv6, за три прогона). Остальные 4 показали «Not detected».
- **Firefox по умолчанию:** 10 из 17 вернули собственный IPv4-адрес машины, 4 показали «Not detected». Остальные 3 показали 0.0.0.0, то есть не раскрыли ни один IP; почему так, мы не выясняли.

![WebRTC Leak Test от ToDetect с настройками Chromium по умолчанию: WebRTC IP Exposure Detected](/media/blog/proxy-leak-check-todetect/leak-webrtc.png)
*Страница определяет подключение в Берлине по IP прокси, но STUN-серверы вернули собственный адрес машины (замаскирован): 13 из 17 в этом прогоне. На фрагменте видны три.*

Причина — в транспорте. WebRTC отправляет STUN-запросы по UDP. Обычный HTTP-прокси передаёт только TCP-соединения, поэтому по умолчанию эти запросы уходят через собственное подключение машины, и STUN-сервер видит его публичный IP. RFC 8828 описывает именно этот случай: если разрешён прямой доступ в интернет, «WebRTC's STUN checks will bypass the proxy and reveal the public IP address of the client» (STUN-проверки WebRTC обойдут прокси и раскроют публичный IP-адрес клиента).

### Исправления, которые мы проверили

| Браузер и настройка | STUN-серверы с собственным адресом машины | Результат |
| --- | ---: | --- |
| Chromium по умолчанию | 13 из 17 (три прогона) | Утечка |
| Chromium headless, `--force-webrtc-ip-handling-policy=disable_non_proxied_udp` | 0 из 17 (один прогон) | Успех |
| Chromium в обычном окне, тот же флаг | 13 из 17 (два прогона) | Утечка |
| Chromium в обычном окне, настройка профиля `webrtc.ip_handling_policy` = `disable_non_proxied_udp` | 0 из 17 (два прогона) | Успех |
| Firefox по умолчанию | 10 из 17 (один прогон) | Утечка |
| Firefox, `media.peerconnection.ice.proxy_only` = true | 0 из 17 (один прогон) | Успех |

*В счётчиках учтены и IPv4, и IPv6.*

Флаг командной строки исправил headless Chromium, но не обычное окно. Судя по исходному коду Chromium, этот переключатель читается в headless-оболочке, а обычный Chrome берёт значение из настройки профиля `webrtc.ip_handling_policy`. Документации о том, что в обычном окне флаг игнорируется, мы не нашли, поэтому считайте это результатом измерения, а не задокументированным правилом.

Исправление для Chromium, которое мы проверили замерами, записывает настройку в файл профиля `Default/Preferences` до запуска. В Playwright для этого нужен постоянный контекст:

```js
import { chromium } from 'playwright';
import { mkdtempSync, mkdirSync, writeFileSync } from 'node:fs';
import { tmpdir } from 'node:os';
import { join } from 'node:path';

const dir = mkdtempSync(join(tmpdir(), 'leak-check-'));
mkdirSync(join(dir, 'Default'));
writeFileSync(
  join(dir, 'Default', 'Preferences'),
  JSON.stringify({ webrtc: { ip_handling_policy: 'disable_non_proxied_udp' } }),
);

const context = await chromium.launchPersistentContext(dir, {
  headless: false,
  proxy: {
    server: process.env.PROXY_SERVER,
    username: process.env.PROXY_USERNAME,
    password: process.env.PROXY_PASSWORD,
  },
});
```

`PROXY_SERVER` содержит URL прокси вместе со схемой и портом. Остальная настройка клиента описана в статье [Прокси в Playwright](/ru/guides/playwright-proxy-setup).

Ещё два способа задать ту же настройку в Chrome, которые мы не проверяли:

- Задайте корпоративной политике [WebRtcIPHandling](https://chromeenterprise.google/policies/#WebRtcIPHandling) значение `disable_non_proxied_udp`. Тогда Chrome использует UDP, только если настроенный прокси его поддерживает, а иначе — TCP через прокси. На странице политики указаны раздел реестра Windows и имя настройки для macOS и Linux.
- Установите расширение Google [WebRTC Network Limiter](https://chromewebstore.google.com/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia). Согласно его странице в магазине, блокировка UDP в обход прокси по умолчанию не активна и включается на странице Options.

Согласно определению политики в Chromium и документации `chrome.privacy`, оба способа управляют той настройкой, которую мы задали. После применения любого из них повторите тест WebRTC.

В Firefox откройте `about:config` и задайте `media.peerconnection.ice.proxy_only` значение `true`, чтобы трафик WebRTC шёл только через настроенный прокси. В Playwright передайте эту настройку как `firefoxUserPrefs: { 'media.peerconnection.ice.proxy_only': true }` в `firefox.launch()`. Значение `false` для `media.peerconnection.enabled` полностью отключает WebRTC. Мы проверили только первую настройку, без параметров часового пояса из шага 5.

![WebRTC Leak Test от ToDetect после исправления: все STUN-серверы показывают Not detected](/media/blog/proxy-leak-check-todetect/fixed-webrtc.png)
*Chromium в обычном окне с настройкой профиля: баннера нет, все 17 серверов «Not detected» (видны три).*

## 5. Проверьте часовой пояс

Откройте [Timezone Detection](https://www.todetect.net/timezone/). Страница сравнивает часовой пояс, определённый по IP, с идентификатором часового пояса самого браузера. Если вы проверяете, как сайт ведёт себя для посетителей из местоположения прокси (например, локализованные страницы или размещение рекламы), эти два значения должны совпадать.

С включённым прокси и браузером на настройках машины пояс по IP был Europe/Berlin, а идентификатор часового пояса IANA в браузере — Europe/Vilnius. Это несовпадение идентификатора часового пояса. Прокси меняет сетевой путь, а не настройку часового пояса в браузере. В нашем прогоне ToDetect показал для обоих одинаковое смещение от UTC; различался только идентификатор пояса.

![Timezone Detection от ToDetect: по IP Europe/Berlin, в браузере Europe/Vilnius](/media/blog/proxy-leak-check-todetect/leak-timezone.png)
*Пояс по IP следует за прокси. Идентификатор пояса в браузере остаётся на настройке машины.*

Затем в Chromium мы добавили `timezoneId: 'Europe/Berlin'` и `locale: 'de-DE'` в параметры `launchPersistentContext()` из шага 4. Именно эта комбинированная настройка стоит за скриншотами «после». После этого оба пояса показывали Europe/Berlin.

![Timezone Detection от ToDetect после изменения: оба пояса Europe/Berlin, локаль de-DE](/media/blog/proxy-leak-check-todetect/fixed-timezone.png)
*После изменения: идентификатор часового пояса IANA в браузере — Europe/Berlin, локаль — de-DE.*

В обычном браузере без автоматизации часовой пояс берётся из операционной системы: смените системный часовой пояс и задайте язык в настройках браузера. Этот путь мы не проверяли, поэтому после изменения проверьте страницу ещё раз.

## 6. Обзор отпечатка читайте последним

[Главная страница ToDetect](https://www.todetect.net/) сводит перечисленные проверки в оценку «Browser Fingerprint Consistency», которая, по словам ToDetect, «does not represent a definitive pass or fail result» (не является окончательным результатом «прошёл/не прошёл»). В обычном окне Chromium с постоянным профилем она показала 65% с настройками по умолчанию и 87% после изменений WebRTC и часового пояса, как отображалось на странице. Вычеты Timezone Anomaly и WebRTC Alert исчезли. Оставшиеся вычеты WebDriver и ClientRect вызваны автоматизированным тестовым браузером; остался и вычет Language Anomaly, причину которого мы не установили.

Страница [Bot Detection](https://www.todetect.net/bot-detection/) отмечала аномалии WebDriver и Dev Tool в каждом прогоне, а в headless-прогонах ещё и Headless Chrome — для автоматизации это ожидаемо. Контексты в духе приватного режима и headless-режим добавляли собственные вычеты в отпечатке, поэтому для QA, проверки рекламы или геопроверок тестируйте в том профиле браузера, который будете использовать для реальной работы.

## Что мы не проверяли

Мы не проверяли SOCKS5 в браузере (Chromium не поддерживает авторизацию по логину и паролю на SOCKS5-прокси), Safari, Edge, мобильные браузеры и ротацию IP во время сессии. Эти результаты описывают одну линию, одну машину и один день.

## Чек-лист

1. Запишите исходные значения с выключенным прокси: IP, ISP, тип IP и DNS-резолверы.
2. С включённым прокси убедитесь, что [проверка IP](https://www.todetect.net/ip/) показывает местоположение, ISP и тип IP прокси, а не ваши.
3. Убедитесь, что [DNS Leak Test](https://www.todetect.net/dns-leak/) показывает только резолверы сети прокси или выбранные вами.
4. Запустите [WebRTC Leak Test](https://www.todetect.net/webrtc/). Если появляется ваш собственный адрес, задайте в Chrome настройке `webrtc.ip_handling_policy` значение `disable_non_proxied_udp` или в Firefox настройке `media.peerconnection.ice.proxy_only` значение `true` и повторите тест. Не полагайтесь на флаг командной строки в обычном окне.
5. Если тест зависит от местоположения прокси, приведите часовой пояс и локаль браузера в соответствие с ним (параметрами Playwright или системным часовым поясом и языком браузера в обычном браузере), затем снова проверьте [Timezone Detection](https://www.todetect.net/timezone/).
6. Прочитайте вычеты в отпечатке и отделите вызванные прокси от вызванных вашей тестовой средой.
7. После любого изменения повторите все тесты в той конфигурации браузера, которую будете использовать на самом деле.

ipvolt провёл эти проверки для собственного тестирования перед запуском. Сервис в разработке, доступ откроется в начале ноября. Если хотите узнать, когда это произойдёт, [запишитесь в список раннего доступа](https://ipvolt.com/#waitlist-closing). Одно письмо, когда откроется доступ. Больше ничего.

## Источники

- [Chromium: поддержка прокси в Chrome (net/docs/proxy.md)](https://chromium.googlesource.com/chromium/src/+/main/net/docs/proxy.md)
- [RFC 8828: WebRTC IP Address Handling Requirements](https://www.rfc-editor.org/rfc/rfc8828)
- [Политика Chrome Enterprise: WebRtcIPHandling](https://chromeenterprise.google/policies/#WebRtcIPHandling)
- [Определение политики в Chromium: WebRtcIPHandling.yaml](https://chromium.googlesource.com/chromium/src/+/main/components/policy/resources/templates/policy_definitions/WebRtc/WebRtcIPHandling.yaml)
- [API расширений Chrome: chrome.privacy (webRTCIPHandlingPolicy)](https://developer.chrome.com/docs/extensions/reference/api/privacy)
- [Интернет-магазин Chrome: WebRTC Network Limiter](https://chromewebstore.google.com/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia)
- [Исходный код Chromium: content_switches.cc (force-webrtc-ip-handling-policy)](https://chromium.googlesource.com/chromium/src/+/main/content/public/common/content_switches.cc)
- [Исходный код Chromium: headless_web_contents_impl.cc](https://chromium.googlesource.com/chromium/src/+/main/headless/lib/browser/headless_web_contents_impl.cc)
- [Исходный код Chromium: renderer_preferences_util.cc](https://chromium.googlesource.com/chromium/src/+/main/chrome/browser/renderer_preferences_util.cc)
- [Исходный код Firefox: modules/libpref/init/all.js (настройки media.peerconnection)](https://github.com/mozilla-firefox/firefox/blob/main/modules/libpref/init/all.js)
- [Исходный код Firefox: StaticPrefList.yaml](https://github.com/mozilla-firefox/firefox/blob/main/modules/libpref/init/StaticPrefList.yaml)
- [ToDetect: IP Quality Check](https://www.todetect.net/ip/)
- [ToDetect: DNS Leak Test](https://www.todetect.net/dns-leak/)
- [ToDetect: WebRTC Leak Test](https://www.todetect.net/webrtc/)
- [ToDetect: Timezone Detection](https://www.todetect.net/timezone/)
- [ToDetect: Browser Fingerprint Checker](https://www.todetect.net/)
- [ToDetect: Bot Detection](https://www.todetect.net/bot-detection/)

## Узнайте, когда откроется доступ к ipvolt.

Пока вы здесь

ipvolt в разработке. Оставьте email, и мы один раз напишем, когда откроется доступ.

Одно письмо, когда откроется доступ. Больше ничего.

[Получить ранний доступ](https://ipvolt.com/ru/blog/proxy-leak-check-todetect#waitlist-blog-end)

[Конфиденциальность](https://ipvolt.com/privacy)


## Похожие статьи

- [Python 3.15 для веб-скрапинга: что ставится, а что ломается](https://ipvolt.com/ru/blog/python-3-15-web-scraping.md) (Анализ, 16 окт. 2026 г., 8 мин чтения): pip install scrapy на Python 3.15 без компилятора C падает: у brotli нет колеса cp315. Мы поставили 19 пакетов для скрапинга через pip и uv и проверили остальное.
- [Парсинг японских цен: иены, полноширинные цифры и налоговые метки](https://ipvolt.com/ru/blog/japanese-price-parsing.md) (Анализ, 6 окт. 2026 г., 6 мин чтения): Разбирайте японские цены, не теряя валюту и признак налога. Запустите проверенную Python-фикстуру: полноширинная иена, смешанные цены и намеренные случаи «на проверку».
- [SOCKS5 и SOCKS5h: в чём разница и что отправляют 6 клиентов](https://ipvolt.com/ru/blog/socks5-vs-socks5h.md) (Сравнение, 4 окт. 2026 г., 7 мин чтения): socks5:// не везде означает локальный DNS. Мы записали, что curl, Requests, HTTPX, aiohttp, Playwright и Node отправляют SOCKS5-прокси для каждой схемы URL.

## Связанные руководства

- [Настройка прокси в Playwright](https://ipvolt.com/ru/guides/playwright-proxy-setup.md): Задайте HTTP-прокси с аутентификацией для контекста браузера Playwright, изолируйте состояние теста и диагностируйте навигацию отдельно от подресурсов.
- [Прокси Германии: сети, города и региональные проверки](https://ipvolt.com/ru/guides/germany-proxies.md): Как оценивать прокси Германии: актуальный контекст операторов и роуминга, пределы точности по городу, контроль языка браузера и практический чек-лист приёмки.
- [HTTP и SOCKS5 прокси: выбирайте по типу соединения](https://ipvolt.com/ru/guides/http-vs-socks5-proxies.md): Сравниваем HTTP CONNECT и SOCKS5, разбираем, где выполняется DNS и где проходят границы TLS, и выбираем протокол, который реально поддерживают ваш клиент и провайдер.

## О ipvolt

Технический анализ от команды ipvolt.

Доступ к ipvolt пока не открыт.

[Читать оригинал на английском](https://ipvolt.com/blog/proxy-leak-check-todetect.md)