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

Прокси в браузере меняет то, откуда приходят запросы страницы. Но 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-прокси с логином и паролем. Контекст немецких мобильных сетей описан в статье Прокси для Германии.
• Собственное подключение машины: выход коммерческого VPN в Таллине (Эстония), то есть адрес дата-центра.
• Маскировка: IP-адреса замаскированы на скриншотах и удалены из файла результатов, где собраны счётчики и оценки по каждому прогону.

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

Сначала запустите каждый тест с выключенным прокси, чтобы знать, как выглядит ваше собственное подключение. Наши исходные значения в IP Quality Check от ToDetect: местоположение Таллин, тип IP Datacenter, организация ASN с меткой HOSTING и IP Quality Score 68%. DNS Leak Test показал один резолвер — резолвер VPN в Эстонии.

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

Включите прокси и перезагрузите IP Quality Check. Сверьте с ожидаемыми для прокси значениями четыре поля: местоположение, ISP и ASN, тип IP и часовой пояс.

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

IP Quality Check от ToDetect через тестовую линию 4G, 23 октября 2026 года. IP-адрес и префикс замаскированы.

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

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

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

Запустите DNS Leak Test с включённым прокси. Он показывает DNS-резолверы, которые ответили на DNS-запросы вашего браузера. Успешный результат — список резолверов, принадлежащих сети прокси, или резолвер, выбранный вами намеренно. Неудачный — резолвер вашего провайдера или вашей собственной сети.

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

Оба резолвера принадлежат Vodafone Germany. IP клиента вверху замаскирован.

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

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

Откройте WebRTC Leak Test. Он спрашивает у 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; почему так, мы не выясняли.

Страница определяет подключение в Берлине по 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-адрес клиента).

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

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

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

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

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.

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

• Задайте корпоративной политике WebRtcIPHandling значение disable_non_proxied_udp. Тогда Chrome использует UDP, только если настроенный прокси его поддерживает, а иначе — TCP через прокси. На странице политики указаны раздел реестра Windows и имя настройки для macOS и Linux.
• Установите расширение Google WebRTC Network Limiter. Согласно его странице в магазине, блокировка 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.

Chromium в обычном окне с настройкой профиля: баннера нет, все 17 серверов «Not detected» (видны три).

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

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

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

Пояс по IP следует за прокси. Идентификатор пояса в браузере остаётся на настройке машины.

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

После изменения: идентификатор часового пояса IANA в браузере — Europe/Berlin, локаль — de-DE.

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

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

Главная страница ToDetect сводит перечисленные проверки в оценку «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 отмечала аномалии WebDriver и Dev Tool в каждом прогоне, а в headless-прогонах ещё и Headless Chrome — для автоматизации это ожидаемо. Контексты в духе приватного режима и headless-режим добавляли собственные вычеты в отпечатке, поэтому для QA, проверки рекламы или геопроверок тестируйте в том профиле браузера, который будете использовать для реальной работы.

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

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

Чек-лист

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

ipvolt провёл эти проверки для собственного тестирования перед запуском. Сервис в разработке, доступ откроется в начале ноября. Если хотите узнать, когда это произойдёт, запишитесь в список раннего доступа. Одно письмо, когда откроется доступ. Больше ничего.

Теги:ProxiesTroubleshooting