DNS и маршрутизация в VPN-клиентах часто ломаются не по отдельности, а вместе. DNS отвечает за превращение домена в IP-адрес, а routing решает, каким путем пойдет соединение: напрямую, через proxy, через конкретную группу узлов, в блокировку или в локальную сеть. Поэтому зеленый статус подключения еще не доказывает, что нужный домен пошел правильным маршрутом.
Типичная ситуация выглядит так: клиент пишет Connected, тест IP показывает другую страну, но отдельный сайт не открывается, приложение видит старую геолокацию или тест DNS leak показывает resolver провайдера. В такой момент не стоит сразу переустанавливать приложение. Сначала нужно понять, где именно расходятся три слоя: запрос имени, выбранный IP и правило маршрута.
#Что делает DNS в VPN/proxy-клиенте
Когда вы открываете example.com, приложению нужен IP-адрес сервера. Для этого используется DNS resolver: системный, встроенный в клиент, публичный, корпоративный, DoH/DoT или resolver на стороне proxy/VPN. Cloudflare в базовом объяснении DNS разделяет recursive resolver, который принимает запрос пользователя и ищет запись, и authoritative nameserver, который хранит записи конкретного домена. Для пользователя VPN важнее первый участник: именно resolver видит, какие имена вы запрашиваете.
В обычной сети DNS-запрос часто уходит к провайдеру, роутеру или публичному resolver. В VPN/proxy-схеме возможны разные варианты:
- DNS идет через VPN/proxy. Resolver видит адрес VPN/proxy-выхода или запрос приходит из туннеля.
- DNS идет напрямую. Сайт может открываться через proxy, но имена запрашиваются у локального провайдера.
- DNS обрабатывает сам клиент. Xray, sing-box и Clash-подобные ядра могут использовать встроенный DNS для правил, FakeIP, блокировок или выбора outbound.
- DNS перехватывается системой или браузером. Браузерный DoH, корпоративный профиль, Private DNS на Android или старый VPN-профиль могут обойти ожидания клиента.
#Что делает маршрутизация
Маршрутизация отвечает на другой вопрос: куда отправить уже понятный поток трафика. В современных клиентах правило может смотреть на домен, IP-диапазон, порт, протокол, процесс, Android package name, network type, Wi-Fi SSID, rule set или результат sniffing. Затем правило выбирает outbound: proxy, direct, block, dns, конкретную группу или балансировщик.
Важно не путать routing в клиенте и системную таблицу маршрутов. В режиме system proxy приложение может отправлять HTTP/SOCKS-трафик в локальный порт клиента, но программы, которые игнорируют системный proxy, пойдут напрямую. В TUN-режиме клиент создает виртуальный сетевой интерфейс и может перехватывать больше IP-трафика, но тогда появляются риски routing loop, конфликтов с firewall, IPv6 и локальной сетью.
От теории к подключению
От понимания к подключению
Если вы уже разобрались, зачем нужен VPN, можно получить данные для подключения и настроить доступ по инструкции.
#Мини-модель: от домена до outbound
| Шаг | Что происходит | Где бывает ошибка |
|---|---|---|
| 1. Приложение просит домен | Браузер или приложение обращается к site.example. | Приложение использует собственный DoH, кэш или встроенный resolver. |
| 2. DNS получает IP | Системный DNS или DNS ядра возвращает A/AAAA/FakeIP. | Запрос ушел к провайдеру, пришел IPv6 без маршрута, сработал не тот DNS rule. |
| 3. Routing ищет правило | Клиент сопоставляет домен/IP/процесс/rule set. | Более раннее правило отправило домен в direct или block. |
| 4. Outbound устанавливает соединение | Трафик идет через proxy, direct, block или другой outbound. | Outbound недоступен, выбран не тот узел, возник routing loop. |
| 5. Сайт проверяет контекст | Сервис видит IP, DNS-географию, cookies, аккаунт, язык, время, WebRTC и другие сигналы. | Пользователь принимает это за DNS-проблему, хотя причина в аккаунте или антифроде. |
#Режимы клиента и DNS-риски
| Режим | Что обычно перехватывает | Где чаще ломается DNS/routing |
|---|---|---|
| System Proxy | Приложения, которые уважают системный HTTP/SOCKS proxy. | DNS может оставаться системным; отдельные приложения игнорируют proxy; браузерный DoH живет отдельно. |
| TUN | IP-трафик через виртуальный интерфейс, включая приложения без proxy-настроек. | Нужны корректные routes, DNS hijack, исключения для локальной сети и защита от loop. |
| Global | Почти все, что видит клиент, отправляется в один outbound. | Проще диагностировать, но может ломать банки, локальные сервисы, captive portal и CDN-географию. |
| Rule / split routing | Трафик делится по доменам, IP, приложениям или rule sets. | Самый частый источник симптома 'часть сайтов работает, часть нет'. |
| FakeIP | DNS возвращает специальный искусственный IP, а клиент сопоставляет его с доменом. | Проблемы появляются, если приложение, система или другой DNS-кэш теряет связь FakeIP с исходным доменом. |
#Как это устроено в Xray
В Xray routing module отправляет входящий трафик в разные outbounds по правилам. Важная настройка — domainStrategy. При AsIs ядро использует домен как есть, если он доступен. При IPIfNonMatch Xray сначала пытается сопоставить domain rules, а если совпадений нет, резолвит домен и повторно проверяет IP rules. При IPOnDemand резолвинг выполняется при встрече IP-правила.
Встроенный DNS Xray используется не только для 'поставить DNS-сервер'. Он участвует в routing phase, может помогать freedom outbound при разрешении target address и может использоваться для перехвата/forward DNS-запросов через DNS outbound. Отсюда частая ошибка: пользователь меняет DNS-сервер, но не смотрит domainStrategy, порядок rules и то, какие домены уже сопоставлены до IP-этапа.
#Как это устроено в sing-box
В sing-box DNS и route описаны отдельными блоками, но они тесно связаны. DNS имеет servers, rules, final, strategy, cache, FakeIP и reverse mapping. Route имеет rules, rule sets, final, auto_detect_interface и другие поля. В TUN-сценариях особенно важны настройки, которые не дают outbound-соединениям снова попасть в тот же туннель.
Route rules в sing-box могут учитывать домен, IP CIDR, source IP, process name/path, Android package name, network type, Wi-Fi SSID, rule set и логические комбинации. Это мощно, но создает риск ложной диагностики: кажется, что 'DNS не работает', хотя правило по package name отправило приложение напрямую, а браузер в это время идет через proxy.
FakeIP и reverse mapping полезны для доменного routing в TUN, но требуют аккуратности. Если приложение получило FakeIP, а дальнейший поток не проходит через тот же клиент, соединение может выглядеть как таймаут или странный IP. На macOS и других системах с сильным DNS-кэшированием reverse mapping тоже может вести себя не так предсказуемо, как в лабораторном примере.
#DNS leak: что это и что это не значит
DNS leak — это ситуация, где DNS-запросы уходят к resolver, которого вы не ожидали. Например, весь веб-трафик идет через proxy, но DNS-запросы видит локальный провайдер. Это неприятно для приватности и может ломать доступ, потому что разные resolver возвращают разные IP для CDN, региональных доменов и заблокированных ресурсов.
Но тест DNS leak нужно читать осторожно:
- Если тест показывает resolver в стране VPN-выхода, это обычно ожидаемо, но не доказывает полную приватность.
- Если тест показывает Cloudflare, Google или Quad9, это не всегда утечка: возможно, клиент специально использует публичный resolver через туннель.
- Если тест показывает вашего провайдера, проверьте, не работает ли браузерный DoH, Private DNS, system proxy вместо TUN или исключение приложения.
- Если IP-тест и DNS-тест показывают разные страны, причина может быть в CDN, EDNS Client Subnet, кэше, split routing или разных путях IPv4/IPv6.
#Типовые симптомы и вероятные причины
| Симптом | Вероятная причина | Что проверить |
|---|---|---|
| VPN подключен, но сайт не открывается | DNS не резолвит домен, правило отправило сайт в block/direct, outbound недоступен. | Лог DNS, rule match, выбранный outbound, доступность сервера. |
| Открывается браузер, но не приложение | System proxy покрывает браузер, приложение идет напрямую или имеет свой DNS. | TUN/per-app настройки, package/process rules, DNS внутри приложения. |
| DNS leak показывает провайдера | DNS идет мимо клиента или IPv6 идет другим путем. | Private DNS/DoH, IPv6 routes, TUN DNS hijack, системный resolver. |
| Работает на Wi-Fi, ломается на LTE | Другой MTU, IPv6, metered network, captive policy, UDP-фильтрация. | Network type rules, IPv6 strategy, UDP/DoH/DoT, MTU. |
| Локальная сеть пропала после TUN | Все private IP ушли в tunnel или заблокированы. | Исключения RFC1918, route_exclude, allow LAN, firewall. |
| Сайт видит старую страну | Не DNS, а cookies, аккаунт, GPS, SIM, WebRTC, язык, платежный регион или CDN-кэш. | Сравнить IP, DNS, clean profile, другой браузер, WebRTC. |
| После включения FakeIP все таймаутится | FakeIP не доходит до того же ядра или конфликтует с кэшем/другим клиентом. | Отключить FakeIP для теста, очистить DNS-кэш, проверить TUN capture. |
#Как диагностировать без хаоса
- Зафиксируйте простой сценарий. Выберите один сайт и одно приложение. Не проверяйте одновременно браузер, мессенджер, игру и speedtest.
- Проверьте интернет без VPN. Если домен не открывается без клиента, проблема может быть не в routing.
- Включите самый простой режим. Для диагностики временно используйте Global или один понятный outbound. Если так работает, проблема почти наверняка в rules/split routing.
- Сравните IP и DNS. Откройте IP-test и DNS leak test. Смотрите не только страну, но и resolver, IPv4/IPv6 и повторяемость результата.
- Посмотрите логи клиента. Ищите строки DNS query, rule matched, outbound tag, direct/proxy/block, timeout, refused, no route.
- Проверьте домен и IP отдельно. Если домен не резолвится, это DNS-слой. Если IP есть, но соединение висит, смотрите route/outbound/firewall.
- Отключите браузерный DoH для теста. Chrome, Edge, Firefox и некоторые браузеры могут использовать собственный encrypted DNS, обходя системную картину.
- Проверьте IPv6. Часто IPv4 идет через proxy, а IPv6 остается прямым или наоборот блокируется без понятного сообщения.
- Верните правила по одному. Добавляйте rule sets, FakeIP, per-app исключения и DNS strategy постепенно, проверяя один симптом после каждого изменения.
#Платформенные нюансы
#Android
Android-клиенты используют VpnService. В его API есть DNS-серверы, маршруты, allowed/disallowed applications и возможность разрешить обход VPN. Документация Android прямо показывает, что добавление DNS-сервера и route влияет на адресные семейства IPv4/IPv6, а per-app списки определяют, какие приложения получают доступ к VPN. Поэтому на Android симптом 'браузер работает, приложение нет' часто связан не с сервером, а с package rules, battery restrictions, Private DNS или split tunneling внутри клиента.
- Проверьте Android Private DNS: он может конфликтовать с DNS клиента.
- Сравните Wi-Fi и cellular: в sing-box есть network type rules, а мобильная сеть может иначе обрабатывать IPv6/UDP.
- Если клиент поддерживает per-app mode, убедитесь, что нужное приложение не исключено.
- Не держите одновременно два VPN-клиента: Android обычно допускает один активный VPN-профиль для пользователя.
#iOS и iPadOS
На Apple-платформах VPN-клиенты обычно работают через Network Extension и системные VPN-профили. Apple поддерживает routing settings для VPN и per-app VPN, а MDM-профили могут задавать DNS и on-demand поведение. Пользователь видит мало низкоуровневых деталей, поэтому диагностика часто сводится к проверке профиля, разрешений, режима on-demand, per-app списка и того, не перехватывает ли DNS другой профиль.
- Если VPN значок есть, но конкретное приложение идет напрямую, проверьте per-app/on-demand правила.
- Если после установки DNS-профиля изменилось поведение всех сетей, временно отключите профиль для теста.
- На iOS сложнее увидеть полный лог ядра, поэтому сравнивайте один и тот же домен в Safari и проблемном приложении.
#Windows
На Windows могут одновременно влиять system proxy, TUN/Wintun-драйвер, firewall, DNS Client service, NRPT и старые корпоративные VPN-профили. Microsoft описывает NRPT как таблицу пространств имен, которая определяет поведение DNS-клиента для запросов. Поэтому в split VPN сценариях домен может уходить не туда даже при рабочем proxy.
- Проверьте, включен ли только system proxy или еще и TUN.
- Посмотрите старые VPN, корпоративные профили, security software и NRPT-политики.
- Для приложений Microsoft Store и игр system proxy может быть недостаточен: нужен TUN или явная настройка.
- После смены DNS очищайте кэш только как диагностический шаг, а не как постоянное решение.
#macOS
macOS активно использует Network Extension, системные DNS-сервисы и кэширование. Отдельные приложения могут вести себя иначе, чем браузер. В TUN/Packet Tunnel сценариях важно, какие маршруты установлены, разрешена ли локальная сеть и не конфликтует ли другой network extension.
- Проверьте системные VPN/DNS профили и разрешения Network Extension.
- Сравните Safari/Chrome/проблемное приложение: браузерный DoH может менять картину.
- Если ломается локальная сеть, ищите private IP исключения и route rules.
#Linux
На Linux поведение зависит от дистрибутива, NetworkManager, systemd-resolved, resolvconf, nftables/iptables, policy routing и прав на TUN. Один клиент может изменить DNS через NetworkManager, другой — поднять локальный DNS listener, третий — ожидать ручной настройки route table.
- Проверьте, какой resolver реально используется: systemd-resolved, NetworkManager, dnsmasq или локальный порт клиента.
- Смотрите таблицы маршрутов и policy rules, если TUN включен, но трафик уходит мимо.
- Не смешивайте несколько менеджеров DNS без понимания приоритета.
- Для приложений в контейнерах, Flatpak или браузерных sandbox проверьте отдельные DNS/proxy настройки.
#Безопасный чеклист настройки
- Начните с рабочего профиля без тонкой маршрутизации. Сначала connection, потом DNS, потом split rules.
- Определите желаемую модель. Все через proxy, только выбранные домены, только приложения или исключение локальной сети — это разные конфигурации.
- Согласуйте DNS и route. Доменное правило должно видеть домен; IP-правило должно получать подходящий A/AAAA; FakeIP должен обрабатываться тем же клиентом.
- Учитывайте IPv6. Либо корректно маршрутизируйте IPv6, либо осознанно ограничивайте его в клиенте/системе.
- Проверяйте rule order. Более раннее или более точное правило может переопределить общий режим.
- Не доверяйте одному тесту. Сравните IP, DNS, логи клиента, проблемный сайт и другое приложение.
- Оставьте локальную сеть отдельным решением. Принтеры, NAS, роутер и умный дом часто требуют direct routes.
- Документируйте изменения. Запишите, какой DNS server, strategy, rule set и mode вы изменили, чтобы можно было откатиться.
#Частые ошибки
- Считать, что публичный DNS автоматически устраняет утечки. Если запрос идет к публичному resolver напрямую, локальный провайдер все еще видит соединение к этому resolver, а route может быть прямым.
- Включить TUN и забыть о локальной сети. Полный маршрут
0.0.0.0/0без исключений может сломать доступ к роутеру, принтеру или NAS. - Смешать DoH в браузере и DNS клиента. В логах клиента чисто, но браузер спрашивает другой resolver.
- Использовать устаревшие geosite/geoip наборы без обновления. Правила могут не знать новые домены или CDN-адреса.
- Принимать антифрод за DNS-проблему. Сайт может учитывать аккаунт, cookies, GPS, SIM-карту, платежный регион и историю входов.
- Добавлять правила без наблюдаемости. Если клиент умеет показывать connections/rule match, используйте это перед правкой конфигурации.
#Короткий вывод
DNS отвечает за имя, routing — за путь, а VPN/proxy-клиент должен связать их без противоречий. Если часть сайтов не открывается, DNS leak test показывает неожиданный resolver или split routing работает непредсказуемо, не начинайте с переустановки. Сначала проверьте resolver, IP, rule match, outbound, IPv6 и режим захвата трафика. Почти всегда проблема становится понятной, когда вы видите всю цепочку от домена до выбранного маршрута.