Утечка DNS возникает, когда VPN уже включён, внешний IP вроде бы сменился, но запросы к доменным именам уходят не через туннель, а к DNS-серверу провайдера, роутера, корпоративной сети или отдельного браузерного резолвера. Сайт видит VPN-адрес, а оператор сети всё равно может увидеть, какие домены запрашивает устройство. Не страницы, не содержимое HTTPS-соединений, но сами имена сайтов часто уже раскрывают достаточно.
Проверка DNS leak занимает пять минут, но результаты легко прочитать неправильно. Cloudflare, Google или Quad9 в отчёте не всегда означают аварию. Иногда VPN сам использует публичный резолвер. Иногда браузер включает DNS-over-HTTPS и обходит системные настройки. Иногда тест показывает корпоративный split DNS, который нужен для работы. Поэтому проверять надо не «зелёную галочку», а маршрут: кто отвечает на DNS-запросы, совпадает ли ответ с логикой VPN и не всплывает ли ваш обычный интернет-провайдер.
Что именно может утечь через DNS
DNS превращает имя вроде example.com в IP-адрес. До установки соединения с сайтом система или браузер обычно спрашивает DNS-сервер, куда вести трафик. VPN должен увести такие запросы в зашифрованный туннель или выдать собственный DNS внутри туннеля. Если запрос уходит в обход, сеть получает список доменов, к которым обращается устройство.
Содержимое HTTPS-страниц через обычную DNS-утечку не раскрывается. Провайдер не увидит текст переписки, пароль или точный адрес страницы после домена. Но домены всё равно чувствительны: банк, клиника, рабочий сервис, мессенджер, облачное хранилище, панель администрирования. Для приватности часто хватает самого факта обращения.
Материал предназначен для легального и ответственного использования. Проверяйте собственные устройства, свои VPN-подключения и инфраструктуру, где у вас есть разрешение. Соблюдайте законы своей страны, особенно России. Не используйте инструкции для несанкционированного доступа, слежки, взлома, нарушения правил сервисов или незаконного обхода блокировок.
Быстрый тест: как проверить VPN на DNS leak
Начните с контрольного замера без VPN. Откройте страницу проверки DNS, например BrowserLeaks, и запишите три вещи: внешний IP, страну, провайдера DNS. После включения VPN картина должна измениться. Если внешний IP сменился, но DNS-серверы остались от домашнего провайдера, мобильного оператора или роутера, защита работает неполно.
- Выключите VPN и закройте лишние вкладки браузера.
- Откройте DNS-тест и запишите текущие DNS-серверы.
- Включите VPN в полноценном приложении, а не только в браузерном расширении.
- Перезапустите браузер или откройте новое приватное окно.
- Повторите проверку через BrowserLeaks и через второй сервис, например Mullvad Check.
- Сравните результаты: DNS не должен указывать на вашего обычного провайдера, домашний роутер или корпоративный DNS без причины.
Один тест может ошибиться из-за кэша, Anycast-маршрутизации, геобазы IP-адресов или особенностей браузера. Два независимых теста снижают риск ложной тревоги. Если оба показывают один и тот же DNS-провайдер вне VPN, проблему уже стоит разбирать.
Как читать результаты без паники
| Что показывает тест | Как трактовать | Что делать |
|---|---|---|
| DNS совпадает с вашим домашним провайдером | Вероятная утечка DNS | Включить защиту от DNS leak в VPN, сбросить DNS, проверить kill switch и IPv6 |
| DNS показывает Cloudflare, Google, Quad9 или NextDNS | Не всегда утечка. Возможно, браузер или система использует отдельный защищённый DNS | Проверить настройки Secure DNS, Private DNS, DoH или DoT |
| DNS принадлежит VPN-провайдеру | Обычно нормальный результат | Повторить тест после смены сервера VPN и перезапуска браузера |
| DNS показывает страну, отличную от выбранного VPN-сервера | Может быть Anycast или внешний DNS-партнёр VPN | Смотреть не только страну, но и организацию, ASN и повторяемость результата |
| WebRTC показывает реальный IP | Проблема не в DNS, а в браузерной утечке или расширении вместо полноценного VPN | Проверить WebRTC, использовать системный VPN-клиент, обновить браузер |
Самый опасный сценарий выглядит просто: IP-адрес сайта видит как VPN, а DNS-запросы уходят к провайдеру последней мили. Пользователь думает, что весь трафик спрятан, хотя список доменов остаётся у сети доступа. Самый частый ложный сценарий другой: тест показывает Cloudflare, пользователь пугается, но Cloudflare включён в браузере как DNS-over-HTTPS и провайдера в цепочке нет. Приватность в таком случае зависит уже от доверия к выбранному DNS-сервису, а не от VPN.
Почему VPN может пропускать DNS-запросы мимо туннеля
Первая причина — браузерный DNS-over-HTTPS. Chrome, Edge, Firefox и другие браузеры умеют отправлять DNS-запросы не системному резолверу, а выбранному DoH-сервису. Cloudflare описывает такую настройку в своей инструкции по браузерам. Шифрование DNS само по себе полезно, но при включённом VPN появляется нюанс: браузер может не использовать DNS-сервер VPN, а строить отдельный канал к публичному резолверу.
Вторая причина — Android Private DNS. На Android 9 и новее функция «Частный DNS» шифрует DNS через DNS-over-TLS на системном уровне. Если в телефоне вручную указан сторонний DNS-провайдер, часть VPN-приложений корректно перехватывает запросы, а часть конфликтует с такой настройкой. При странных результатах теста временно переключите Private DNS в автоматический режим или отключите вручную заданный хост и повторите проверку.
Третья причина — split tunneling. Пользователь сам разрешает части приложений или доменов идти вне VPN. Удобно для банковских приложений, локальной сети, принтеров и рабочих сервисов, но DNS в таком режиме легко становится смешанным: часть запросов идёт через VPN, часть через обычную сеть. Для приватного режима split tunneling лучше отключать.
Четвёртая причина — IPv6. Некоторые VPN-сервисы туннелируют только IPv4 или неправильно обрабатывают IPv6-маршруты. В результате DNS-тест с IPv6-запросами может показать серверы провайдера, хотя IPv4 выглядит чисто. Хороший тест проверяет и IPv4, и IPv6, поэтому не игнорируйте отдельные строки с IPv6-only доменами.
Пятая причина — корпоративные VPN и split DNS. В рабочей сети домены вида internal.company или git.company могут специально резолвиться через корпоративный DNS, а обычные сайты — через локальную сеть или публичный резолвер. Для офиса такое поведение бывает нормой, но для личного приватного VPN такая логика чаще лишняя.
Проверка через командную строку
Браузерный тест показывает, чем пользуется браузер. Система может вести себя иначе. Поэтому полезно проверить DNS на уровне операционной системы. Команды ниже не взламывают сеть и не меняют настройки, а только показывают, куда устройство отправляет запросы.
Windows
Сначала посмотрите DNS-серверы сетевых интерфейсов:
- PowerShell: Get-DnsClientServerAddress
- Классическая команда: ipconfig /all
Затем очистите кэш и проверьте резолвинг после включения VPN:
- ipconfig /flushdns
- nslookup example.com
Если nslookup обращается к DNS домашнего роутера, например 192.168.0.1, 192.168.1.1 или адресу провайдера, VPN не забрал DNS на себя. В корпоративной среде отдельно смотрите политики NRPT: Windows может направлять разные домены к разным DNS-серверам, и такое поведение не всегда ошибка.
macOS
На macOS проверьте активные DNS-серверы так:
- scutil --dns
- dig example.com
В выводе scutil важны блоки resolver и строки nameserver. Если после включения VPN первым остаётся DNS домашнего роутера или провайдера, а не VPN-интерфейс, настройка подозрительная. После смены VPN-сервера повторите проверку: macOS может держать старые записи до переподключения интерфейса.
Linux
На системах с systemd-resolved проверьте маршрут DNS так:
- resolvectl status
- resolvectl query example.com
Смотрите, какой интерфейс получил DNS-сервер и какие домены привязаны к VPN. Для WireGuard, OpenVPN и NetworkManager критично, чтобы DNS VPN-интерфейса имел правильный приоритет. Иначе система может продолжить спрашивать DNS из Wi-Fi или Ethernet, даже когда маршрут по умолчанию ушёл в туннель.
Что исправить, если тест показал утечку
Начните не с ручной прописки 8.8.8.8 или 1.1.1.1, а с настроек VPN-клиента. Надёжнее, когда VPN сам выдаёт DNS внутри туннеля и блокирует внешние DNS-запросы. Ручной публичный DNS может убрать провайдера из отчёта, но не доказывает, что DNS идёт через VPN. Запросы могут просто уйти к другому внешнему оператору.
- Включите в приложении VPN пункты DNS leak protection, kill switch и блокировку трафика вне туннеля.
- Отключите split tunneling на время проверки.
- Проверьте, не задан ли в браузере отдельный Secure DNS или DNS-over-HTTPS.
- На Android временно отключите вручную заданный Private DNS.
- На Windows очистите DNS-кэш командой ipconfig /flushdns и переподключите VPN.
- Проверьте IPv6. Если VPN не поддерживает IPv6, включите блокировку IPv6 в клиенте или на интерфейсе.
- Не используйте только браузерное расширение VPN, если нужна защита всего устройства.
Браузерное расширение часто проксирует только трафик самого браузера и не управляет системным DNS. Мессенджеры, игровые клиенты, обновления ОС и другие приложения в таком случае могут продолжить обращаться к сети напрямую. Для проверки всей системы нужен полноценный VPN-клиент или корректно настроенный туннель на уровне ОС или роутера.
Отдельная ловушка: WebRTC не равен DNS leak
DNS leak и WebRTC leak часто смешивают, потому что оба теста появляются на одной странице. DNS leak касается запросов к доменным именам. WebRTC leak касается сетевых адресов, которые браузер может раскрывать для голосовой связи, видеозвонков и прямых соединений. Если DNS чистый, но WebRTC показывает ваш реальный публичный IP, проблема всё равно серьёзная, просто источник другой.
На современных браузерах поведение WebRTC стало осторожнее, но расширения, старые версии браузеров, нестандартные настройки и прокси вместо VPN всё ещё дают неприятные результаты. Проверяйте WebRTC вместе с DNS, но не чините WebRTC через замену DNS-сервера. Настройки находятся в браузере, VPN-клиенте или политике блокировки прямых соединений.
Когда «утечка» на самом деле нормальная настройка
Не всякий DNS вне бренда VPN означает провал. Некоторые VPN-провайдеры используют сторонние DNS-сети, а тест показывает организацию резолвера, а не сам VPN. Некоторые сервисы арендуют инфраструктуру у дата-центров, поэтому в отчёте всплывает не знакомое название VPN, а хостинг-провайдер. Геолокация IP тоже часто ошибается, особенно у Anycast DNS.
Смотрите на повторяемость. Если при каждом подключении к VPN в Нидерландах DNS стабильно показывает вашего российского, эстонского или другого домашнего провайдера, почти наверняка запросы идут мимо туннеля. Если тест показывает публичный резолвер, который вы сами включили в браузере или системе, вопрос уже не в технической утечке к провайдеру, а в доверии к выбранному DNS-оператору.
Мини-чеклист перед тем как доверять VPN
- Внешний IP после включения VPN не совпадает с вашим обычным IP.
- DNS-тест не показывает домашнего провайдера, мобильного оператора или роутер.
- IPv6-строки в тесте не раскрывают обычную сеть.
- WebRTC не показывает реальный публичный IP.
- Браузерный Secure DNS не конфликтует с VPN.
- Split tunneling выключен или настроен осознанно.
- После перезагрузки устройства результат не меняется в худшую сторону.
Почему DNS-тест показывает Cloudflare, хотя я включил VPN?
Чаще всего браузер или система использует DNS-over-HTTPS или DNS-over-TLS. Такой результат не обязательно означает утечку к провайдеру, но показывает, что DNS-запросы обрабатывает Cloudflare, а не DNS-сервер VPN. Проверьте настройки Secure DNS в браузере и Private DNS на Android.
Можно ли просто прописать 1.1.1.1 или 8.8.8.8 и забыть?
Нет. Публичный DNS может убрать из отчёта DNS вашего провайдера, но не гарантирует маршрут через VPN. Для защиты от DNS leak важнее, чтобы VPN-клиент перехватывал DNS и блокировал запросы вне туннеля.
Нужно ли отключать IPv6?
Не всегда. Если VPN корректно поддерживает IPv6, отключать IPv6 не нужно. Если VPN работает только с IPv4 и тест показывает реальные IPv6-адреса или DNS провайдера, включите блокировку IPv6 в VPN-клиенте либо отключите IPv6 на активном интерфейсе.
VPN в браузере защищает DNS всей системы?
Обычно нет. Расширение защищает только браузерный трафик или отдельные запросы внутри браузера. Системные приложения, игры, почтовые клиенты и обновления ОС могут идти напрямую. Для проверки всего устройства используйте системный VPN-клиент.
Нормальная проверка VPN не сводится к одной зелёной надписи на сайте. Сравните состояние до и после подключения, проверьте DNS через два сервиса, отдельно посмотрите WebRTC и IPv6, затем отключите конфликтующие настройки вроде браузерного DoH или Android Private DNS. Если в результатах больше не появляется ваш обычный провайдер, DNS-запросы идут ожидаемым маршрутом, а kill switch блокирует трафик при обрыве туннеля, защита работает. Если хотя бы один тест стабильно показывает домашнюю сеть, доверять такому подключению нельзя: сначала чините DNS, а уже потом используйте VPN для приватной работы.
