VPN включён, внешний IP изменился, но тест показывает DNS-сервер вашего провайдера? Это один из признаков DNS-утечки. Она не означает, что весь трафик внезапно стал открытым, однако часть сетевых метаданных может идти не тем маршрутом, который вы ожидаете от VPN.
Проверять поэтому нужно не только IP-адрес. У исправно настроенного полного туннеля DNS, IPv4, IPv6 и обычный трафик должны работать согласованно.
Что именно называют DNS-утечкой
DNS, или Domain Name System, помогает устройству найти IP-адрес по доменному имени. Когда вы вводите адрес сайта, приложение обычно обращается к DNS-резолверу и спрашивает, куда отправлять соединение.
Без VPN такой резолвер может назначить интернет-провайдер, домашний роутер, операционная система или сам пользователь. После подключения VPN ожидаемое поведение зависит от его конфигурации: сервис может назначить собственный DNS либо разрешить использование другого резолвера, но направить соединение к нему через туннель.
Проблема начинается, когда DNS-запросы обходят предполагаемый VPN-маршрут. Например, веб-трафик идёт к VPN-серверу, а обычный DNS продолжает отправляться напрямую к серверу провайдера.
Отсюда важное различие: DNS-утечка — это прежде всего нарушение ожидаемой маршрутизации. Она не всегда означает передачу DNS в открытом виде. Если приложение использует DNS over HTTPS и соединяется с внешним DoH-резолвером вне VPN, сам DNS-запрос всё ещё зашифрован до резолвера, но этот канал уже существует отдельно от VPN-туннеля.
Какие данные могут раскрыться
Обычный не зашифрованный DNS позволяет наблюдателю на пути увидеть запрашиваемые доменные имена. Это может показать, что устройство обращалось к определённому сайту или сервису.
При этом DNS-запрос обычно не содержит полный URL страницы, пароль или содержимое HTTPS-сессии. Запрос к example.com не сообщает, открывался ли раздел /news или /account.
Есть и ещё одна оговорка: список DNS-запросов не равен точной истории посещений. Приложения могут обращаться к доменам в фоне, браузеры — заранее разрешать имена, а одна страница — загружать ресурсы сразу с нескольких доменов.
Почему DNS начинает обходить VPN
Причина чаще находится не в самом DNS, а в сочетании маршрутов, настроек системы и поведения приложений.
VPN-клиент не назначил нужный DNS
Операционная система должна получить корректные DNS-параметры после создания туннеля. Например, Android позволяет VPN-приложению отдельно указывать DNS-серверы и маршруты для виртуального интерфейса. Если конфигурация неполная, система может продолжить использовать DNS обычной сети.
Включён split tunneling
Раздельное туннелирование специально оставляет часть приложений или направлений вне VPN. Исключённое приложение может пользоваться обычным сетевым маршрутом и системным DNS.
Это не всегда ошибка. Если split tunneling настроен намеренно, результат теста нужно оценивать с учётом этих правил.
Браузер использует собственный DoH
DNS over HTTPS передаёт DNS-запросы внутри HTTPS-соединения. Такой механизм может работать независимо от системного DNS.
Поэтому в тесте иногда появляется Cloudflare, Google или другой публичный резолвер, хотя VPN предлагает собственный DNS. Само по себе это ещё не доказывает утечку: нужно выяснить, проходит ли HTTPS-соединение к DoH-серверу через VPN.
Если оно находится внутри туннеля, обычный провайдер не видит содержимое DNS-запроса. Если DoH идёт отдельно от VPN, появляется дополнительный маршрут, который может противоречить вашей модели приватности.
IPv4 и IPv6 настроены по-разному
VPN может корректно перехватывать IPv4, но неполно обрабатывать IPv6. Тогда часть DNS или другого трафика способна выйти через обычный IPv6-маршрут.
Постоянно отключать IPv6 «для безопасности» — грубый обходной путь. Сначала лучше проверить, поддерживает ли клиент IPv6 и как именно он маршрутизирует эту семью адресов.
Сеть сменилась во время работы
Переход с Wi-Fi на мобильный интернет меняет основной интерфейс, адреса, DNS и маршруты. VPN-клиент должен перестроить туннель под новую сеть. Если на этом этапе возникает задержка или ошибка, часть запросов может уйти напрямую.
Поэтому DNS полезно проверять не только сразу после подключения, но и после переподключения или смены сети.
Как проверить DNS-утечку без ложных выводов
Один скриншот онлайн-теста мало что доказывает. Надёжнее сравнивать несколько состояний.
Сначала отключите VPN и запустите DNS leak test. Запишите, какие резолверы видит сервис: их адреса и организации. Это исходная точка.
Затем подключите VPN с полным туннелем и повторите проверку. Если снова появляется DNS вашего провайдера, хотя клиент должен использовать другой маршрут, есть веская причина исследовать утечку.
После этого проверьте ещё три вещи:
- повторите тест в другом браузере;
- посмотрите, включён ли Secure DNS или DoH;
- проверьте IPv4 и IPv6 отдельно, если сервис это позволяет.
Полезен и тест после разрыва соединения: включите Kill Switch, принудительно переподключите VPN и убедитесь, что в переходный момент DNS не возвращается к обычной сети.
Кеш тоже способен запутать результат. Если имя уже сохранено локально, нового DNS-запроса может не быть. Лучше использовать тест, который создаёт уникальные запросы, либо повторять проверку после очистки кеша.
Как читать результаты теста
Появился DNS интернет-провайдера
Для полного туннеля это наиболее подозрительный сценарий, особенно если до включения VPN отображался тот же резолвер. Проверьте системный DNS, маршрутизацию и настройки VPN-клиента.
Появился публичный DNS
Адрес Cloudflare, Google или другого публичного сервиса не равен автоматически утечке. Его мог выбрать VPN, операционная система или браузер. Вопрос не только в названии резолвера, но и в том, каким маршрутом устройство подключается к нему.
Отображается DNS VPN-провайдера
Это ожидаемый вариант для сервиса, который использует собственную DNS-инфраструктуру. Но один совпавший DNS-тест всё равно не проверяет IPv6, Kill Switch и приложения, исключённые из туннеля.
Что делать, если утечка подтверждена
Начните с самого безопасного: обновите VPN-приложение и верните сетевые параметры к штатной конфигурации клиента. Ручные DNS-настройки, старые профили и сторонние сетевые фильтры иногда конфликтуют между собой.
Если VPN предлагает собственный DNS, сначала протестируйте именно его. Затем временно отключите браузерный DoH или системный Private DNS и повторите проверку. Это не обязательно постоянное решение — такой шаг помогает понять, какой компонент создаёт отдельный маршрут.
Проверьте split tunneling. Браузер или тестовое приложение не должны находиться в списке исключений, если вы хотите проверить полный туннель.
Если проблема проявляется только в IPv6, не ограничивайтесь постоянным отключением протокола. Передайте разработчику клиента результат проверки и уточните поддержку IPv6. Временное отключение здесь полезно как диагностический эксперимент.
Наконец, протестируйте Kill Switch при разрыве и смене сети. Его задача — не только заблокировать веб-страницу после падения VPN, но и не допустить нежелательного обходного маршрута для сетевого трафика в момент переключения.
Частые ошибки при проверке
Первая — считать любой чужой DNS утечкой. Публичный резолвер может работать полностью внутри VPN.
Вторая — менять DNS на 1.1.1.1 или 8.8.8.8 и считать проблему решённой. Смена адреса резолвера ничего не говорит о маршруте к нему.
Третья — проверять только внешний IP. Он может принадлежать VPN-серверу, пока DNS или IPv6 используют другой путь.
Четвёртая — делать вывод по одному браузеру. Встроенный DoH способен давать результат, отличающийся от системного DNS.
DNS over HTTPS и DNS over TLS заменяют VPN?
Нет. DoH и DoT защищают транспорт DNS между клиентом и выбранным резолвером. VPN решает более широкую задачу: создаёт туннель для IP-трафика в соответствии со своими маршрутами.
Эти технологии могут использоваться вместе, но одна не гарантирует правильную работу другой. Зашифрованный DNS всё равно должен идти тем маршрутом, который соответствует вашей модели безопасности.
Может ли DNS-утечка раскрыть пароль?
Сама по себе — нет. DNS сообщает информацию о разрешении имени, а не расшифровывает HTTPS. Пароль и содержимое защищённой TLS-сессии не становятся доступными только из-за того, что DNS ушёл к нежелательному резолверу.
Нужно ли отключать IPv6
Как постоянное решение — обычно нет. Если после временного отключения IPv6 проблема исчезла, вы получили полезный диагностический сигнал: стоит проверить поддержку IPv6 в VPN, маршруты и DNS для этой семьи адресов.
DNS-утечка — это не просто «не тот сервер в тесте». Важнее понять, кто выполняет разрешение имён и каким путём устройство соединяется с этим резолвером.
Для нормальной проверки сравните DNS до и после подключения, учтите DoH, split tunneling и IPv6, а затем повторите тест после разрыва VPN или смены сети. Если проблема воспроизводится, сначала исправляйте маршрутизацию и настройки клиента, а не подбирайте случайный публичный DNS.
Такой подход даёт более точную картину: внешний IP, DNS и остальные сетевые маршруты оцениваются вместе, а не как независимые галочки в онлайн-тесте.