Сайт «не существует»: история про DNS, ТСПУ и одну галочку в Happ
Однажды у человека в Happ перестало открываться вообще всё, даже ya.ru, а Telegram при этом работал как ни в чём не бывало. Распутывая этот случай, мы прошли весь путь: от того, как телефон узнаёт адрес сайта, до того, почему в конце августа 2026 года в России перестали помогать Zapret и ByeByeDPI.
Никаких специальных знаний не нужно: каждый термин объясняется по ходу, а команды для проверки можно пропустить.
Если вам нужно не разобраться, а просто починить, — есть короткая инструкция на пять минут: В Happ не открываются сайты, а Telegram работает.
Вечер, когда ничего не открывалось
Сообщение пришло в поддержку 14 сентября и выглядело обыденно: «В Happ не работает YouTube, а Telegram работает». Такие жалобы приходят часто, и обычно дело в конкретном сервере. Но дальше история стала странной.
| Улика | Что она подсказывает |
|---|---|
| Другой сервер в Happ — то же самое | дело не в сервере |
| В приложении INCY на тех же серверах всё открывается | серверы и дорога до них исправны |
| Wi-Fi или мобильный интернет — без разницы | дело не в провайдере |
| Не открывается вообще ничего, даже ya.ru | сломалось что-то общее для всех сайтов |
| Telegram работает | Telegram чем-то отличается от остальных |
| В журнале Happ пусто | приложение даже не пыталось соединиться |
| Выключили в настройках «Использовать локальную DNS» — всё заработало | виновник найден, но непонятно, почему |
Все улики сходятся на трёх буквах: DNS. Чтобы понять, что именно сломалось, придётся разобраться, что это такое. Это полезно и само по себе: в августе 2026 года DNS внезапно стал одной из главных тем для всех, кто пользуется интернетом в России.
Что такое DNS: справочная интернета
Компьютеры в интернете находят друг друга по номерам — IP-адресам вроде 77.88.55.242. Людям удобнее имена: ya.ru, youtube.com. DNS — это справочная, которая переводит имя в номер.
Каждый раз, когда вы открываете сайт, телефон сначала звонит в справочную: «Какой номер у ya.ru?» — и только получив ответ, соединяется с самим сайтом. Обычно это занимает несколько миллисекунд, и никто этого не замечает.
Вот как выглядит такой вопрос, если задать его вручную командой dig (она есть в macOS и Linux):
$ dig ya.ru
;; status: NOERROR
;; ANSWER SECTION:
ya.ru. 2 IN A 77.88.55.242
ya.ru. 2 IN A 77.88.44.242
ya.ru. 2 IN A 5.255.255.242NOERROR значит «всё в порядке», дальше идут три номера, по любому из которых можно открыть сайт. Число 2 — сколько секунд этот ответ можно помнить, прежде чем спрашивать снова.
Теперь понятна первая улика. Telegram знает номера своих серверов наизусть, справочная ему не нужна. Поэтому, когда DNS ломается, Telegram продолжает работать, а всё остальное — нет. И журнал Happ пуст по той же причине: номер не получен, звонить некуда, записывать нечего.
Кто отвечает на вопрос
Справочная, которой звонит телефон, называется резолвером. По умолчанию это резолвер вашего провайдера, но можно выбрать публичный: у Google это 8.8.8.8, у Cloudflare — 1.1.1.1, у Quad9 — 9.9.9.9, у Яндекса — 77.88.8.8.
Сам резолвер всех номеров не знает. Он спрашивает по цепочке: сначала корневой сервер интернета («кто отвечает за .ru?»), потом сервер зоны .ru («кто отвечает за ya.ru?»), и только затем сервер самого сайта. Полученный ответ резолвер запоминает, чтобы в следующий раз не бегать заново.
Открытка, конверт и посылка: DNS, DoT и DoH
Классический DNS придумали в 1980-х, когда о слежке никто не думал. Поэтому вопрос в справочную — это открытка: он летит открытым текстом на порт 53, и любой узел по дороге видит, какой сайт вы ищете. Хуже того, по дороге можно подсунуть свой ответ, и отличить его от настоящего будет нечем.
Чтобы это исправить, придумали зашифрованные варианты:
- DoT (DNS over TLS) — письмо в запечатанном конверте, но отправленное через отдельное окошко «только для писем в справочную» (порт 853). Прочитать нельзя, но видно, что вы пишете в справочную, — и окошко легко закрыть.
- DoH (DNS over HTTPS) — письмо, спрятанное в обычную посылку: запрос идёт как посещение сайта по HTTPS на порт 443. Снаружи не отличить от открытия любой страницы. Но на посылке всё равно написано имя получателя, например
dns.google, — и по нему посылку можно узнать.
| Способ | Как ходит | Видно ли, что вы ищете | Как ему можно помешать |
|---|---|---|---|
| Обычный DNS (в Happ — DoU) | UDP, порт 53 | да, целиком | подменить ответ или тихо перенаправить |
| Обычный DNS по TCP | TCP, порт 53 | да | то же самое, но пока трогают реже |
| DoT | TLS, порт 853 | нет, но видно, что это DNS | закрыть порт или оборвать соединение |
| DoH | HTTPS, порт 443 | нет | узнать справочную по имени и не пропускать |
| DoQ | QUIC, порт 853 | нет | закрыть порт |
| DNSCrypt | свой протокол | нет | узнать по адресу или поведению |
Эти вещи часто встречаются под бытовыми названиями. «Частный DNS» в настройках Android — это DoT. «Безопасный DNS» в браузере Chrome или Firefox — это DoH. А ещё есть DNSSEC — цифровая подпись ответа, которая могла бы разоблачать подмену. Но пользуются ей далеко не все сайты: например, у youtube.com подписи нет, и проверять там нечего.
И последнее, самое важное для этой истории. Вопрос, заданный внутри VPN-туннеля, не видит никто по дороге — даже если это самая простая «открытка». Для провайдера туннель — это просто поток зашифрованных байтов до одного сервера. Что внутри, он не знает.
Почему о DNS заговорили все
Годами блокировки в России работали по имени сайта в момент соединения. DNS в основном оставался в стороне: хочешь честный ответ — укажи Google или Cloudflare вместо провайдера. Этот совет кочевал из инструкции в инструкцию. В 2026 году он перестал работать.
| Когда | Что заметили |
|---|---|
| Начало июля | У нескольких крупных операторов на время перестали работать TCP-подключения к DNS Google. Через какое-то время всё вернули — похоже на пробу |
| Середина августа | Шифрованный DNS Google и Cloudflare перестал отвечать у части абонентов Ростелекома, Дом.ру, Таттелекома, SkyNet и Билайна. DoT обрывался сразу, DoH «зависал» до таймаута |
| Вечер 26 августа | Самые обычные DNS-запросы к 1.1.1.1 и 8.8.8.8 стали перехватывать: вместо Google и Cloudflare на них отвечает другой сервер |
Что обнаружил автор статьи на Хабре
27 августа на Хабре вышла статья «На ТСПУ начали перехватывать открытые DNS запросы к 1.1.1.1, 8.8.8.8». ТСПУ — это оборудование, которое по закону стоит в сетях российских операторов и фильтрует трафик. Автор, angry_agent, провёл маленькое расследование, которое читается как детектив.
Началось с простого вопроса к Google о YouTube:
$ dig youtube.com @8.8.8.8
;; status: NXDOMAIN
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)NXDOMAIN означает «такого домена не существует». YouTube, разумеется, существует. Но самое интересное спрятано в строке flags: там стоит aa — «полномочный ответ». Так отвечает только хозяин домена. Google — это справочная, а не хозяин youtube.com, и так ответить он не мог. Значит, отвечал кто-то другой, представившись Google.
Вторая улика: тот же вопрос, отправленный не по UDP, а по TCP, получил настоящие адреса:
$ dig +tcp youtube.com @8.8.8.8
;; status: NOERROR
;; ANSWER SECTION:
youtube.com. 300 IN A 64.233.162.136
youtube.com. 300 IN A 64.233.162.91Третья улика оказалась самой изящной. У каждого пакета в интернете есть счётчик пересадок: каждый узел на пути уменьшает его на единицу, а когда счётчик доходит до нуля, узел выбрасывает пакет и присылает отправителю уведомление «не доставлено». Важная деталь: в уведомление узел вкладывает копию заголовка погибшего пакета — таким, каким пакет к нему доехал, вместе с адресом получателя.
Автор отправил DNS-вопрос на 8.8.8.8 с запасом всего на две пересадки. Уходя от него, пакет нёс адрес 8.8.8.8 — это видно в журнале отправки. Пакет погиб на втором узле, пришло уведомление, а в копии заголовка адрес получателя был уже 195.208.5.1 — сервер НСДИ, национальной системы доменных имён.
Уехал пакет с одним адресом, а до второго узла доехал с другим. Отправитель адрес не менял, а узел лишь скопировал то, что к нему пришло, — значит, адрес переписали между ними, прямо по дороге. Кто это сделал, показал контрольный опыт: такой же пакет, но с произвольными байтами вместо DNS-вопроса, доезжал с прежним 8.8.8.8. Обычный маршрутизатор в содержимое пакетов не заглядывает, значит, адрес меняет оборудование, которое их читает, — ТСПУ. Такая подмена адреса называется DNAT.
Картина сложилась такая:
- телефон спрашивает Google о YouTube;
- ТСПУ узнаёт в пакете DNS-вопрос и незаметно переадресует его в НСДИ;
- НСДИ на заблокированные сайты отвечает «такого домена нет», на все остальные — честно;
- ответ приходит будто бы от Google, и телефон ему верит.
Поэтому снаружи всё выглядит так, будто интернет в полном порядке, а конкретный сайт просто исчез.
Система оказалась не безупречной. Если сначала отправить вопрос «на две пересадки», повторный вопрос доходил до настоящего Google. А если выстрелить пачкой одинаковых вопросов, «не существует» получал только первый, остальные — настоящие адреса. В комментариях к статье картина пестрее: у одних провайдеров вместо «не существует» приходит адрес страницы-заглушки, у других перехвата нет вовсе. Вывод один: это происходит не везде и не всегда одинаково.
Зачем ТСПУ переписывать адрес
Сами цели ТСПУ никто не публикует, но логику можно восстановить. Задача простая: чтобы заблокированный сайт не открывался, даже если человек сменил DNS на Google или Cloudflare. Долгие годы это был самый простой обход: справочная провайдера врёт, а 8.8.8.8 отвечает честно.
С вопросом, который летит к Google, у оборудования есть три варианта:
| Вариант | Чем он плох или хорош |
|---|---|
| Выбросить вопрос | у человека ломается весь интернет, а не один сайт; это заметно, и в ответ сразу меняют DNS |
| Сочинить ответ самому | пришлось бы держать список заблокированных доменов и на лету собирать ответы на DNS-трафик всей страны: дорого, и легко ошибиться |
| Переслать вопрос в НСДИ | список там уже есть, и сервер умеет отвечать как обычная справочная; оборудованию остаётся только поменять адрес |
Третий вариант самый дешёвый: ТСПУ ничего не решает сам, а лишь переставляет адреса. На пути туда в вопросе 8.8.8.8 меняется на 195.208.5.1, и вопрос уходит в НСДИ. На пути обратно в ответе адрес отправителя меняется с 195.208.5.1 на 8.8.8.8.
Обратная замена обязательна. Телефон ждёт ответ от того, кого спрашивал, и ответ от незнакомого 195.208.5.1 он бы просто выбросил. Именно поэтому подмена невидима: человек уверен, что ему ответил Google.
Что это даёт:
- заблокированный сайт «не существует», а все остальные открываются, поэтому человек не видит поломки и не ищет обход;
- до соединения с сайтом дело не доходит, и оборудованию не приходится разбирать само соединение; автор статьи считает, что так снижают нагрузку на ТСПУ, и эта мысль нам ещё пригодится;
- DNS-вопросы людей уходят в НСДИ, даже если человек вручную указал чужую справочную.
Трогают при этом только DNS-вопросы. На тот же адрес бывает и другой трафик, переписывать его незачем: цель — именно вопрос в справочную.
Перехват касается не только запрещённых сайтов. Когда он включён, государственный резолвер получает все DNS-вопросы, отправленные на эти адреса, — то есть видит, какие сайты вы открываете, какими бы они ни были.
Почему DoT «рвётся», а DoH «зависает»
Параллельно шифрованный DNS сломался двумя разными способами. Разница между ними как раз объясняется открыткой, конвертом и посылкой.
DoT ходит через своё окошко — порт 853. Чтобы его закрыть, не нужно ничего читать: достаточно правила «всё, что идёт на 853-й порт, оборвать». Соединение устанавливается и тут же рвётся, приложение сразу получает ошибку.
DoH прячется в порт 443 вместе со всеми сайтами, закрыть его целиком нельзя — упадут банки и госуслуги. Но в самом начале HTTPS-соединения клиент открытым текстом называет имя сервера: dns.google или cloudflare-dns.com. Оборудование узнаёт это имя и молча выбрасывает пакеты. Ошибки нет, ответа тоже нет. Приложение ждёт секунды, а потом сдаётся.
Для человека разница выглядит так: при сломанном DoT интернет пропадает сразу, при сломанном DoH всё мучительно медленно открывается или не открывается совсем.
Что это ломает в обычной жизни
| Где у вас указан DNS | Что происходит |
|---|---|
8.8.8.8 или 1.1.1.1 в роутере, Windows или macOS | заблокированные сайты «не существуют», браузер пишет DNS_PROBE_FINISHED_NXDOMAIN |
| «Частный DNS» Google или Cloudflare на Android | Android сообщает, что частный DNS-сервер недоступен, и интернет пропадает во всех приложениях |
| «Безопасный DNS» Google или Cloudflare в браузере | страницы открываются по нескольку секунд или не открываются |
Приложение с «зашитым» 8.8.8.8 | то же, что с роутером |
| Прокси или сервер, указанный доменным именем, а не адресом | подключение идёт очень долго или не идёт вовсе |
Отдельно: почему перестали помогать Zapret и ByeByeDPI
Если YouTube годами открывался через Zapret на компьютере или роутере или через ByeByeDPI на телефоне, а в конце августа вдруг перестал, скорее всего, дело именно в этом.
Zapret и ByeByeDPI работают совсем не так, как VPN. Они не везут трафик за границу, а обманывают оборудование в момент соединения: дробят первые пакеты, подсовывают ложные, чтобы фильтр не разглядел имя сайта в приветствии. Это хитрая маскировка самого соединения.
Но соединение начинается только после того, как получен адрес. Если справочная ответила «такого сайта не существует», соединения не будет вовсе, и маскировать нечего. Вот та самая мысль из статьи на Хабре: блокировка сдвинулась на шаг раньше, туда, где эти программы не работают.
Разработчики Zapret честно пишут об этом в документации, в разделе «Когда это работать не будет». Первым пунктом там стоит: «Если подменяется DNS».
Обе программы маскируют соединение с сайтом, но не вопрос в справочную. Ирония в том, что инструкции к ним годами советовали «независимые» 8.8.8.8 и 1.1.1.1 — именно эти адреса с 26 августа и перехватывают. У ByeByeDPI в режиме VPN по умолчанию стоит DNS 1.1.1.1 обычным запросом, то есть ровно под перехват.
Узнать эту ситуацию просто: обходчик включён и вроде бы работает, а браузер пишет не «соединение сброшено», а «сайт не найден» или DNS_PROBE_FINISHED_NXDOMAIN.
Что пробуют люди. Сразу оговоримся: всё это работает сегодня и может перестать завтра.
- Другой DNS. В ByeByeDPI есть выбор: системный, Google, Cloudflare, Quad9 или свой. Первые два сейчас перехватываются. По сообщению одного из наших пользователей, в сентябре Quad9 (
9.9.9.9) у него отвечал честно, но это не проверка, а одно наблюдение. - DNS по TCP. Судя по замерам, перехватывают в основном UDP. Но этот вариант поддерживает далеко не каждое устройство.
- Шифрованный DNS, пропущенный через сам обходчик. Так фильтр не увидит имя справочной в приветствии. Документация Zapret советует для таких случаев dnscrypt.
- Спрашивать внутри туннеля. Самый надёжный вариант: провайдер не видит ни вопроса, ни того, кому он адресован.
Как проверить у себя
Проверять нужно с выключенным VPN: внутри туннеля перехвата нет, и проверка покажет, что всё в порядке.
На Windows откройте командную строку и сравните два ответа. Первая команда спрашивает обычным способом, вторая — по TCP:
nslookup youtube.com 8.8.8.8
nslookup -vc youtube.com 8.8.8.8На macOS и Linux то же самое делает dig:
dig youtube.com @8.8.8.8
dig +tcp youtube.com @8.8.8.8| Что вы увидели | Что это значит |
|---|---|
| Оба раза настоящие адреса | перехвата на вашей линии сейчас нет |
Обычный запрос: «не существует» или NXDOMAIN, по TCP — адреса | перехват есть |
В ответе от «Google» стоит флаг aa | отвечал не Google |
Вместо адресов сайта приходит 127.0.0.1 или адрес страницы-заглушки | подмена адресом-заглушкой |
| Ответа нет вовсе, только таймаут | запрос выбрасывается по дороге |
DNS в Happ: где он живёт и зачем там столько настроек
Вернёмся к нашей истории. Чтобы понять, при чём тут галочка, нужно знать, как Happ обращается с DNS.
Happ — это не просто труба до сервера. Внутри приложения работает ядро Xray со своей справочной и своими правилами: одни сайты оно открывает напрямую, другие через VPN-сервер. Поэтому и справочных в Happ две.
«Удалённый DNS» отвечает за сайты, которые идут через VPN. Вопрос в эту справочную уходит через туннель, поэтому провайдер его не видит и подменить не может. Даже если здесь указан 1.1.1.1, перехват ему не страшен: пакет покидает туннель уже за границей.
«Домашний DNS» отвечает за сайты, которые идут напрямую, — обычно российские. Вопрос уходит мимо VPN, обычным путём через провайдера, и именно здесь перехват может задеть. По документации Happ по умолчанию здесь стоит обычный запрос к 8.8.8.8 — тот самый адрес, который сейчас перехватывают. Для российских сайтов это обычно безвредно: НСДИ отвечает на них честно. А вот если вручную поставить сюда шифрованный DNS Google, он упрётся в «зависание». Поэтому у нас там стоит Яндекс по DoH: он в России не блокируется и отвечает быстро.
Вот как это выглядит на двух сайтах:
| Вы открываете | Решение Happ | Кто ищет адрес | Как идёт вопрос |
|---|---|---|---|
| youtube.com | через VPN | «Удалённый DNS» | внутри туннеля, провайдер не видит |
| ozon.ru | напрямую | «Домашний DNS» | мимо туннеля, зашифрованно, к Яндексу |
Остальные настройки DNS в Happ, коротко и понятно:
| Настройка | Что делает | Нужно ли трогать |
|---|---|---|
| «Использовать локальную DNS» | перехватывает DNS-вопросы всех приложений телефона и отдаёт их ядру, чтобы оно ответило по своим правилам, а не пустило их «открыткой» | можно включать |
| «Локальный порт DNS» | служебный порт этого перехвата | нет |
| «Использовать поддельную DNS» | приложение сразу получает фиктивный адрес, а настоящий ищется уже по правилам ядра; вопрос вообще не уходит в сеть открытым | лучше не включать: часть приложений с этим работает плохо |
| «DNS туннеля» | появляется вместо «Удалённого DNS», когда подписка приходит полными конфигурациями | нет |
| «Использовать DNS из JSON» | брать справочную из конфигурации, которую прислал сервис | нет |
Про «DNS туннеля» стоит сказать отдельно. Чтобы в списке серверов был пункт «Авто», который сам выбирает лучший сервер, мы присылаем Happ не короткие ссылки, а полные конфигурации ядра. Такой режим Happ называет ограниченным и честно предупреждает: «Маршрутизация HAPP не применяется к конфигурации JSON». Все правила, включая DNS, лежат внутри присланной конфигурации, а приложение передаёт её ядру как есть.
Ничего менять не нужно: правильные справочные уже заданы. «Использовать локальную DNS» можно включать — с 14 сентября это работает. Не вписывайте вручную DNS Google или Cloudflare в настройки телефона и роутера: сейчас это скорее навредит.
Разгадка: почему одна галочка ломала всё
Теперь можно вернуться к вечеру 14 сентября и собрать улики вместе. Сначала мы честно проверили очевидное и всё отбросили:
- сервер — подняли ту же конфигурацию у себя и прогнали YouTube: 200, быстро;
- перехват ТСПУ — человек открыл
https://1.1.1.1без VPN, и он открылся; - настройку DNS в профиле — попробовали два разных варианта, не помогло ни одно: в ограниченном режиме Happ эти поля в ядро не передаёт;
- пропущенную справочную в конфигурации — добавили её, тоже не помогло.
Ответ нашёлся внутри самого приложения. Happ для Android построен на основе другого известного клиента — v2rayNG. Когда вы включаете «локальную DNS», приложение само дописывает в конфигурацию ядра две вещи: «вот место, куда отдавать DNS-вопросы» и первым же правилом «всё, что пришло на порт 53, отдай туда».
Но если конфигурацию прислал сервис целиком, приложение ничего в неё не дописывает. Правила перехвата нет, а сам перехват со стороны телефона включён. Вопрос «какой номер у ya.ru?» уходит в туннель к служебному адресу, который никуда не ведёт, и ответ не приходит никогда. Номер не получен, соединения нет, в журнале пусто. Именно это мы и видели.
Та же ошибка давно известна и у самого v2rayNG: на GitHub есть обращение о том, что с JSON-подпиской и включённым локальным DNS все запросы висят, и его закрыли без исправления. А INCY такого перехвата не делает вовсе, поэтому у неё вопрос уходил обычным путём через туннель и получал ответ.
Раз приложение не дописывает нужное правило, его дописываем мы. Теперь в каждой конфигурации для Happ есть справочная, место для DNS-вопросов и правило перехвата, стоящее первым:
"dns": {"servers": ["1.1.1.1", "8.8.8.8"]},
"routing": {"rules": [
{"inboundTag": ["socks", "tun"], "port": "53", "outboundTag": "dns-out"},
...
]}Проверили в три шага: сначала запустили ядро с этими конфигурациями у себя и убедились, что DNS-вопросы перехватываются и уходят в туннель, потом включили одному человеку, у которого всё сломалось, — у него заработало. После этого включили всем, кто пользуется Happ.
Эта маленькая вставка — хорошая иллюстрация всей истории. В ней стоят те же 1.1.1.1 и 8.8.8.8, которые с 26 августа перехватывают у многих провайдеров. Но вопрос к ним задаётся внутри туннеля, и перехватить его по дороге невозможно. Важен не адрес справочной, а путь, по которому к ней идёт вопрос.
Что стоит запомнить
- Если Telegram работает, а всё остальное нет, почти всегда виноват DNS.
- Ответ «такого сайта не существует» может быть неправдой: его может подсунуть кто-то по дороге.
- Шифрованный DNS больше не гарантирует ответа: DoT обрывают по порту, DoH узнают по имени справочной.
- Zapret и ByeByeDPI маскируют соединение, но не DNS. Если сломан DNS, они бессильны, пока не поменять справочную.
- Самый надёжный способ — задавать DNS-вопросы внутри туннеля, где их не видно.
- В Happ «Удалённый DNS» защищён туннелем, а «Домашний DNS» идёт мимо него, и его стоит оставить таким, каким он пришёл.
Источники
- Хабр: На ТСПУ начали перехватывать открытые DNS запросы к 1.1.1.1, 8.8.8.8
- Хабр: В России начали блокировать протоколы DoH и DoT
- Теплица социальных технологий: Что происходит с DNS в России?
- Zapret: документация, раздел «Когда это работать не будет»
- ByeByeDPI на GitHub
- Happ: маршрутизация и настройки DNS
- v2rayNG: JSON-подписка и локальный DNS