# 🚫 Инцидент 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-архивом доступны на GitHub: [исходник этой заметки](https://github.com/youtubediscord/todo/blob/main/DPI/google-dns-8888-block-july-2026.md) · [весь репозиторий](https://github.com/youtubediscord/todo/tree/main).