zapretdiscordyoutube/todo
Watch
1
0
Fork
You've already forked todo
 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions
todo/DPI/google-dns-8888-block-july-2026.md
loop-uh 08b4491545
Some checks failed
Published content check / validate (push) Failing after 3s
Details
Завершить переезд базы знаний на Forgejo 
Обновить правила репозитория и подписи исходников в 99 заметках, не затрагивая пользовательские незакоммиченные файлы. Сделать Forgejo Actions содержательным: проверять опубликованный commit, а не пустое рабочее дерево после checkout.
2026-08-07 08:27:28 +03:00

46 KiB
Raw Permalink Blame History

date tags aliases link
2026-07-03
dns
doh
dot
quic
tspu
rkn
incident
vpn
amazon
troubleshooting
Инцидент 3 июля 2026
Блокировка 8.8.8.8
Google DNS заблокирован
Отвалился DoH Google
Перестали работать VPN 3 июля 2026
Не работают серверы EA июль 2026
Battlefield FIFA не подключается июль 2026
Сбой интернета 3 июля 2026

🚫 Инцидент 3 июля 2026: 8.8.8.8 заблокирован по TCP (DoH/DoT) — «умерли» VPN; параллельно ложились серверы EA

[!info] О чём заметка Утром 3 июля 2026 (около 10:00, по сообщениям пользователей) IP-адрес публичного DNS-сервера Google 8.8.8.8 перестал отвечать в России по TCP: не работают DoH (DNS-over-HTTPS, порт 443/TCP), DoT (DNS-over-TLS, порт 853/TCP) и DNS по TCP/53. При этом UDP не тронут: классический DNS по UDP/53 и даже DoH по HTTP/3 (QUIC, UDP/443) к тому же 8.8.8.8 работают, как и 8.8.4.4 — второй адрес того же Google DNS — и Google DNS по IPv6. Главный видимый эффект — массово «сломались» VPN и прокси-клиенты, у которых в конфиге DNS прописан именно 8.8.8.8: туннель жив, но имена сайтов не резолвятся, и всё выглядит как «VPN перестал работать». В те же сутки прошли ещё две волны: вечером 2 июля 2026 легли игровые серверы EA (Battlefield, FIFA, Titanfall 2; по версии сообщества — снова ковровый блок подсетей Amazon, к середине дня 3 июля правило откатили), а около 12:00 МСК 3 июля случился синхронный всплеск жалоб «упал интернет» сразу в нескольких регионах и на разнородные сервисы. Здесь — что именно заблокировано, почему это кладёт VPN-клиенты и игры, и как починить за минуту.

[!warning] Статус данных: сообщения пользователей, не контролируемый замер Вся картина ниже — сводка сообщений пользователей из чатов за 3 июля 2026 плюс скриншоты агрегатора сбоев Detector404, а не официальная информация или систематический замер. География и операторы по сообщениям: Москва (Билайн AS8402, Т2 — по сути сеть Ростелекома), Самара и ЦФО (Эртелеком / Дом.ру), юг России (Билайн), плюс ТТК, Ростелеком и МТС без указания города. Картина неравномерна даже внутри одного оператора: у части абонентов Ростелекома 8.8.8.8 в тот же момент работал нормально. ТСПУ (Технические Средства Противодействия Угрозам — DPI-оборудование Роскомнадзора на сетях операторов) настраиваются неравномерно по операторам, регионам и отдельным узлам, поэтому у вас картина может отличаться, а само состояние может измениться в любой день. Версия о том, что это блокировка на ТСПУ и тем более «тест зарезания сторонних DNS», — интерпретация сообщества, а не подтверждённый факт.

TL;DR

  • С ~10:00 3 июля 2026 8.8.8.8 недоступен по TCP у ряда российских операторов (ТТК, Ростелеком, ЭР-Телеком, МТС, МегаФон, Билайн, Т2, Дом.ру): DoH (443/TCP), DoT (853/TCP) и DNS по TCP/53 падают в таймаут; режется TCP и на другие порты (подтверждено mtr --tcp). ICMP (ping 8.8.8.8) при этом отвечает — то есть блокируется именно TCP, а не весь IP-адрес.
  • Основной удар — по TCP; UDP в целом проходит, но не гарантированно: классический DNS по UDP/53 к 8.8.8.8 у большинства отвечает (nslookup youtube.com 8.8.8.8), и — важная деталь — DoH по HTTP/3 (QUIC, UDP/443) к тому же 8.8.8.8 тоже работает. Но часть пользователей отмечает, что и по UDP/53 Google «далеко не всегда отвечает» — то ли местами задет и UDP, то ли сказывается рейт-лимит. Итог: это блок по связке IP + транспорт (в первую очередь TCP), а не полное выпиливание адреса.
  • 8.8.4.4 работает целиком (и DoH, и DoT, и UDP/53), Google DNS по IPv6 тоже работает (2001:4860:4860::8888 / 2001:4860:4860::8844). То есть заблокирован именно адрес 8.8.8.8, а не сервис Google DNS как таковой.
  • Каскадный эффект: VPN/прокси-клиенты с DNS https://8.8.8.8/... или tls://8.8.8.8 перестали резолвить домены — «сайт не найден», проваленный пинг-тест в клиенте, YouTube с ошибкой «Нет подключения к интернету». Ломались HAPP, Throne, v2rayN, nekobox, YogaDNS — при живом туннеле (в т.ч. VLESS-XHTTP с XMUX). А вот клиенты, гоняющие DoH по HTTP/3 (например, Clash с включённым «Предпочитать H3»), могли продолжать работать через тот же 8.8.8.8 как ни в чём не бывало.
  • Быстрый фикс: сменить в конфиге DNS 8.8.8.8 на 8.8.4.4 (или другой резолвер) либо пустить DNS-запросы через туннель, где блок ТСПУ не виден. Рабочий приём из практики — жёстко привязать dns.google к 8.8.4.4 (в hosts или в клиенте): и TLS-сертификат остаётся валиден, и IP рабочий.
  • Картина неравномерна даже внутри одного оператора. У части абонентов Ростелекома 8.8.8.8 работает штатно, у других — заблокирован; это указывает на раскатку по отдельным узлам/регионам, а не на единое правило по всей сети оператора.
  • Фильтр стоит на абонентских сетях, а не на хостинге. Проверка через globalping из разных сетей: у ЭР-Телеком (Москва), Ростелекома (Ханты-Мансийск), МегаФона (Москва), МТС (Новосибирск) — таймаут, а из дата-центра Selectel (СПб) 8.8.8.8:443 отвечает (штатный редирект 302 → dns.google). То есть режут трафик к 8.8.8.8 у конечных пользователей, а не сам сервер Google — из ДЦ он доступен.
  • Это не «DoH запретили как протокол»: другие DoH-провайдеры в целом работают. Заблокирована конкретная связка IP:порт — хотя есть и единичные сообщения о более широкой деградации DoH у отдельных операторов (см. ниже).
  • Параллельная волна тех же суток: с ~21:00 МСК 2 июля 2026 были недоступны игровые серверы EA (Battlefield, FIFA, Titanfall 2). По версии сообщества, блокировали не EA адресно, а снова подсети Amazon (AWS) ковровым блоком; к середине дня 3 июля правило, по сообщениям, откатили. Подробнее — в разделе ниже.
  • Около 12:00 МСК 3 июля — ещё одна волна: синхронный всплеск жалоб «упал интернет» сразу в нескольких регионах (Москва, Подмосковье, Петербург, Самарская область — по графикам Detector404) и на разнородные сервисы (Авито, облако Keenetic/Netcraze и др.). Версия сообщества — очередная попытка зарезать VPN, задевающая всё подряд; официальных подтверждений нет.

На пальцах: почему «сломался VPN», если сломался DNS

[!example] Аналогия: справочная служба DNS — это справочная служба: прежде чем «позвонить» сайту, устройство спрашивает у неё номер (IP-адрес) по имени (youtube.com). В конфигах VPN-клиентов часто прописана одна конкретная справочная — Google по адресу 8.8.8.8, причём по «защищённой линии» (DoH/DoT). 3 июля 2026 эту линию перерезали: сам телефон (туннель VPN) исправен, гудок есть, но узнать номер абонента больше не у кого — и любой звонок «по имени» заканчивается ошибкой «такой сайт не найден». Достаточно вписать в конфиг соседнее окно той же справочной (8.8.4.4) — и всё оживает.

Отсюда и обманчивая картина: часть сайтов работает (их адреса остались в кеше или зашиты по IP), большинство — нет. Пользователь видит «VPN отвалился», грешит на протокол или баги клиента, хотя туннель цел — мёртв только резолвер.

Что наблюдали 3 июля 2026

Сводка по сообщениям из разных сетей (Москва — Билайн AS8402 и Т2, Самара и ЦФО — Эртелеком/Дом.ру, юг России — Билайн; плюс ТТК, Ростелеком, МТС):

Проверка Результат
8.8.8.8 — DoH (TCP/443) ❌ таймаут соединения
8.8.8.8 — DoT (TCP/853) ❌ таймаут
8.8.8.8 — DNS по TCP/53 ❌ таймаут (подтверждено на Т2 и Билайн Москва)
8.8.8.8 — TCP на другие порты ❌ режется (подтверждено mtr --tcp 8.8.8.8)
8.8.8.8 — ICMP (ping) ✅ отвечает — блокируется TCP, а не весь IP
8.8.8.8 — классический DNS (UDP/53) ⚠️ у большинства работает (nslookup отвечает; в Самаре на Дом.ру достаточно повесить 8.8.8.8 на интерфейс Windows), но часть сообщает, что Google по UDP/53 «далеко не всегда отвечает»
8.8.8.8 — DoH по HTTP/3 (QUIC, UDP/443) ✅ работает, не заблокирован
8.8.8.8 — DoQ (DNS-over-QUIC, UDP/853) — не проверить: Google этот протокол на публичном DNS, по сообщениям, пока не поддерживает
8.8.8.8:443 из дата-центра (Selectel, СПб) ✅ отвечает (302 → dns.google) — фильтр на абонентских сетях, не на сервере
8.8.4.4 — DoH/DoT/UDP-53 ✅ работает полностью
Google DNS по IPv6 (2001:4860:4860::8888, 2001:4860:4860::8844) ✅ работают
Другие популярные DNS-серверы ✅ в целом работают (но см. оговорку про Билайн ниже)

Начало — около 10 утра 3 июля 2026 (успешный ответ 8.8.4.4 в тесте ниже датирован 03 Jul 2026 10:06 GMT). Симптомы схожи у разных провайдеров и городов — что указывает на централизованную настройку ТСПУ, а не аварию у одного оператора; при этом раскатка идёт неравномерно по узлам — у части абонентов того же Ростелекома 8.8.8.8 продолжал работать.

Наглядно это видно в проверке через globalping (сервис распределённых сетевых замеров) из разных сетей 3 июля 2026: у абонентских операторов — таймаут, из дата-центра Selectel — штатный ответ сервера Google:

! globalping http 8.8.8.8 из пяти сетей: ЭР-Телеком (Москва, AS25446), Ростелеком (Ханты-Мансийск, AS12389), МегаФон (Москва, AS12714), МТС (Новосибирск, AS8359) — Request timeout; Selectel (СПб, AS49505) — HTTP/1.1 302, редирект на dns.google. Блокируют трафик к 8.8.8.8 у конечных пользователей, а не сам сервер.

[!note] Противоречие в сообщениях про порт 53 — разрешилось в пользу «блок только TCP» Одни пользователи писали «8.8.8.8 заблокирован по 53/853/443», другие — «обычный 53 работает везде». Противоречия нет: по уточнениям с Т2 и Билайн Москва блок накрывает TCP-порты 53/853/443, а классический DNS ходит по UDP/53 и проходит — nslookup по умолчанию использует именно UDP. У части операторов картина может быть шире или уже.

[!note] Дыра в блоке: HTTP/3 (QUIC) не зарезан DoH-запрос к 8.8.8.8:443 по UDP (HTTP/3, поверх QUIC) проходит, хотя тот же запрос по TCP — в таймауте. Отсюда неожиданный эффект: клиенты, предпочитающие H3 для DoH (в Clash — тумблер «Предпочитать H3»: «Использовать HTTP/3 для DNS DoH»), продолжали резолвить через 8.8.8.8, и у их владельцев «ничего не сломалось». Возможная причина разнобоя в наблюдениях «у меня работает / у меня нет» — именно транспорт, по которому клиент ходит к резолверу (у части систем DoH может уходить по HTTP/3 автоматически). Полагаться на эту дыру не стоит: QUIC у российских операторов и так под периодическим давлением, и лазейку могут закрыть в любой момент.

! Тот самый тумблер в DNS-настройках Clash: «Предпочитать H3 — использовать HTTP/3 для DNS DoH». С ним DoH к 8.8.8.8 уходит по QUIC (UDP/443) и блок TCP не задевает.

Каскад: «отвалились VPN», хотя туннели живы

Типичные жалобы того утра: «перестал работать даже VLESS-XHTTP с XMUX», «часть сайтов работает, но большинство — “сайт не найден”», «пинг-тест из клиента проваливается», «Ютуб открывается, но пишет “Нет подключения к интернету”». Затронуты разные клиенты: HAPP (телефон), Throne (десктоп), v2rayN, nekobox (конфиги вида https://8.8.8.8/dns_query), YogaDNS.

Общий знаменатель у всех — DNS через 8.8.8.8 по DoH/DoT, идущий напрямую (мимо туннеля). Многие конфиги специально пускают DNS-запросы в обход туннеля ради скорости — и именно они уткнулись в блок ТСПУ. Насколько глубоко 8.8.8.8 прошит в типичных конфигах, видно на примере DNS-настроек Clash-клиента: адрес стоит и в «DNS-серверах по умолчанию» (через них резолвятся адреса самих DoH-серверов), и первым в основном списке DNS:

! Типичные DNS-настройки Clash-клиента (скриншот от 3 июля 2026): 8.8.8.8 — и в серверах по умолчанию, и первым в списке основных DNS. Показательно, что пострадавшие сначала грешили на баги клиентов (например, на проблемный tun-режим v2rayN под Linux) — классический случай, когда «не работает программа» оказывается симптомом изменений на сети, а не поломкой софта (об этом принципе — Zapret2/symptom-not-cause).

[!note] Отдельное наблюдение: деградация DoH шире, чем 8.8.8.8 (Билайн, юг России) Один пользователь (Билайн, юг России) сообщил, что у него в YogaDNS в то же утро отваливались по таймауту и другие DoH/DoT/DNSCrypt-провайдеры (включая Cloudflare), причём ~50% запросов проходили, остальные рандомно сбрасывались. Это единичное сообщение, противоречащее общей картине «остальные резолверы работают» — возможно, у отдельных операторов параллельно идёт более широкий эксперимент с фильтрацией стороннего шифрованного DNS. Похожие сигналы были и раньше: в конце июня 2026 у Мегафона в ряде регионов переставали работать сторонние DoH/DoT-резолверы целиком (см. tspu-whitelist-cloudflare-june-2026#DNS-проблемы у мобильных операторов).

📉 Полдень 3 июля: вторая волна — «упал интернет» по всей стране

Около 12:00 МСК 3 июля 2026 — через пару часов после блокировки 8.8.8.8 — прошла вторая, более широкая волна: у многих пропадал интернет целиком или отваливались отдельные сервисы. На агрегаторе сбоев Detector404 это видно как синхронный всплеск жалоб сразу в нескольких регионах в интервале примерно 11:00–12:30: Москва (до ~147 жалоб на пике, 2,1 тыс. за сутки), Московская область (пик в 12:05 — 102 жалобы), Санкт-Петербург (до ~74 на пике, 1,5 тыс. за сутки; плюс отдельный утренний всплеск около 07:00), Самарская область (до ~41 на пике, 503 за сутки). Как и в tspu-whitelist-cloudflare-june-2026, одновременный пик у независимых регионов и сервисов указывает не на аварию у кого-то одного, а на общее событие в сети.

! Detector404, Москва, 3 июля 2026: резкий пик жалоб около 11:00–12:30.

! Московская область: на пике 12:05 — 102 жалобы за 15 минут при обычном фоне в 10–20.

! Санкт-Петербург: тот же полуденный пик плюс отдельный всплеск около 07:00 утра.

! Самарская область: полуденный пик повторяет московский по форме — волна была не региональной.

По конкретным сервисам в тот же день (панель Detector404 на вторую половину дня 3 июля): резкий пик жалоб у Авито (4,1 тыс. за сутки), жалобы на ГдеБЕНЗ, Суточно.ру, провайдера «Телеком Сервис»; у Electronic Arts — статус «Сбой сети» с 807 жалобами за сутки, но лишь 10 за последний час — хвост вечерней волны 2 июля, что согласуется с сообщениями об откате правила (см. следующий раздел).

! Панель сервисов Detector404 во второй половине дня 3 июля 2026: жалобы на разнородные, не связанные между собой сервисы — от Авито до серверов EA.

Ещё один штрих той же волны: облако Keenetic (Netcraze) — сервис удалённого управления роутерами — перестало открываться и с домашнего подключения, и через мобильную связь, но открывалось через VPN/прокси. Раз через зарубежный туннель сервис жив, авария не на стороне облака — что-то фильтрует путь к нему из российских сетей.

[!warning] «Пытаются заблокировать VPN, но не получается» — гипотеза, а не факт Ведущая в сообществе версия полуденной волны: это продолжение попыток зарезать VPN-протоколы/инфраструктуру, где под замах раз за разом попадает всё подряд — от досок объявлений до облака роутеров. Версия согласуется с почерком последних недель (ковровые блоки подсетей, быстрые откаты, см. tspu-whitelist-cloudflare-june-2026 и DPI/tspu-false-blocks-june-2026), но никаких официальных подтверждений нет, а по одним графикам жалоб причину не установить.

🎮 Параллельная волна: вечером 2 июля легли игровые серверы EA (похоже, снова подсети Amazon)

На те же сутки пришлась вторая, формально не связанная с DNS волна блокировок. По сообщениям пользователей:

  • С ~21:00 МСК 2 июля 2026 стали недоступны игровые серверы EA (Electronic Arts): игроки не могли зайти в онлайн Battlefield, FIFA, Titanfall 2 — игры не подключались к серверам при живом интернете.
  • К середине дня 3 июля правило, по сообщениям пользователей, откатили — доступ к серверам EA вернулся.
  • Той же ночью один из пользователей не мог открыть форум ntc.party (площадка обсуждения сетевой цензуры), но сам не исключал локальную причину — он в это время экспериментировал с параметром quic_initial в обходных средствах, — так что этот эпизод к общей волне привязан слабо.

Версия сообщества о причине: блокировали не EA адресно, а опять целые подсети Amazon (AWS) — облака, в котором живёт игровая инфраструктура EA. То есть игры стали таким же сопутствующим ущербом коврового блока по диапазонам хостера, каким 23 июня 2026 были Discord и Twitch при перетряске списков Cloudflare. Механика таких ковровых блоков «по белому списку» (режется весь диапазон, наружу выпускают только явно разрешённое) разобрана в subnet-whitelist-blocking-2026, а хроника аналогичного инцидента — в tspu-whitelist-cloudflare-june-2026.

[!warning] Версия про Amazon не подтверждена Что резали именно подсети AWS, а не что-то другое, — предположение сообщества по косвенным признакам (характер отказа, быстрый откат, совпадение с почерком предыдущих инцидентов). Замеров конкретных заблокированных диапазонов в сообщениях не приводилось. Быстрый откат в течение суток похож на тест или ошибку конфигурации — как и с «белыми списками» 23 июня 2026.

Диагностика: как убедиться, что дело в 8.8.8.8

  • DoH к 8.8.8.8 — должен упасть в таймаут, если вы под блоком:
curl -v --connect-timeout 5 -H 'accept: application/dns-json' 'https://8.8.8.8/resolve?name=youtube.com&type=A'

Результат при блоке (реальный вывод от 3 июля 2026):

* Trying 8.8.8.8:443...
* ipv4 connect timeout after 5000ms, move on!
* Failed to connect to 8.8.8.8 port 443 after 5059 ms: Timeout was reached
curl: (28) Failed to connect to 8.8.8.8 port 443 after 5059 ms: Timeout was reached
  • Тот же запрос к 8.8.4.4 — проходит целиком: TLS-рукопожатие с валидным сертификатом CN=dns.google, ответ HTTP/2 200 с адресами youtube.com:
curl -v --connect-timeout 5 -H 'accept: application/dns-json' 'https://8.8.4.4/resolve?name=youtube.com&type=A'
  • Классический DNS (UDP/53) — работает к обоим адресам:
nslookup youtube.com 8.8.8.8
nslookup youtube.com 8.8.4.4
  • DoH по HTTP/3 (QUIC) к 8.8.8.8 — по наблюдениям, проходит, несмотря на блок TCP (нужен curl, собранный с поддержкой HTTP/3):
curl -v --http3-only --connect-timeout 5 -H 'accept: application/dns-json' 'https://8.8.8.8/resolve?name=youtube.com&type=A'
  • Отделить TCP-блок от полного IP-блока: ping 8.8.8.8 (ICMP) в этом инциденте отвечает, а mtr --tcp 8.8.8.8 — нет. Если пинг идёт, а TCP-коннект не устанавливается — блокируется именно TCP, сам адрес «живой».
  • Если DoH к 8.8.8.8 по TCP в таймауте, а к 8.8.4.4 (или к 8.8.8.8 по HTTP/3) проходит — это блок по IP:порт на сети оператора, чинить нужно конфиг DNS, а не переустанавливать клиент и не менять протокол туннеля.

Сочетание «TCP-коннект не устанавливается вовсе (таймаут на этапе Trying ...:443), а UDP к тому же адресу ходит» — почерк блокировки по связке IP+порт/протокол, а не DPI-фильтра по содержимому: до TLS-рукопожатия, где DPI мог бы что-то анализировать, дело просто не доходит. Где в конвейере ТСПУ стоят такие проверки — в DPI/dpi-analysis-pipeline.

Что делать

[!tip] Суть фикса Заблокирован один конкретный IP-адрес резолвера. Достаточно увести DNS с 8.8.8.8 — на соседний адрес, на другого провайдера или внутрь туннеля.

  • Самое быстрое: в конфиге клиента (HAPP, Throne, nekobox, v2rayN, YogaDNS, Xray/sing-box) заменить 8.8.8.8 на 8.8.4.4: https://8.8.8.8/dns_query → https://8.8.4.4/dns_query, tls://8.8.8.8 → tls://8.8.4.4. Это тот же Google DNS.
  • С доменом dns.google — аккуратно. Сам по себе домен резолвится в оба адреса (8.8.8.8 и 8.8.4.4), так что клиент может снова попасть на заблокированный — поэтому «просто впиши домен вместо IP» помогает не всегда. Но есть рабочий приём из практики: жёстко привязать dns.google к 8.8.4.4 (строка в hosts или в клиенте). Тогда одновременно и TLS-сертификат валиден (у Google он выписан на dns.google, а не на голый IP), и адрес рабочий — у пользователей, кто так сделал, DoH сразу заработал.
  • Либо сменить провайдера DNS: Cloudflare (1.1.1.1), AdGuard DNS, Quad9 и др. — по сообщениям за 3 июля 2026, другие популярные резолверы в целом работали (с оговоркой про единичные случаи деградации DoH — см. выше).
  • Либо пустить DNS-запросы через туннель (remote DNS через прокси/VPN, а не напрямую): внутри туннеля блок ТСПУ не виден, и 8.8.8.8 снова доступен. Это системное решение — следующая блокировка очередного резолвера вас уже не заденет.
  • Правильная схема на будущее — разнести domestic и remote DNS. В клиентах с раздельными DNS (Xray/v2rayNG, sing-box, Happ) настраивают два резолвера: remote — для проксируемых доменов, заворачивается в туннель (можно даже голый 53/udp — внутри туннеля это безопасно); domestic — для всего остального, идёт напрямую наружу и должен указывать на резолвер, который у вашего оператора гарантированно работает (провайдерский DNS, 8.8.4.4, 1.1.1.1). Тогда блокировка одного публичного адреса не роняет резолвинг целиком. Это же снимает проблему «курицы и яйца»: если адрес самого VPN-сервера в конфиге задан доменом (а не IP), его резолвит именно domestic-резолвер напрямую — и подключиться к туннелю удаётся, даже когда remote-DNS (8.8.8.8) недоступен. В Happ отдельной возни с доменами не требуется — достаточно развести domestic и remote, и он не гонит через remote то, что не проксируется.
  • Если есть IPv6 — можно использовать Google DNS по IPv6: 2001:4860:4860::8888 / 2001:4860:4860::8844 (по сообщениям, IPv6-адреса блок не затронул).
  • Если нужен именно 8.8.8.8 — уйти с TCP. Работают два обходных транспорта: классический DNS по UDP/53 (в Самаре на Дом.ру достаточно было выключить DoH на роутере и прописать 8.8.8.8 на сетевой интерфейс Windows) — но он нешифрованный, оператор видит и может подменять запросы; и DoH по HTTP/3 (в Clash — тумблер «Предпочитать H3») — шифрование сохраняется, но лазейка живёт ровно до тех пор, пока QUIC к этому адресу не зарезали тоже.
  • Проверить, чем на самом деле резолвит ваш клиент. В Clash-клиентах включённое «Переопределение настроек DNS» подставляет свой список резолверов (часто с 8.8.8.8 в «DNS-серверах по умолчанию» — они используются для резолвинга адресов самих DoH-серверов) — при диагностике это маскирует, какой именно резолвер отваливается. Отключение переопределения возвращает DNS из профиля/системы.
  • После правки — сбросить кеш DNS и перезапустить клиент, затем повторить пинг-тест/открыть пару сайтов.

! Тумблер «Переопределение настроек DNS» в настройках Clash (здесь выключен): во включённом состоянии клиент подменяет DNS из профиля своим списком — при диагностике сначала выясните, какой список реально активен.

[!warning] 8.8.4.4 — не гарантия на будущее Если версия про «тест зарезания сторонних DNS» верна, следующим может стать любой другой публичный резолвер, включая 8.8.4.4 и 1.1.1.1. Надёжнее либо возить DNS внутри туннеля, либо держать в конфиге несколько запасных резолверов разных провайдеров.

Контекст и гипотезы: зачем блокировать половину Google DNS

Достоверно известно только само наблюдение: 8.8.8.8 стал недоступен по TCP у нескольких операторов одновременно, 8.8.4.4 не тронут. Стратегическая рамка при этом известна: у РКН и Минцифры есть опубликованные планы до 2030 года с целевыми показателями по подавлению VPN и фильтрации всего трафика Рунета — разбор в DPI/rkn-vpn-2030-roadmap. Дальше — интерпретации сообщества (все — гипотезы, официальных заявлений на 3 июля 2026 не было):

  • Тест «зарезания» сторонних DNS. Блокировка ровно одного адреса из пары при живом втором выглядит как аккуратный эксперимент: оценить масштаб поломок (в первую очередь — сколько всего завязано на 8.8.8.8), не обрушив резолвинг всем сразу. 8.8.8.8 — самый известный и самый прописываемый в конфигах публичный DNS-адрес в мире, идеальная цель для замера эффекта.
  • Удар по шифрованному DNS как каналу обхода. DoH/DoT скрывают от оператора, какие домены запрашивает пользователь, и мешают DNS-фильтрации — мотив давить именно TCP-порты 443/853, оставив «прозрачный» UDP/53, очевиден. Продолжение линии, начатой у мобильных операторов в июне 2026 (Мегафон, см. tspu-whitelist-cloudflare-june-2026#DNS-проблемы у мобильных операторов): вынудить пользоваться DNS оператора, через который удобно фильтровать.
  • Побочный удар по VPN-инфраструктуре. Значительная часть сломавшегося — именно VPN/прокси-клиенты с DoH 8.8.8.8 в дефолтных конфигах. Даже если это не главная цель, эффект «у всех отвалился VPN, хотя туннели целы» цензору только на руку: часть пользователей решит, что «VPN больше не работает», и сдастся.

В пользу версии «тест/сырое правило» говорит и дыра с HTTP/3: правило зарезало только TCP, оставив тот же DoH к тому же адресу доступным по QUIC (UDP/443), — для «настоящей» блокировки шифрованного DNS это очевидный недосмотр. И общий контекст суток подходящий: параллельно шла ещё одна волна с быстрым откатом — блок игровых серверов EA вечером 2 июля (по версии сообщества, снова подсети Amazon; см. раздел выше). Обе волны укладываются в почерк «раскатали правило → посмотрели на эффект → откатили/оставили», знакомый по tspu-whitelist-cloudflare-june-2026.

[!note] «В чём вообще смысл, если это обходится в одну строчку?» Резонный скепсис из обсуждений: блокировка обходится тривиально — сменой на 8.8.4.4, DoH через HTTP/3, DNS внутри туннеля или DoH через CDN, — так что технически «наглухо» перекрыть шифрованный DNS этим не выйдет («борьба с ветряными мельницами»). Но у меры может быть не техническая, а статистическая и психологическая цель: (1) замерить, сколько всего в стране завязано на самый популярный DNS-адрес мира, — идеальный пробный шар; (2) отсечь массового неподготовленного пользователя, который не полезет править конфиг, а решит, что «VPN сломался». Против подготовленных это и не рассчитано — и именно поэтому одноразовая блокировка одного IP выглядит как итерация теста, а не как финальное решение. Плюс это болезненно и для самих операторов: 8.8.8.8 настолько вездесущ, что трогать его «по-крупному» рискованно — что тоже говорит в пользу осторожной точечной раскатки.

Что говорит против «случайной аварии у Google»: авария не выбирает операторов одной страны, не разделяет UDP и TCP к одному адресу и не обходит стороной 8.8.4.4, стоящий в той же инфраструктуре. Картина «TCP к одному IP зарезан у нескольких независимых операторов, всё остальное живо» — типичная для централизованного правила на ТСПУ.

📚 См. также

  • tspu-whitelist-cloudflare-june-2026 — предыдущая волна изменений на ТСПУ; там же — первые сигналы про блокировку сторонних DoH/DoT у мобильных операторов.
  • subnet-whitelist-blocking-2026 — механика ковровых блоков по диапазонам хостеров; по версии сообщества, именно она положила серверы EA 2–3 июля 2026.
  • Zapret2/symptom-not-cause — тот же принцип на примере Zapret: прежде чем чинить клиент, проверь, что изменилось на сети.
  • DPI/dpi-analysis-pipeline — где в конвейере ТСПУ живут блокировки по IP:порт и чем они отличаются от фильтров по содержимому.
  • DPI/tspu-false-blocks-june-2026 — сопутствующий ущерб других правил ТСПУ; общий контекст наращивания фильтрации в 2026.
  • Zapret/zapret_not_working — общий чек-лист диагностики «всё сломалось», включая DNS-слой.
  • DPI/rkn-vpn-2030-roadmap — стратегическая рамка: почему такие эксперименты будут повторяться до 2030 года.

[!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: исходник этой заметки · весь репозиторий.