DNS over HTTPS (DoH) и доступ к ИИ: как они взаимодействуют

MAATRIX

Вы подняли VPN на своём сервере, проверили внешний IP — всё чисто, страна правильная, а ChatGPT или Claude всё равно пишут, что сервис недоступен в вашем регионе. Первая мысль — туннель работает не полностью. Но есть менее очевидная причина, которая живёт не в настройках VPN, а в самом браузере: DNS over HTTPS. Разберём, что это за механизм, почему он умеет резолвить домены в обход исправного туннеля, и как вернуть DNS-запросы под контроль.

Что такое DoH и чем он отличается от обычного DNS

Обычный DNS-запрос — это открытка без конверта: приложение спрашивает «какой IP у openai.com», ОС отправляет этот вопрос на DNS-сервер (указанный в настройках сети или полученный по DHCP) обычным текстом по UDP на порт 53, и любой узел на пути — провайдер, транзитная сеть, VPN-шлюз — теоретически видит содержимое запроса.

DNS over HTTPS оборачивает тот же запрос в HTTPS-соединение к конкретному веб-серверу-резолверу. Вместо UDP:53 на DNS-сервер провайдера уходит зашифрованный HTTPS-запрос на URL вида https://dns.resolver.example/dns-query — с точки зрения сети это выглядит как обычный HTTPS-трафик к сайту, а не как DNS. Провайдер и любой узел на пути больше не видят, какие домены вы резолвите, и не могут подменить ответ.

Технически DoH описан в RFC 8484 и сейчас включён по умолчанию или доступен одним переключателем в большинстве массовых браузеров. Ключевая деталь для нашей темы: DoH — это функция браузера, а не операционной системы. ОС по-прежнему может использовать классический системный DNS, а браузер параллельно — свой собственный, зашитый резолвер поверх HTTPS. Это два независимых DNS-стека на одной машине, и они не обязаны совпадать.

Почему DoH браузера обходит VPN, даже когда туннель настроен правильно

Здесь и кроется конфликт. Когда вы поднимаете VPN — WireGuard, OpenVPN, любой другой, — правильная настройка обычно включает push DNS-сервера внутри туннеля: клиент получает не только маршруты, но и адрес DNS, который нужно использовать, пока туннель активен. ОС слушается этой настройки и меняет системный резолвер.

Firefox в ряде сборок и профилей по умолчанию включает DoH и резолвит через собственного зашитого провайдера — исторически это Cloudflare (1.1.1.1) или NextDNS в рамках партнёрской программы «Trusted Recursive Resolver». Это соединение браузер устанавливает напрямую по имени резолвера, независимо от того, какой DNS назначил VPN-клиент операционной системе. Итог: ОС считает, что DNS настроен на сервер внутри туннеля, а Firefox в это время резолвит домены openai.com или claude.ai через Cloudflare напрямую.

Важный нюанс: сам факт, что DoH идёт по HTTPS, не значит, что он физически обходит туннель как канал — при full tunnel TCP-соединение к резолверу тоже пойдёт через VPN как транспорт. Проблема не в маршруте пакетов, а в том, *какой резолвер* выбирает домен: браузер стучится к стороннему DoH-провайдеру, а не к DNS-серверу, назначенному для туннеля. Сервис на другом конце видит резолвинг не от «ожидаемого» пула дата-центра, а от адресов публичного DoH-провайдера — отдельный сигнал для антифрод-логики, не связанный с IP пакета. При split tunneling риск выше: DoH-соединение может вовсе не попасть в туннель, если маршрутизация построена по портам или процессам, а не по всему трафику браузера.

Это отдельная и самостоятельная причина DNS leak — она не связана с классической утечкой, где ОС стучится к DNS провайдера через UDP:53 в обход туннеля. Общую диагностику классической утечки мы разбирали в статье как проверить IP и страну после туннеля; здесь речь о механизме на уровне конкретного приложения, который стандартные системные проверки DNS не всегда ловят.

Какие браузеры и в каких режимах используют DoH по умолчанию

Поведение по умолчанию у разных браузеров отличается, и оно меняется от версии к версии — если приведённые ниже детали для вашей версии браузера не совпадут, ориентируйтесь на сам принцип и проверяйте актуальные настройки в своей сборке.

Разница в логике важна: Chrome по умолчанию старается не заводить нового резолвера, а «зашифровать» уже используемый — если DNS внутри туннеля не поддерживает DoH, Chrome, скорее всего, откатится на обычный DNS через тот же сервер. Firefox же настойчивее предлагает собственный TRR-резолвер независимо от того, что настроено в системе — поэтому основная масса жалоб на «DoH ломает VPN» приходится именно на него.

Как проверить, какой резолвер реально использует браузер

Первый и самый прямой способ — встроенная диагностика Firefox. Откройте about:networking#dns — там список доменов и то, каким способом (HTTP DNS / TRR / native) они были разрешены. Если в колонке способа стоит TRR — запрос ушёл через DoH-резолвер браузера, а не через системный DNS.

Второй способ — сетевой. Откройте DevTools → вкладку Network, включите фильтр по домену вашего DoH-резолвера (cloudflare-dns.com, dns.nextdns.io и подобные) и посмотрите, идут ли к нему регулярные HTTPS-запросы, пока вы просто открываете сайты. Если да — DoH активен и работает параллельно с системным DNS.

Третий, независимый от браузера способ — посмотреть, что видит VPN-сервер:

# на сервере, где поднят VPN-туннель
sudo tcpdump -i any -n 'udp port 53 or (tcp port 443 and host 1.1.1.1)'

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

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

• Firefox: about:preferences#privacy → раздел «DNS через HTTPS» (или Settings → Privacy & Security → DNS over HTTPS в англоязычной сборке).
• Chrome: chrome://settings/security → «Использовать безопасный DNS» (Use secure DNS).
• Edge: edge://settings/privacy → раздел, отвечающий за безопасный DNS.

Как отключить встроенный DoH браузера

Самый надёжный вариант, если вы хотите, чтобы весь DNS шёл через настройки ОС и туннеля, — выключить DoH в браузере полностью.

В Firefox:

1. Перейдите в about:preferences#privacy.
2. Прокрутите до раздела «DNS через HTTPS».
3. Выберите «Выключено» (Off) вместо «Стандартная защита» или «Максимальная защита».

Через about:config то же самое делается флагом:

network.trr.mode = 5

Значение 5 — принудительно отключает TRR (DoH) независимо от других настроек; 0 — «по усмотрению браузера», что на практике часто означает «включено, если резолвер это поддерживает».

В Chrome и Chromium-браузерах: chrome://settings/security → снимите переключатель «Использовать безопасный DNS» полностью, либо выберите «С провайдером текущей сети» вместо стороннего сервиса из списка.

Для корпоративных и мультипользовательских машин то же самое можно закрепить групповой политикой, не полагаясь на ручную настройку каждого пользователя:

# Chrome/Chromium: /etc/opt/chrome/policies/managed/doh.json
{ "DnsOverHttpsMode": "off" }

# Firefox: policies.json, например /usr/lib/firefox/distribution/policies.json
{ "policies": { "DNSOverHTTPS": { "Enabled": false, "Locked": true } } }

Параметр Locked: true не даёт пользователю снова включить DoH из интерфейса.

Альтернатива: не выключать DoH, а направить его через свой DNS

Полностью отключать DoH — не единственный путь, и не всегда лучший: вы теряете шифрование DNS-запросов там, где оно реально защищает от подмены и слежки со стороны провайдера. Более аккуратный вариант — оставить DoH включённым, но указать браузеру свой собственный DoH-эндпоинт, поднятый на сервере с VPN, вместо публичного резолвера вендора.

Технически это разворачивание DoH-совместимого резолвера на сервере — например, dnsdist или Unbound с DoH-модулем, отдающий ответы по /dns-query. После этого в браузере вместо https://cloudflare-dns.com/dns-query прописывается адрес вашего резолвера:

• Firefox: about:config → network.trr.uri → указать https://ваш-домен/dns-query, и network.trr.mode = 3 (только указанный TRR, без отката) или = 2 (с откатом на системный DNS при недоступности).
• Chrome: chrome://settings/security → в разделе безопасного DNS выберите «С другим провайдером» и вставьте URL своего резолвера.

Плюс такого подхода — DNS-запросы браузера физически идут туда же, куда и остальной трафик через туннель, и совпадают по логике с системным DNS. Минус — придётся администрировать ещё один сервис: если резолвер на вашем сервере ляжет, а network.trr.mode выставлен в строгий режим без отката, браузер может вовсе перестать резолвить домены.

Как это связано именно с доступом к ИИ-сервисам

Для чат-ботов и API вроде ChatGPT, Claude или Gemini история с DoH особенно чувствительна. Эти сервисы применяют гео-ограничения по IP и параллельно могут анализировать дополнительные сигналы — включая происхождение DNS-резолвинга, если оно заметно отличается от ожидаемого для региона выхода в интернет. Резолвинг через публичный DoH-провайдер, который физически может отвечать из совсем другой точки мира, чем ваш VPN-сервер, — лишний повод для более пристального «подозрения» со стороны антифрод-логики, даже когда сам IP-пакет приходит с правильного адреса.

К тому же доступ к ИИ через VPN — обычно не «зашёл на пять минут», а рабочий инструмент на весь день: открытые вкладки, фоновые запросы к API, расширения. Каждое приложение и вкладка, использующие DoH независимо друг от друга, увеличивают шанс, что хоть один поток резолвится не туда — и именно там сервис однажды покажет ошибку региона, которую сложно объяснить, если проверяли только внешний IP.

Если вы настраиваете сервер именно под доступ к нейросетям, общая логика выбора такой инфраструктуры разобрана в статье аренда VPS для доступа к нейросетям: что выбрать и как настроить — DoH стоит проверять уже поверх этой базовой настройки, как один из источников скрытых утечек. Похожая логика полного перекрытия трафика обсуждается и в статье про kill switch для доступа к ИИ: смысл kill switch — не пропускать трафик мимо туннеля вообще, а DoH — пример того, как трафик формально идёт «мимо» логики туннеля, оставаясь зашифрованным HTTPS-соединением, которое простой kill switch не отличит от обычного веб-запроса.

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