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

220 lines
46 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
date: 2026-07-03
tags:
- dns
- doh
- dot
- quic
- tspu
- rkn
- incident
- vpn
- amazon
- troubleshooting
aliases:
- Инцидент 3 июля 2026
- Блокировка 8.8.8.8
- Google DNS заблокирован
- Отвалился DoH Google
- Перестали работать VPN 3 июля 2026
- Не работают серверы EA июль 2026
- Battlefield FIFA не подключается июль 2026
- Сбой интернета 3 июля 2026
link:
---
# 🚫 Инцидент 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](https://globalping.io/) (сервис распределённых сетевых замеров) из разных сетей 3 июля 2026: у абонентских операторов — таймаут, из дата-центра Selectel — штатный ответ сервера Google:
![[globalping-8888-3july2026.png]]
*`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 у российских операторов и так под периодическим давлением, и лазейку могут закрыть в любой момент.
![[clash-dns-prefer-h3-3july2026.png]]
*Тот самый тумблер в 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:
![[clash-dns-servers-8888-3july2026.png]]
*Типичные 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-проблемы у мобильных операторов|раздел про DNS-проблемы в инциденте 23 июня 2026]]).
### 📉 Полдень 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|инциденте 23 июня 2026]], одновременный пик у независимых регионов и сервисов указывает не на аварию у кого-то одного, а на **общее событие в сети**.
![[detector404-moscow-3july2026.png]]
*Detector404, Москва, 3 июля 2026: резкий пик жалоб около 11:00–12:30.*
![[detector404-mosobl-3july2026.png]]
*Московская область: на пике 12:05 — 102 жалобы за 15 минут при обычном фоне в 10–20.*
![[detector404-spb-3july2026.png]]
*Санкт-Петербург: тот же полуденный пик плюс отдельный всплеск около 07:00 утра.*
![[detector404-samara-3july2026.png]]
*Самарская область: полуденный пик повторяет московский по форме — волна была не региональной.*
По конкретным сервисам в тот же день (панель Detector404 на вторую половину дня 3 июля): резкий пик жалоб у **Авито** (4,1 тыс. за сутки), жалобы на **ГдеБЕНЗ**, **Суточно.ру**, провайдера **«Телеком Сервис»**; у **Electronic Arts** — статус «Сбой сети» с 807 жалобами за сутки, но лишь 10 за последний час — хвост вечерней волны 2 июля, что согласуется с сообщениями об откате правила (см. следующий раздел).
![[detector404-services-3july2026.png]]
*Панель сервисов Detector404 во второй половине дня 3 июля 2026: жалобы на разнородные, не связанные между собой сервисы — от Авито до серверов EA.*
Ещё один штрих той же волны: **облако Keenetic (Netcraze)** — сервис удалённого управления роутерами — перестало открываться и с домашнего подключения, и через мобильную связь, но **открывалось через VPN/прокси**. Раз через зарубежный туннель сервис жив, авария не на стороне облака — что-то фильтрует путь к нему из российских сетей.
> [!warning] «Пытаются заблокировать VPN, но не получается» — гипотеза, а не факт
> Ведущая в сообществе версия полуденной волны: это продолжение попыток зарезать VPN-протоколы/инфраструктуру, где под замах раз за разом попадает всё подряд — от досок объявлений до облака роутеров. Версия согласуется с почерком последних недель (ковровые блоки подсетей, быстрые откаты, см. [[tspu-whitelist-cloudflare-june-2026|23 июня]] и [[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|заметке про блок подсетей Cloudflare и Amazon]], а хроника аналогичного инцидента — в [[tspu-whitelist-cloudflare-june-2026|инциденте 23 июня 2026]].
> [!warning] Версия про Amazon не подтверждена
> Что резали именно подсети AWS, а не что-то другое, — **предположение сообщества** по косвенным признакам (характер отказа, быстрый откат, совпадение с почерком предыдущих инцидентов). Замеров конкретных заблокированных диапазонов в сообщениях не приводилось. Быстрый откат в течение суток похож на тест или ошибку конфигурации — как и с «белыми списками» 23 июня 2026.
## Диагностика: как убедиться, что дело в 8.8.8.8
- [ ] **DoH к 8.8.8.8** — должен упасть в таймаут, если вы под блоком:
```bash
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`:
```bash
curl -v --connect-timeout 5 -H 'accept: application/dns-json' 'https://8.8.4.4/resolve?name=youtube.com&type=A'
```
- [ ] **Классический DNS (UDP/53)** — работает к обоим адресам:
```bash
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):
```bash
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|разборе воронки проверок DPI]].
## Что делать
> [!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 и перезапустить клиент, затем повторить пинг-тест/открыть пару сайтов.
![[clash-dns-override-toggle-3july2026.png]]
*Тумблер «Переопределение настроек 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|Курс на 2030]]. Дальше — интерпретации сообщества (все — **гипотезы**, официальных заявлений на 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-проблемы у мобильных операторов|инцидент 23 июня]]): вынудить пользоваться 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|инциденту 23 июня 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|Инцидент 23 июня 2026: слетели «белые списки» Cloudflare]] — предыдущая волна изменений на ТСПУ; там же — первые сигналы про блокировку сторонних DoH/DoT у мобильных операторов.
- [[subnet-whitelist-blocking-2026|Блок подсетей Cloudflare и Amazon по белому списку]] — механика ковровых блоков по диапазонам хостеров; по версии сообщества, именно она положила серверы EA 2–3 июля 2026.
- [[Zapret2/symptom-not-cause|Почему «не работает» — это симптом, а не причина]] — тот же принцип на примере Zapret: прежде чем чинить клиент, проверь, что изменилось на сети.
- [[DPI/dpi-analysis-pipeline|Как DPI анализирует соединение: воронка проверок]] — где в конвейере ТСПУ живут блокировки по IP:порт и чем они отличаются от фильтров по содержимому.
- [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты (июнь 2026)]] — сопутствующий ущерб других правил ТСПУ; общий контекст наращивания фильтрации в 2026.
- [[Zapret/zapret_not_working|Что делать, если Запрет не работает]] — общий чек-лист диагностики «всё сломалось», включая DNS-слой.
- [[DPI/rkn-vpn-2030-roadmap|Курс на 2030: планы по VPN, трафику и анонимности]] — стратегическая рамка: почему такие эксперименты будут повторяться до 2030 года.
---
> [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ
> При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/DPI/google-dns-8888-block-july-2026.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main).
Reference in a new issue View git blame Copy permalink