Happ VPN
Тарифы

Утечка DNS: как проверить и устранить

Автор
Дмитрий Соколов, ведущий технический автор
Проверил:
Артём Волков
Проверено:
Опубликовано:
, обновлено
Версия гайда:
1.0

Коротко

DNS-утечка — это ситуация, когда запросы на определение адреса сайта уходят напрямую к резолверу вашей сети, минуя прокси-сервер. В Happ это чаще связано с режимом системного прокси вместо TUN, встроенным в браузер secure DNS или маршрутизацией конкретного домена как прямого соединения.

DNS-запрос — отдельная операция от самого соединения с сайтом, и у прокси-клиентов она не всегда идёт по тому же пути, что основной трафик. В Happ за DNS для доменов через прокси отвечает Remote DNS профиля маршрутизации, а для прямых соединений — Domestic DNS. В режиме TUN обычно перехватывается весь трафик устройства, включая DNS. В режиме системного прокси часть браузеров и приложений резолвит домены локальным DNS мимо прокси-сервера. Отдельный источник утечки — встроенный в браузер secure DNS: он посылает запросы на собственный сервер напрямую, независимо от настроек Happ. Отдельного kill switch, который блокировал бы трафик при обрыве, в документации Happ нет, поэтому при разрыве DNS-запросы на короткое время могут пойти обычным путём системы.

Причины и проверка

DNS-запрос и основное соединение с сайтом — разные операции, и у них не всегда один и тот же путь через прокси.

ПричинаКак проверитьЧто сделать
Включён режим системного прокси, а не TUNПрограмма или браузер резолвит домен напрямую, хотя остальной трафик идёт через проксиПереключитесь в режим TUN, если нужен весь трафик устройства без исключений
В браузере включён собственный secure DNS на отдельный серверВ настройках сети браузера есть отдельный переключатель безопасного DNSОтключите его или укажите тот же адрес, что задан в Remote DNS профиля
Домен попал в список прямых соединений профиля маршрутизацииПроверьте DirectSites и правила GeoSite профиля подпискиУточните у провайдера, осознанно ли домен вынесен в прямые соединения
Соединение только что оборвалось и восстанавливаетсяУтечка проявляется коротким всплеском в момент разрыва, а не постоянноПереподключитесь и повторите проверку в установившемся соединении
Domestic DNS настроен на резолвер вашей сети вместо стороннегоСравните адрес Domestic DNS в профиле с адресом резолвера сетиЭто может быть штатным поведением для доменов с прямым соединением, а не утечкой
Устройство получило IPv6-адрес, а обрабатывается преимущественно IPv4-трафикСравните поведение с выключенным IPv6 на устройствеСм. отдельный разбор на странице проблем с IPv6

Диагностика по шагам

  1. Зафиксируйте, каким способом вы обнаружили утечку

    Способ проверки важен: разные инструменты и сервисы показывают разные аспекты DNS-резолвинга, и результат стоит перепроверить хотя бы одним альтернативным способом.

    Результат: Вы точно знаете, что проверяли: адрес отвечающего DNS-резолвера, доступность конкретного сайта или что-то другое.

  2. Проверьте режим подключения

    В режиме системного прокси заранее ожидайте, что часть программ, включая некоторые браузеры, может резолвить DNS отдельно от прокси-трафика.

    Результат: Вы знаете, включён TUN или системный прокси.

  3. Проверьте secure DNS в браузере

    Раздел называется по-разному в разных браузерах, но обычно находится в сетевых настройках или настройках приватности.

    Результат: Настройка безопасного DNS в браузере выключена или указывает на тот же сервер, что и Remote DNS профиля.

  4. Проверьте профиль маршрутизации для конкретного домена

    Если подписка не зашифрована, параметры профиля можно посмотреть в настройках подписки; для зашифрованной подписки эти данные скрыты и известны только провайдеру.

    Результат: Понятно, попадает ли проверяемый домен в правила прямого соединения или идёт через прокси.

  5. Повторите проверку в режиме TUN

    Если утечка пропадает в режиме TUN, причина была именно в режиме подключения, а не в самом сервере или профиле.

    Результат: Результат проверки отличается или совпадает с результатом в режиме системного прокси.

  6. Повторите проверку через несколько минут стабильного соединения

    Так вы отделите разовый всплеск в момент переподключения от постоянной утечки.

    Результат: Результат не меняется между разными попытками при одинаковых настройках.

Проверка результата

  • Способ обнаружения утечки понятен и воспроизводится повторно.
  • Режим подключения — TUN или системный прокси — определён и учтён при проверке.
  • Secure DNS в браузере проверен отдельно от настроек Happ.
  • Домены из правил прямого соединения профиля маршрутизации проверены отдельно от остальных.
  • Результат стабилен при повторной проверке в установившемся соединении.

Когда обращаться к провайдеру

Remote DNS, Domestic DNS и правила профиля маршрутизации задаёт провайдер подписки, а не сам Happ. Если после проверки режима подключения и настроек браузера утечка сохраняется именно для доменов, которые должны идти через прокси, вопрос — к провайдеру.

Опишите провайдеру, какой домен и каким способом проверки показал утечку, а также режим подключения — TUN или системный прокси. Изменить или получить объяснение значений Remote DNS и правил маршрутизации может только он: подробнее об этих параметрах — на странице DNS в Happ и в глоссарии Domain Strategy. Смежная тема с похожими причинами — проблемы с IPv6 при включённом Happ.

Главное

  • Remote DNS и Domestic DNS — два независимых параметра профиля маршрутизации Happ: первый обслуживает домены через прокси, второй — домены с прямым соединением.
  • Режим TUN обычно перехватывает весь трафик устройства, включая DNS-запросы; режим системного прокси охватывает только программы, которые учитывают настройки прокси Windows или другой системы.
  • Встроенный в браузер secure DNS может отправлять запросы на собственный сервер напрямую, независимо от настроек DNS в Happ.
  • Отдельного механизма kill switch, который блокировал бы весь трафик при обрыве соединения, в документации Happ нет.
  • Если домен ошибочно попал в список прямых соединений профиля маршрутизации, его DNS-запрос обслужит Domestic DNS, а не Remote DNS.

Частые вопросы

Как вообще заметить утечку DNS, не имея специальных инструментов?

Косвенный признак — сайт, который должен быть недоступен без прокси, всё равно открывается быстро и с провайдером интернета, который виден в сетевых настройках устройства, а не ожидаемым сервером. Точнее это проверяют сервисом, который показывает адрес отвечающего DNS-резолвера: если он совпадает с обычным резолвером вашей сети при включённом Happ, вероятна утечка.

Влияет ли выбор TUN или системного прокси на риск утечки DNS?

Да, это одна из главных переменных. Режим TUN обычно перехватывает весь сетевой трафик устройства на уровне интерфейса, включая DNS-запросы. Системный прокси действует только на программы, которые прочитали настройки прокси системы; часть из них резолвит домены отдельным системным запросом, минуя сам прокси, даже когда весь остальной трафик идёт через него.

Может ли браузер быть причиной утечки, даже если Happ настроен правильно?

Может. Современные браузеры умеют сами отправлять DNS-запросы через свой secure DNS на собственный сервер, независимо от системных или прокси-настроек. Если такая функция включена в браузере, часть его запросов может идти мимо DNS, который настроен в профиле маршрутизации Happ. Проверьте настройки secure DNS именно в браузере, а не только в Happ.

Что делать, если конкретный сайт всегда резолвится напрямую?

Проверьте профиль маршрутизации подписки: возможно, домен или его провайдер CDN попал в список прямых соединений DirectSites или подходит под правило GeoSite для прямого доступа. Такие правила задаёт провайдер подписки, и для конкретного домена это может быть осознанным решением, а не ошибкой.

Правда ли, что без kill switch каждое подключение начинается с утечки?

Нет, отсутствие отдельного механизма kill switch в документации Happ не означает утечку при каждом подключении — оно означает лишь, что при обрыве уже установленного соединения трафик и DNS-запросы не блокируются автоматически, а могут временно пойти обычным системным путём. Для устойчивого соединения это не проблема; риск актуален именно в моменты разрыва и переподключения.

Связана ли утечка DNS с проблемами IPv6?

Да, это смежная причина. Если сеть выдаёт устройству IPv6-адрес, а туннель полноценно обрабатывает только IPv4, DNS-запросы по IPv6 теоретически могут пойти отдельным путём. Подробный разбор именно этой ситуации — на странице «Проблемы с IPv6 при включённом Happ».

Упомянутые темы

Похожие материалы

Разделы по теме

Источники

  1. Документация Happ: геонастройки и маршрутизация — обращение 28 сентября 2026
  2. Документация Happ: локальные подключения (LAN) — обращение 28 сентября 2026
  3. Документация Xray: DNS — обращение 28 сентября 2026