VLESS и Private DNS: почему AdGuard, DoH или DNS могут мешать VPN

Иногда VLESS выглядит полностью исправным:

• HAPP показывает подключение;
• сервер отвечает;
• VPN включён;
• соединение не падает;

но сайты при этом:

• не открываются;
• долго висят на загрузке;
• часть доменов работает, часть нет;
• приложения показывают Network error;
• браузер работает, а другие программы нет.

Очень часто пользователь начинает искать проблему в:

• VLESS-ключе;
• SNI;
• сервере;
• transport.

Хотя реальная причина находится раньше:

доменное имя не удаётся правильно преобразовать в IP-адрес.

То есть ломается DNS.

Особенно интересной ситуация становится, если одновременно используются:

• Android Private DNS;
• AdGuard;
• NextDNS;
• DNS over HTTPS;
• Secure DNS браузера;
• DNS внутри HAPP;
• FakeDNS Xray.

Все эти технологии могут быть полезными.

Но чем больше независимых DNS-слоёв работает одновременно, тем сложнее понять, кто именно сейчас разрешает доменное имя.

Разберёмся по порядку.

Что такое DNS

Когда пользователь открывает:

example.com

компьютеру или телефону нужен IP-адрес этого сервера.

DNS выполняет примерно такую операцию:

example.com
↓
DNS
↓
93.184.216.34

Только после этого начинается обычное сетевое соединение.

Поэтому если DNS не работает, пользователь видит:

интернет сломан,

хотя сам VLESS-туннель вполне может быть исправен.

Как выглядит DNS-проблема

Характерные симптомы:

• HAPP показывает Connected;
• сервер быстро подключился;
• но новые сайты не открываются;
• приложение долго показывает «Соединение»;
• некоторые уже открытые соединения продолжают работать;
• после отключения Private DNS всё внезапно оживает.

Очень показательный сценарий:

VPN подключён, но домены не открываются.

Это уже повод проверить DNS раньше, чем менять параметры VLESS.

Что такое Android Private DNS

Android имеет системную функцию:

Private DNS / Частный DNS.

Она позволяет использовать защищённое DNS-соединение.

Google указывает, что Private DNS защищает только DNS-запросы и ответы и не является полноценным VPN.

В Android обычно доступны варианты:

• Выкл.;
• Автоматически;
• имя хоста поставщика Private DNS.

Например, пользователь может вручную указать DNS-провайдера.

Private DNS — это не VPN

Это важнейшее различие.

Private DNS:

домен → защищённый DNS → IP

VPN:

весь подходящий трафик → VPN-сервер → интернет

То есть включённый Private DNS не означает:

интернет идёт через VPN.

Он меняет только способ разрешения доменных имён.

Может ли Private DNS работать одновременно с HAPP

Да, технически эти механизмы могут сосуществовать.

Android Private DNS не создаёт отдельный системный VPN-интерфейс.

Поэтому само наличие:

Private DNS + HAPP

ещё не является ошибкой.

Но возникает вопрос:

через какой маршрут уйдёт DNS-запрос и какой resolver в итоге будет использоваться?

И вот здесь уже возможны проблемы.

Почему Private DNS иногда мешает VLESS

Представим, что пользователь вручную указал:

dns.example.com

Android пытается обратиться к этому resolver.

Но:

• DNS-сервер недоступен через текущую сеть;
• провайдер плохо маршрутизирует его;
• VLESS routing предполагает другую DNS-схему;
• запрос идёт не туда, куда ожидал Xray.

В итоге:

VLESS Connected

но:

домен → не разрешился → сайт не открылся.

Пользователь воспринимает это как неисправность VPN.

Первый тест при подозрении на Private DNS

На Android временно поставьте:

Private DNS → Автоматически.

Google прямо предлагает варианты Off, Automatic и hostname конкретного DNS-провайдера.

После этого:

1. отключите HAPP;
2. подключите заново;
3. попробуйте открыть проблемный сайт.

Если всё заработало, уже есть конкретное направление для диагностики.

Не нужно отключать Private DNS навсегда

Это именно контрольный тест.

Google по умолчанию рекомендует оставлять Private DNS включённым на поддерживаемых сетях.

Если автоматический режим работает нормально вместе с VLESS, можно его оставить.

Проблема чаще возникает при:

• конкретном вручную заданном resolver;
• сложной комбинации DNS-фильтрации;
• конфликте нескольких DNS-механизмов.

Что такое DoH

DNS over HTTPS, или DoH, передаёт DNS-запросы внутри HTTPS.

Вместо обычного DNS:

устройство → DNS server :53

получается что-то ближе к:

устройство → HTTPS → DoH server

Поэтому DNS-трафик становится сложнее отличить от обычного HTTPS.

DoH может использовать сам браузер

Современный браузер способен иметь собственный Secure DNS.

Тогда получается:

Chrome
↓
собственный DoH
↓
DNS provider

При этом остальные приложения используют:

Windows/Android
↓
System DNS

Отсюда возникает классическая странность:

браузер работает, а приложения нет.

На самом деле браузер просто использует другой resolver.

Почему это важно при диагностике VLESS

Представим:

системный DNS сломан

но:

Chrome Secure DNS работает.

Пользователь видит:

• Google открывается;
• YouTube открывается;

но:

• Discord;
• Telegram;
• launcher

не соединяются.

И делает вывод:

VLESS работает только в браузере.

Хотя настоящий диагноз:

браузер обходит проблемный системный DNS через собственный DoH.

Что такое DNS внутри Xray

Xray имеет собственный встроенный DNS-модуль.

Он может использовать разные серверы и разные варианты DNS.

Например:

• обычный DNS;
• DoH;
• DoQ;
• FakeDNS.

Официальная документация Project X отдельно описывает встроенный DNS-server и разные схемы запросов.

Это означает, что при использовании VLESS DNS необязательно должен полностью зависеть от системного resolver.

Но системный DNS всё равно может участвовать

Зависит от конфигурации.

Project X отдельно предупреждает:

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

То есть наличие DNS-раздела в Xray ещё не означает:

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

DNS и routing связаны

Это особенно важно при split tunneling.

Представим правила:

YouTube → Proxy
Discord → Proxy
.ru → Direct
Local → Direct

Чтобы выбрать маршрут по домену, Xray должен понимать:

к какому домену относится соединение.

Поэтому DNS, sniffing и routing часто работают вместе.

Если DNS-схема нарушена, правила маршрутизации тоже могут вести себя неожиданно.

Что делает DNS в HAPP

HAPP позволяет управлять DNS в рамках routing-профиля.

В документации HAPP отдельно присутствуют:

• Remote DNS;
• Domestic DNS;
• DoH;
• другие DNS-настройки;
• Fake DNS.

Это позволяет разделять разные категории запросов.

Например:

зарубежные домены
↓
Remote DNS

локальные домены
↓
Domestic DNS

И дальше применять соответствующий routing.

Что такое FakeDNS

FakeDNS часто выглядит пугающе по названию, хотя это технический механизм transparent proxy.

Вместо настоящего IP DNS временно возвращает адрес из специального виртуального диапазона.

Например:

example.com
↓
FakeDNS
↓
198.18.x.x

Xray запоминает:

198.18.x.x = example.com

Когда приложение подключается к этому виртуальному IP, Xray понимает исходное доменное имя и может применить правильное routing rule.

Project X именно так описывает принцип FakeDNS: компонент возвращает IP из собственного ipPool и сохраняет соответствие между этим IP и доменом.

Зачем FakeDNS нужен HAPP

HAPP описывает Fake DNS как способ подменить реальный IP виртуальным так, чтобы запросы гарантированно обрабатывались Xray в соответствии с его конфигурацией, а не перехватывались системным DNS.

Это особенно полезно для:

• TUN;
• доменной маршрутизации;
• split tunneling.

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

FakeDNS не является публичным DNS-сервером

Это важный момент.

Он не заменяет:

• Google DNS;
• Cloudflare;
• AdGuard DNS.

FakeDNS — внутренний механизм сопоставления:

домен ↔ виртуальный IP.

Реальное разрешение домена дальше всё равно происходит согласно конфигурации Xray.

FakeDNS должен действительно получать DNS-запросы

Сам факт наличия FakeDNS в конфиге ещё недостаточен.

Project X отдельно указывает:

чтобы FakeDNS работал, DNS-запросы необходимо направить на него.

То есть при сложной пользовательской DNS-схеме можно получить ситуацию:

Android Private DNS
↓
внешний resolver

а FakeDNS Xray вообще не участвует.

Нужно ли включать FakeDNS всегда

Нет.

Если текущая конфигурация:

• работает;
• правильно маршрутизирует домены;
• не имеет DNS leak-проблем;

не нужно включать FakeDNS только потому, что функция существует.

Это инструмент под определённую архитектуру.

Что такое AdGuard и почему здесь возникает путаница

Под словом AdGuard пользователь может иметь в виду сразу несколько вещей.

Например:

1. AdGuard DNS.
2. AdGuard для Android.
3. AdGuard VPN.
4. AdGuard DNS через Android Private DNS.

Это принципиально разные схемы.

AdGuard DNS как Private DNS

Если в Android просто указан DNS-провайдер AdGuard через Private DNS, отдельный VPN-интерфейс не создаётся.

Это DNS-схема.

Она вполне может работать вместе с HAPP.

Но при проблемах её можно временно отключить для контрольного теста.

AdGuard для Android — уже другое

Обычный AdGuard Ad Blocker на Android без root часто использует локальный VPN, чтобы фильтровать весь сетевой трафик.

AdGuard прямо пишет, что Local VPN mode — системный способ фильтрации на non-root Android.

И тут возникает уже настоящий конфликт.

Почему AdGuard Local VPN конфликтует с HAPP

Android обычно не позволяет двум приложениям одновременно владеть системным VPN-интерфейсом.

AdGuard официально предупреждает:

при Local VPN mode использовать другой VPN одновременно нельзя.

То есть схема:

AdGuard Local VPN
+
HAPP VPN

на обычном Android работать одновременно не должна.

Это уже не DNS-проблема.

Это конфликт двух VPN-приложений.

Как выглядит такой конфликт

Например:

1. AdGuard работает.
2. Пользователь включает HAPP.
3. AdGuard отключается.

Или наоборот:

1. HAPP подключён.
2. Запускается AdGuard.
3. VPN HAPP перестаёт работать.

С точки зрения Android всё логично:

системный VPN-интерфейс уже занят другим приложением.

А AdGuard VPN?

Это отдельное VPN-приложение.

AdGuard сделал специальный Integrated Mode, позволяющий AdGuard Ad Blocker + AdGuard VPN работать совместно.

В такой схеме AdGuard создаёт локальный VPN-интерфейс, а AdGuard VPN используется как outbound proxy.

Но это фирменная интеграция именно их продуктов.

Она не означает автоматическую совместимость:

AdGuard Local VPN + любой сторонний VPN.

Можно ли использовать AdGuard и HAPP одновременно

Зависит от режима AdGuard.

Если AdGuard использует Local VPN

На обычном non-root Android — обычно нет.

Если используется только AdGuard DNS

Да, это другая технология.

Если устройство rooted

AdGuard предлагает альтернативные proxy-режимы, не требующие собственного VPN-интерфейса.

Для большинства пользователей самый простой вариант:

HAPP как VPN + DNS-фильтрация без отдельного AdGuard Local VPN.

Почему после установки AdGuard HAPP перестал подключаться

Первое, что стоит проверить:

не работает ли AdGuard в Local VPN mode?

Если да, причина практически найдена.

Не нужно:

• менять VLESS UUID;
• менять сервер;
• обновлять public key.

Два приложения просто борются за один системный VPN-механизм Android.

Что делать в таком случае

Для контрольного теста:

1. полностью остановите AdGuard;
2. запустите HAPP;
3. подключите VLESS;
4. проверьте интернет.

Если всё заработало — VLESS исправен.

Дальше уже выбирайте подходящую схему DNS/фильтрации.

AdGuard DNS и AdGuard Ad Blocker — не одно и то же

Это стоит повторить.

AdGuard DNS:

DNS filtering

AdGuard for Android Local VPN:

весь трафик → local VPN → filtering

Первый обычно может сосуществовать с HAPP.

Второй конкурирует за VPN-интерфейс.

Что если используется NextDNS

Логика похожая.

Если NextDNS настроен как:

Android Private DNS

это просто DNS-механизм.

Если используется отдельное приложение, которое само создаёт VPN profile, уже может возникнуть конфликт с HAPP.

Нужно понимать не название сервиса, а:

каким способом он подключён к Android.

А что с DNS-фильтрацией в самом HAPP

Если нужна блокировка:

• рекламы;
• трекеров;

часть задач можно решить на уровне routing/DNS самого HAPP/Xray.

HAPP routing поддерживает отдельную категорию:

Block

наряду с:

• Direct;
• Proxy.

Поэтому необязательно добавлять второй системный VPN только ради части фильтрации.

Что означает Direct / Proxy / Block

Упрощённо:

Direct
→ идти напрямую

Proxy
→ идти через VLESS

Block
→ не разрешать соединение

HAPP позволяет использовать отдельные:

• directSites;
• proxySites;
• blockSites;

а также IP-правила.

DNS и routing в такой конфигурации тесно связаны.

Почему сайт может попасть в Block по ошибке

Если используются:

• рекламные списки;
• собственные правила;
• большие DNS blocklists,

иногда блокируется нужный домен.

Тогда пользователь видит:

один сайт через VLESS не работает.

Но сервер исправен.

Для теста отключите сложный block-list или попробуйте простой routing profile.

Почему приложение может зависеть от неожиданного домена

Современное приложение редко обращается только к:

example.com.

Оно может использовать:

• API;
• CDN;
• analytics;
• authentication;
• media-host;
• websocket endpoint.

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

HAPP подключён, Google открывается, а один сайт нет

Это не похоже на полный отказ DNS.

Проверьте:

• routing;
• block list;
• конкретный resolver;
• другой VLESS-сервер.

Если проблема только с одним доменом, менять всю VPN-конфигурацию не нужно.

HAPP подключён, вообще никакие домены не открываются

Вот здесь DNS становится сильным подозреваемым.

Особенно если:

• Connection status нормальный;
• сервер отвечает;
• проблема появилась после смены DNS.

Верните:

Private DNS → Automatic

и используйте стандартную DNS-конфигурацию HAPP.

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

Можно ли проверить DNS вручную

Да.

На компьютере:

nslookup example.com

или:

dig example.com

На Android это сложнее без дополнительных инструментов, поэтому чаще достаточно:

• сравнить Wi-Fi/LTE;
• отключить Private DNS;
• проверить другой resolver.

Почему Wi-Fi и LTE могут давать разный DNS

Провайдеры могут выдавать свои resolver.

Кроме того, Android Private DNS способен вести себя по-разному в зависимости от доступности выбранного сервера через конкретную сеть.

Поэтому:

Wi-Fi → всё работает

LTE → домены не открываются

может быть DNS-проблемой, а не проблемой VLESS.

Почему смена VLESS-сервера иногда исправляет DNS

Если DNS-трафик направляется через proxy, смена VLESS-сервера меняет маршрут до resolver.

Например:

Телефон
→ VLESS NL
→ DNS

и:

Телефон
→ VLESS FR
→ DNS

могут работать по-разному.

Поэтому даже DNS-проблема иногда выглядит как:

один VPN-сервер работает, другой нет.

DoH через VLESS или напрямую

Xray умеет использовать DoH разными способами.

В документации Project X присутствует, например, https+local, при котором DoH-запрос идёт напрямую через Freedom outbound и не проходит обычный routing Xray.

Это хороший пример того, почему недостаточно спросить:

какой DNS стоит?

Нужно ещё знать:

через какой маршрут этот DNS используется.

Почему это важно для геомаршрутизации

Представим:

сайт → VLESS через Францию
DNS → напрямую через локального ISP

Такой вариант может работать.

Но в сложной routing-схеме оператор иногда хочет:

зарубежный домен
→ Remote DNS через proxy

а:

локальный домен
→ Domestic DNS напрямую

Тогда смешивание дополнительных DoH/Private DNS поверх этой системы способно изменить ожидаемое поведение.

DNS leak — всегда ли это катастрофа

Нет.

Под DNS leak обычно понимают ситуацию, когда DNS-запросы идут не туда, куда предполагалась архитектура VPN.

Например:

трафик → VPN
DNS → ISP

С точки зрения приватности это может быть нежелательно.

Но само по себе такое состояние ещё не означает:

сайты обязательно перестанут работать.

Это отдельный вопрос.

Главное — DNS должен быть доступным и согласованным с вашей routing-схемой.

Почему не стоит одновременно включать всё

Плохая диагностическая конфигурация:

• Android Private DNS;
• AdGuard DNS;
• browser DoH;
• HAPP Remote DNS;
• FakeDNS;
• дополнительный DNS-filter.

Если что-то перестаёт открываться, понять источник проблемы становится очень трудно.

Лучше сначала получить простую рабочую схему.

Например:

Android Automatic DNS
+
HAPP
+
стандартный routing

А затем добавлять дополнительные функции по одной.

Как диагностировать DNS-проблему правильно

Самое главное правило:

меняйте один параметр за раз.

Например:

Шаг 1

Private DNS → Automatic.

Проверили.

Шаг 2

Отключили browser Secure DNS.

Проверили.

Шаг 3

Упростили routing HAPP.

Проверили.

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

Не меняйте VLESS-параметры из-за DNS

Если HAPP показывает стабильное подключение и проблема появилась после изменения DNS, не нужно трогать:

• UUID;
• SNI;
• fingerprint;
• public key;
• short ID;
• flow.

Эти параметры относятся к соединению с VLESS-сервером.

DNS находится на другом уровне.

Как отличить VLESS timeout от DNS-проблемы

VLESS timeout

Сам сервер не подключается.

HAPP долго пытается установить соединение.

DNS-проблема

HAPP быстро подключился.

Но:

• домены не открываются;
• отдельные приложения зависают;
• сайты ждут resolution.

Это два разных этапа.

IP открывается, домен нет — что это означает

Это классический диагностический признак DNS.

Если известный IP доступен, но соответствующее доменное имя не разрешается, сам IP-маршрут существует.

Проблема находится именно в name resolution.

Но использовать случайные IP сайтов для постоянной диагностики не всегда удобно из-за:

• HTTPS;
• CDN;
• virtual hosts.

Это лишь технический тест.

Почему браузер иногда сам исправляет DNS-проблему

Современный браузер может:

• использовать DoH;
• кэшировать DNS;
• повторять resolution;
• выбирать IPv4/IPv6.

Поэтому он способен выглядеть рабочим даже при проблемном системном DNS.

Другие приложения этих возможностей могут не иметь.

DNS cache тоже может путать

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

Получается:

старые сайты работают

а:

новые не открываются.

Это очень характерно для DNS-сбоев.

Нужно ли очищать DNS cache

Иногда полезно.

Но сначала исправьте сам источник проблемы.

Если resolver недоступен, очистка cache только удалит последние рабочие записи и может сделать ситуацию хуже.

На Windows после исправления DNS можно использовать:

ipconfig /flushdns

На Android обычно проще переподключить сеть или VPN.

Что делать на Android: короткая инструкция

Если HAPP Connected, но сайты не открываются:

1. Проверить обычный интернет без VPN.
2. Поставить Private DNS в Automatic.
3. Отключить отдельный AdGuard Local VPN.
4. Переподключить HAPP.
5. Попробовать другой VLESS-сервер.
6. Проверить другую сеть.
7. Вернуть дополнительные DNS-настройки по одной.

В большинстве бытовых случаев этого уже достаточно.

Что делать на Windows

Если похожая проблема возникает на ПК:

1. Проверить системный DNS.
2. Проверить браузерный Secure DNS.
3. Проверить AdGuard/антивирус.
4. Проверить HAPP TUN.
5. Попробовать другой routing profile.
6. Сменить сервер.

На Windows особенно важно помнить, что браузерный DoH и системный DNS могут работать независимо.

AdGuard на Windows тоже может вмешиваться

Desktop AdGuard способен использовать собственную фильтрацию:

• DNS;
• HTTPS;
• приложения.

Если проблема исчезает после временного отключения AdGuard, дальше нужно выяснять именно его конкретный сетевой компонент.

Не стоит сразу считать виноватым весь VLESS.

Нужно ли использовать DNS 8.8.8.8 или 1.1.1.1

Не существует универсального правила:

поставьте 8.8.8.8 — всё заработает.

Публичный resolver может быть отличным.

Но конкретная VLESS/routing-схема может предполагать другой DNS.

Поэтому лучше использовать настройки, которые рекомендует сам сервис или клиент.

Случайная замена DNS иногда исправляет симптом, но ломает routing.

А AdGuard DNS?

То же самое.

Он может прекрасно работать с VLESS.

Особенно если нужен DNS-level blocking.

Но если после его включения:

• перестали открываться нужные домены;
• routing ведёт себя странно;

проверьте сначала без него.

Это не означает, что AdGuard DNS плохой.

Просто фильтрация DNS всегда способна изменить набор доступных доменов.

Может ли DNS блокировать рекламу

Да.

AdGuard DNS и другие filtering DNS способны возвращать специальные результаты для доменов:

• рекламы;
• трекеров;
• вредоносных ресурсов.

AdGuard для Android также позволяет выбирать DNS-server и применять DNS-фильтры.

Но чем агрессивнее filter list, тем выше риск false positive.

Что такое false positive DNS-блокировки

Например, приложение использует:

api.example.net

Фильтр ошибочно считает этот домен трекером.

В результате:

главный сайт → работает
API → blocked
приложение → сломалось

Пользователь обвиняет VPN.

Но VLESS вообще исправен.

Как проверить блокировку

Временно:

• отключите DNS-filter;
• либо добавьте домен в исключение.

Если приложение заработало, причина найдена.

Не нужно менять сервер.

VPN работает без AdGuard, но нужен и блокировщик

Тогда можно выбрать более простую совместимую схему.

Например:

HAPP как единственный Android VPN

плюс:

DNS-level filtering

без второго Local VPN.

Так меньше сетевых слоёв конфликтуют между собой.

Нужно ли включать FakeDNS вместе с Private DNS

Не существует универсального ответа.

Если провайдер VLESS уже подготовил рабочий HAPP routing с FakeDNS, лучше не накладывать поверх него вручную сложную DNS-схему без необходимости.

Если текущая конфигурация работает:

ничего оптимизировать не нужно.

Когда FakeDNS действительно полезен

Прежде всего когда нужна надёжная доменная маршрутизация внутри transparent/TUN-сценария.

Например:

YouTube
→ FakeDNS
→ Xray понимает домен
→ Proxy

при этом:

локальный ресурс
→ Direct

Это более сложная задача, чем просто:

открыть сайт через VPN.

Почему FakeDNS иногда ломает локальную сеть

Если virtual IP и routing настроены неудачно, локальные сервисы могут разрешаться или маршрутизироваться не так, как ожидалось.

Поэтому локальные:

• NAS;
• принтеры;
• .local;
• внутренние DNS-зоны

стоит тестировать отдельно.

Для домашнего пользователя готовый routing profile обычно безопаснее ручной настройки FakeDNS.

Что если проблема только у банковского приложения

Не стоит автоматически считать это DNS.

Банковское приложение может:

• проверять VPN;
• использовать certificate pinning;
• обращаться к отдельным API;
• зависеть от local route.

Сначала проверьте:

работает ли оно при Direct.

Если сервис должен идти напрямую, добавьте соответствующее routing rule согласно конфигурации вашего VPN-сервиса.

Что если проблема только у одного сайта

Проверьте:

1. без VPN;
2. через другой VLESS-сервер;
3. без DNS-фильтра;
4. другой resolver.

Если проблема исчезает только после отключения DNS-filter, причина ясна.

Если только после смены сервера — вероятнее маршрут или server IP.

Быстрая таблица диагностики

Самая быстрая последовательность действий

Если подозреваете конфликт VLESS и Private DNS, проверяйте так:

1. Убедиться, что сам HAPP подключается.
2. Private DNS → Automatic.
3. Отключить отдельные VPN-based фильтраторы.
4. Переподключить HAPP.
5. Проверить другой сервер.
6. Проверить Wi-Fi и LTE.
7. Упростить routing/DNS HAPP.
8. Вернуть дополнительные DNS-функции по одной.

Не изменяйте десять настроек одновременно.

Что написать поддержке

Не:

с DNS какая-то фигня.

Лучше:

Android, HAPP. VLESS подключается за секунду. При Private DNS dns.example сайты не открываются. Если поставить Android Private DNS в Automatic, всё работает. На Wi-Fi и LTE одинаково.

Это уже практически готовый диагноз.

Другой пример:

HAPP не может запустить VPN, пока работает AdGuard для Android. После полной остановки AdGuard HAPP подключается нормально.

Здесь уже понятно, что проблема связана с двумя системными VPN.

Что НЕ нужно делать

При DNS-проблеме не стоит сразу:

• менять UUID;
• менять public key;
• редактировать SNI;
• менять fingerprint;
• создавать новый VLESS;
• переустанавливать Android.

Если HAPP уже подключился, VLESS handshake прошёл.

Ищите проблему там, где она появилась:

DNS и routing.

Если нужен готовый VLESS без ручной DNS-настройки

На VLESS.ART используется готовая подписка для HAPP и совместимых клиентов.

Пользователю не требуется вручную собирать Xray JSON или настраивать отдельные DNS-outbound.

Подписка содержит готовые серверные параметры, а routing может использоваться для разделения proxy/direct-трафика.

Посмотреть тарифы:
https://vless.art/#tarif

Если после подключения возникла проблема именно с:

• Private DNS;
• AdGuard;
• отдельным приложением;

лучше сначала проверить стандартную конфигурацию без дополнительных DNS-фильтров.

Простая рабочая схема для Android

Для большинства пользователей хорошей отправной точкой является:

Android
↓
Private DNS Automatic
↓
HAPP
↓
VLESS
↓
готовый routing

Если всё работает, дальше уже можно экспериментировать с:

• filtering DNS;
• собственным DoH;
• дополнительными блок-листами.

Не наоборот.

Почему простая схема лучше для диагностики

Каждый дополнительный компонент добавляет новую точку отказа.

Например:

Android
↓
Private DNS
↓
AdGuard
↓
DoH
↓
HAPP
↓
FakeDNS
↓
VLESS

Если сайт не открылся, непонятно, кто виноват.

Чем проще исходная конфигурация, тем легче найти проблему.

Итог

VLESS и Private DNS обычно могут работать вместе.

Android Private DNS — это отдельный механизм защищённого разрешения доменных имён. Google прямо уточняет, что Private DNS защищает только DNS-запросы и ответы и не является полноценным VPN.

Но при сложной конфигурации пользователь может одновременно задействовать:

• системный Private DNS;
• browser DoH;
• DNS HAPP;
• Xray FakeDNS;
• DNS-фильтрацию.

И тогда становится сложнее понять, какой resolver реально обслуживает запрос.

Особенно важно отличать AdGuard DNS от AdGuard for Android.

AdGuard DNS может работать как обычный DNS-механизм.

А AdGuard for Android в режиме Local VPN создаёт собственный системный VPN. AdGuard прямо предупреждает, что в этом режиме другой VPN одновременно использовать нельзя.

Xray, в свою очередь, имеет собственный DNS-модуль и FakeDNS. FakeDNS возвращает виртуальные IP и сохраняет соответствие между ними и доменами, что позволяет Xray корректно применять доменные routing rules. Но DNS-запросы должны действительно быть направлены в FakeDNS — одного включения функции недостаточно.

Поэтому если:

HAPP Connected, но сайты не открываются,

первым делом проверяйте не VLESS-ключ, а:

Private DNS → сторонние DNS-фильтры → routing → FakeDNS.

Самый полезный контрольный вариант на Android:

Private DNS Automatic + один активный VPN + стандартный routing HAPP.

Если такая схема работает, дополнительные:

• AdGuard DNS;
• DoH;
• blocklists;
• FakeDNS-настройки

можно возвращать по одной.

Так намного быстрее находится конкретный конфликт, чем после бесконечной смены VLESS-серверов и параметров ключа.