--- date: 2026-06-23 tags: - dpi - rkn - cloudflare - whitelist - zapret - troubleshooting - incident link: aliases: - Инцидент ТСПУ 23 июня 2026 - Белые списки Cloudflare июнь 2026 - Ужесточение фильтрации Cloudflare 2026 - Что сломалось 23 июня 2026 --- # 🧱 Инцидент 23 июня 2026 (не работает Дискорд, Твич заблокировали): при обновлении ТСПУ слетели «белые списки» Cloudflare *Twitch и Discord не работают в России их заблокировали в интернете обход блокировок Запрет 2* > [!info] О чём заметка > Хроника и разбор волны изменений в блокировках Рунета **23 июня 2026**: в этот день у многих разом «поплыли» давно рабочие настройки обхода, часть ранее закрытых сайтов внезапно открылась, а часть рабочих — наоборот, отвалилась. Ниже — что именно наблюдали, какова рабочая гипотеза о причине, и **как чинить** каждый из симптомов. Сам механизм (почему ТСПУ режут облачные подсети по белому списку, а Discord и Twitch — лишь сопутствующие жертвы) вынесен в отдельную заметку [[subnet-whitelist-blocking-2026|Блок подсетей Cloudflare и Amazon по белому списку]]. Общий чек-лист диагностики «не работает» — в [[zapret_not_working|Что делать, если Запрет не работает]]; почему «Запрет сломался» — это почти всегда симптом смены DPI, а не поломки программы — в [[symptom-not-cause|Почему «не работает» — это симптом, а не причина]]. > [!warning] Статус данных: наблюдения сообщества, часть изменений откатили > Почти все факты ниже — **сообщения пользователей из разных сетей и регионов** за 23 июня 2026 (в т.ч. из [Канала для умных манулов (@nerdpapers)](https://t.me/nerdpapers/3220)), а не результат контролируемого замера. ТСПУ (Технические Средства Противодействия Угрозам — российские системы DPI) настраиваются неравномерно по операторам и регионам, поэтому у вас картина может отличаться. Главное: **часть изменений в тот же день откатили назад** — значит, это была, скорее всего, раскатка/тест новой конфигурации, а не финальное состояние. Воспринимайте заметку как снимок волатильной ситуации на конкретную дату, а не как описание устоявшегося режима блокировок. ## TL;DR - В ночь на 23 июня 2026, по версии сообщества, обновление ТСПУ прошло со сбоем: **списки исключений из «16к-блока» Cloudflare слетели** — и под ковровый блок разом попало всё, что раньше из него было выведено. - Из-за этого у многих **одновременно отвалились давно рабочие настройки** и доступ к ресурсам, которые годами открывались нормально; характерный пример — Amazon: ранее разрешённые исключения «сбросились». - Пока списки перетряхивало, картина была противоречивой: часть закрытых ранее ресурсов **временно открылась** (`fandom.com`, `di.fm`), а часть рабочих обходов — наоборот, отвалилась (отпали фейки/SNI под Cloudflare). - К моменту записи РКН **часть блоков откатили** — восстанавливают исключения, — поэтому состояние нестабильно и меняется по ходу. - Параллельно — точечные доработки по сервисам (Twitch снова режет HLS-видео) и DNS-проблемы у мобильных операторов (сторонний DoH перестал работать в ряде регионов). - Чинится по-разному и **зависит от типа блока**: сначала отличите IP-блок от DPI-блока, дальше — конкретный рецепт (см. ниже). > [!example] На пальцах: «белый список» вахтёра на проходной > Представьте проходную, где вахтёр пускает не «всех, кроме чёрного списка», а наоборот — **только тех, кто в белом списке**, а всех остальных разворачивает «ковром», не разбираясь. Так устроен «ковровый блок» на диапазонах Cloudflare: под одним IP-диапазоном живут тысячи сайтов, и ТСПУ пропускает лишь явно разрешённые, а прочие рубит «до кучи» — даже если конкретного сайта нет в чёрном списке РКН. 23 июня 2026 вахтёру **переписали белый список**: кого-то в него добавили (сайт внезапно заработал), кого-то проверять стали строже (рабочий пропуск-«фейк» перестал срабатывать). ## Что наблюдали 23 июня 2026 ### Downdetector: синхронный всплеск жалоб в ночь на 23 июня То, что сломалось не у одного сервиса, а у многих сразу, хорошо видно по агрегаторам сбоев. Жалобы на совершенно несвязанные между собой сервисы — онлайн-игру PUBG, стриминг Twitch, мессенджер Discord — **скачком выросли около 01:00 МСК 23 июня 2026** и дали второй «горб» днём. Синхронный всплеск у независимых друг от друга сервисов указывает не на аварию у каждого по отдельности, а на **общее событие в сети** — обновление ТСПУ. Пример для PUBG (за сутки — около 2.6 тыс. жалоб): ![[detector404-pubg-23june2026.png]] Графики Twitch и Discord с тем же ночным пиком — в посвящённых им разделах ниже ([[tspu-whitelist-cloudflare-june-2026#🎮 Twitch: снова не грузит видео|Twitch]], [[tspu-whitelist-cloudflare-june-2026#💬 Discord: отвалились чаты и картинки|Discord]]). ### Главное: при обновлении ТСПУ слетели списки исключений Ведущая в сообществе версия событий проще, чем «вручную переписали белый список»: обновление ТСПУ прошло **со сбоем, и списки исключений из «16к-блока» слетели целиком**. Чтобы понять, почему от этого ломается сразу всё, нужно держать в голове, как устроен ковровый блок Cloudflare. «16к-блок» работает не как чёрный список («режем вот эти сайты»), а как **белый**: на «подозрительных» диапазонах Cloudflare по умолчанию рубится **всё**, а наружу пропускают лишь то, что явно внесено в **список исключений** (allowlist). Под этим списком держится огромная масса нормально работающих ресурсов — их специально вывели из-под коврового блока, чтобы они открывались. Поэтому стоит **этому списку исчезнуть** — и ковровый блок мгновенно накрывает всех, кто им прикрывался: ресурсы, которые годами работали без всякого обхода, разом перестают открываться. Именно такую картину и описывают: массовый одновременный отказ давно рабочих вещей у разных людей и операторов, без единого «нового» запрета конкретных сайтов. Это куда лучше объясняется **сбросом исключений при кривом обновлении**, чем адресной блокировкой каждого ресурса по отдельности. Дальше РКН начал **откатывать** изменения — восстанавливать исключения, — отсюда и «часть блоков уже откатили». Пока откат идёт, состояние списков противоречиво: что-то уже вернули, что-то ещё под ковром, а что-то по ошибке оказалось разрешено шире обычного. > [!warning] Это реконструкция по симптомам, а не подтверждённый факт > Версию «обновление слетело и снесло исключения» сообщество выводит из косвенных признаков (массовость, одновременность, быстрый частичный откат), а не из официальных данных или прямого доступа к конфигурации ТСПУ. Внутреннее устройство «16к-блока» и точная причина сбоя публично не подтверждены. Поэтому относитесь к разделу как к наиболее правдоподобному объяснению на 23 июня 2026, а не как к доказанному механизму. ### Два видимых эффекта перетряски списков На поверхности сброс и последующий откат исключений выглядели как **два разнонаправленных изменения сразу**: 1. **Часть ресурсов оказалась временно разрешена шире обычного** — и открылась без всякого обхода. По сообщениям, во время перетряски списков «отпустило» `fandom.com` и `di.fm`, которые с января 2026 не открывались без Zapret из-за коврового блока на Cloudflare (правда, заработали они не полностью — связанные `audioaddict.com` и `nocookie.net` в исключения, видимо, занести забыли). На сайте Duolingo (`duolingo.com`) перестали грузиться скрипты с `d35aaqx5ub95lt.cloudfront.net`, пока этот домен **не убрали** из хостлиста заблокированных — он, похоже, оказался разрешён, и Zapret стал лишь мешать (об этом — в разделе про починку). Тем же `d35aaqx5ub95lt.cloudfront.net`, по сообщению одного из пользователей, удалось «прикрыть» доступ к твичевскому `ttvnw.net` — т.е. использовать уже разрешённый домен как фейк. 2. **Часть рабочих обходов, наоборот, отвалилась** — по сообщениям, «отвалились некоторые рабочие фейки и SNI»: стратегии, которые подсовывали поддельное имя сайта (SNI) в [[desync|дурение]], перестали проходить. На проводном **Tele2 (РТК), Москва** разом перестали работать стратегии против «16к-блока», стабильно работавшие **полгода**. Это согласуется со слетевшими исключениями: пока списки не восстановили, под ковёр попало и то, что раньше из-под него выводилось, и часть прежних настроек просто потеряла смысл. > [!note] Что такое «16к-блок» (он же ковровый блок Cloudflare) > «16к-блок» — народное название в сообществе для коврового блока на диапазонах Cloudflare, при котором соединение к «неразрешённому» ресурсу обрывается. Точный внутренний механизм и происхождение названия публично не подтверждены, поэтому здесь термин используется как ярлык наблюдаемого поведения, а не как описание устройства фильтра. Практически важно одно: под этот блок попадают сайты, которых **нет даже в чёрном списке РКН** — их рубит «за компанию», просто потому что они на «подозрительном» хостере и не попали в белый список. ### «Сброс» ранее разрешённых исключений Отдельно отмечают эффект, будто у DPI **сбросились правила для ранее разрешённых ресурсов** — в частности, для Amazon. То, что операторы вручную загоняли в исключения, из исключений пропало, и трафик снова стал фильтроваться. Это согласуется с версией про переписанный белый список: при раскатке новой конфигурации часть ручных «прощений» могла не перенестись. ### Кратковременный IP-блок CDN при раскатке В момент обновления ТСПУ ряд пользователей словил **полное пропадание пинга** до подсетей сразу нескольких CDN/хостеров: Amazon, Cloudflare, Hetzner, Melbicom, Oracle, Zenlayer. Вскоре доступность вернулась — то есть это был **временный IP-блок на время раскатки апдейта**, а не постоянное состояние. Важно не путать его с DPI-блоком: пока пинга и TCP-коннекта нет вообще, никакой Zapret не поможет (см. [[zapret_not_working#2. Тип блокировки определяет эффективность|про типы блокировок]]). Отдельные сервисы, которые пострадали заметнее всего, разобраны ниже в своих разделах: [[tspu-whitelist-cloudflare-june-2026#🎮 Twitch: снова не грузит видео|Twitch]] и [[tspu-whitelist-cloudflare-june-2026#💬 Discord: отвалились чаты и картинки|Discord]]. ### DNS-проблемы у мобильных операторов - **Оренбургская область, Мегафон** (несколько дней к 23 июня 2026): перестали работать сторонние DNS-серверы — Cloudflare, Google, AdGuard и прочие. Если выставить приватный DNS в телефоне или браузере (DNS-over-HTTPS/TLS), интернета «просто нет». То есть оператор вынуждает пользоваться своим DNS, через который удобнее фильтровать. - **Продолжение этой линии — 3 июля 2026:** у ряда операторов по всей стране заблокировали по TCP (DoH/DoT) сам адрес Google DNS **8.8.8.8** (8.8.4.4 при этом работал), из-за чего массово «отвалились» VPN-клиенты с этим резолвером в конфиге. Разбор — в [[DPI/google-dns-8888-block-july-2026|Инцидент 3 июля 2026: блокировка 8.8.8.8]]. - **Мегафон, Северо-Запад** (несколько дней): по IPv6 перестали работать «белые» (легитимные) SNI на Cloudflare; пинг до IP Cloudflare (и IPv4, и IPv6) возвращает лишь часть пакетов — похоже на частичный фильтр, а не полный блок. ### Не только Cloudflare: под ковёр попадает инфраструктура разработчиков на других хостерах Cloudflare — самый заметный, но не единственный пострадавший хостер: ковровые блоки целыми диапазонами задевают и инфраструктуру разработчиков/Linux, которой «не повезло» жить на «подозрительном» хостинге. Сами эти ресурсы нейтральны и в чёрные списки РКН по содержанию не попадают — их рубит **за компанию**, просто за диапазон хостера. По сообщениям: - **`linuxcontainers.org` (проект Incus)** — инфраструктура размещена на DigitalOcean и заблокирована «без разбора»; теперь без обхода не скачать даже образы контейнеров. - **`flathub.org`** (каталог приложений Flatpak для Linux) и **`deb.debian.org`** (зеркало репозиториев Debian) — оба живут на CDN Fastly, по ним периодически прилетает блок. Что именно служит триггером — выяснить не удалось, блок непостоянный. - **`7tv.app` / `7tv.io` / `api.7tv.app`** (эмоуты для Twitch, хостинг Hetzner) — заблокированы 3 из 4 IP (`95.217.169.88` и `95.217.169.233` полностью, на `65.109.41.220` не проходит ClientHello). По QUIC у части людей работает. Рецепт обхода (подмена IP + «белый» SNI) — в [[subnet-whitelist-blocking-2026#Что с этим делать (обход)|концептуальной заметке]]. - **`chat.deepseek.com`** — наглядный пример «кривой привязки» белого списка: РКН разрешил его, похоже, **только для старого Cloudflare**, а на актуальном Amazon — нет. Разбор — в [[subnet-whitelist-blocking-2026#Тонкость: белый список привязан к провайдеру и устаревает|концептуальной заметке]]. - Начало — примерно **конец мая 2026**. Ещё раньше, в **марте и начале апреля 2026**, периодический блок ловили на `openstreetmap.org` — он, по наблюдениям, периодически резолвится на `151.101.1.55` (Fastly), который в блоке, отсюда «то работает, то нет». > [!note] Почему «лечится как Cloudflare» работает не всегда > Для CDN с anycast-маршрутизацией (Fastly, как и Cloudflare) приём с подменой IP на чистый адрес того же CDN в принципе применим. А вот для обычного хостинга-VPS без anycast (DigitalOcean — это аренда серверов, а не CDN) подменять адрес не на что: у ресурса свой конкретный IP, и если режут именно его диапазон, помогает уже не Zapret и не правка hosts, а **туннель** (VPN/прокси). Это та же развилка «IP-блок против DPI-блока», что и в [[tspu-whitelist-cloudflare-june-2026#Как это чинить|разделе про починку]]. ### Прочее - Десктоп-клиент Spotify, по сообщению, перестал проигрывать песни без обхода — звук затыкается на 5-й секунде, при этом браузерный и Android-клиенты работали штатно. Позже сообщили, что **откатили**. - Трекеры: анонсер `bt.tracktor.in` забанили **по IP**, из-за чего на торрентах ЛостФильма обезлюдело — особенно на старых private-раздачах, где другого анонсера нет (без рабочего анонсера пиры не находят друг друга). - Утром 23 июня в Москве, по сообщениям, отвалился не только Twitch, но и доступ к `x.com` / `twimg.com` (картинки Twitter/X) — вместе с очередным отвалом стратегий против «16к-блока». Twitter/X и SoundCloud, по другим сообщениям, отваливались и раньше, ещё до этой волны. - По характеру это, как описывают, «стандартный блок на Ревизоре, как и на YouTube» — то есть штатный механизм ТСПУ (АС «Ревизор» — система мониторинга РКН, следящая за исполнением блокировок операторами), а не какая-то новая, отдельная технология. Меняется не способ блокировки, а **что** под неё попадает. ## Рабочая гипотеза о причине > [!important] Коротко: при обновлении ТСПУ слетели исключения из коврового блока, дальше — частичный откат > Складывая наблюдения, наиболее правдоподобная картина такая: в ночь на 23 июня 2026 обновление ТСПУ прошло криво и **обнулило списки исключений из «16к-блока» Cloudflare**, из-за чего ковровый блок разом накрыл массу ранее работавших ресурсов; следом РКН начал **откатывать** изменения и восстанавливать исключения. Видимые «добавили в белый список» (что-то открылось) и «ужесточили SNI» (что-то отвалилось) — это две стороны одной перетряски списков, а не отдельные осмысленные правки. Это **реконструкция по косвенным признакам**, а не подтверждённый официально факт; часть изменений в тот же день откатили. Близкий по времени разбор ужесточения DPI против TLS-обходов (VLESS+REALITY) — в [[VLESS/dpi-tls-june-2026|«Как DPI замораживает VLESS+REALITY»]]. ### Наглядный тест: два слоя блокировки на одном Cloudflare Один из пользователей продемонстрировал, что на Cloudflare работают **два разных слоя** блокировки. Тест (воспроизведение на свой риск, результат зависит от вашего ТСПУ): 1. Открыть `wiki.cavesofqud.com` (Cloudflare) **без Zapret** → ловится «16к-блок». Домена нет ни в белом, ни в чёрном списке — он закрыт **просто ковровым блоком** на диапазоне Cloudflare. 2. Запустить Zapret с обычным `multisplit` по [[ipset|ipset]] с адресами Cloudflare, а в качестве [[desync|фейка]] подсунуть имя живого разрешённого домена (в тесте — `stackoverflow.org`) → `wiki.cavesofqud.com` **открывается**. То есть ковровый слой обходится дурением. 3. Открыть `4chan.org` (тоже Cloudflare) той же стратегией из п.2 → снова «16к-блок». Причина другая: **IP «плохой»**, потому что 4chan попал в чёрный список РКН ещё до эпохи блокировок целыми автономными системами (AS), и его конкретные адреса режут адресно. 4. Подменить в [[Что такое файл hosts|hosts]] адрес `4chan.org` на IP его же nameserver'ов Cloudflare (`rita.ns.cloudflare.com`, `rick.ns.cloudflare.com`) → теперь 4chan **открывается** с той же стратегией из п.2. Вывод из теста: «ковровый» слой (за то, что ресурс на Cloudflare и не в белом списке) снимается дурением с фейком от разрешённого домена, а **адресный** слой (конкретный IP в чёрном списке) — только подменой IP на чистый адрес из того же диапазона Cloudflare. По сообщению автора теста, к моменту публикации это поведение **уже откатили**. ## Как это чинить > [!tip] Сначала определите тип блока — это решает всё > Прежде чем подбирать стратегию, отделите **IP-блок** от **DPI-блока**, иначе будете чинить не то. Проверка простая: попробуйте установить TCP-соединение к IP ресурса на 443 порт (например, `ncat -z -w 2 443`, либо просто пинг). Соединение **вообще не устанавливается** (нет ответа / RST на SYN) → это IP-блок, и Zapret здесь бессилен — нужен туннель (VPN/прокси) или подмена IP на чистый (см. ниже). Соединение **устанавливается, но страница не грузится / рвётся** → это DPI-блок по содержимому, вот тут Zapret и работает. Подробнее про различие — в [[zapret_not_working#2. Тип блокировки определяет эффективность|«Тип блокировки определяет эффективность»]]. ### 1. Ресурс внезапно заработал без Zapret → уберите его из хостлиста Если сайт после 23 июня 2026 **открывается без обхода** (его добавили в белый список), а с Zapret — наоборот ломается, значит дурение ему больше не нужно и только мешает: фейковые пакеты доходят до настоящего сервера, тот считает их мусором и рвёт связь. - [ ] Уберите домены этого ресурса из [[hostlist|хостлиста]] заблокированных (пример из инцидента: `d35aaqx5ub95lt.cloudfront.net` пришлось убрать, чтобы на Duolingo снова грузились скрипты). - [ ] Либо назначьте профилю стратегию-исключение `--lua-desync=pass` («ничего не делать, пропустить как есть») — см. [[profile#Профиль-исключение: pass|про профиль-исключение]]. Почему так — подробно в [[zapret_not_working|стандартной процедуре]]: первый шаг диагностики всегда «а работает ли без Zapret». ### 2. Ковровый «16к-блок» на Cloudflare → multisplit по ipset + фейк от разрешённого домена Для сайта, который закрыт **только ковровым блоком** (он на Cloudflare, не в белом списке, но и не в чёрном): - [ ] Включите профиль с `multisplit` по [[ipset|ipset]] с диапазонами Cloudflare (чтобы стратегия применялась ко всему трафику на адреса Cloudflare, а не к одному домену). - [ ] В параметрах [[desync|фейка]] подставьте имя **живого разрешённого** домена (в тесте сработал `stackoverflow.org`). Идея: DPI видит «хороший» SNI и пропускает соединение. Это снимает именно ковровый слой. Если после этого ресурс всё равно даёт «16к-блок» — вероятно, дело уже не в ковровом слое, а в адресном (пункт 3). ### 3. IP «плохой» (адрес в чёрном списке) → подмена IP на чистый адрес того же Cloudflare Если конкретный IP ресурса режут адресно (ресурс давно в чёрном списке РКН), стратегия не поможет — нужно сменить адрес назначения на **другой живой IP из диапазона Cloudflare**, который под адресный блок не попал. Это возможно благодаря тому, что Cloudflare — anycast-сеть: она маршрутизирует запрос к нужному сайту **по имени (SNI/Host), а не по тому, на какой именно её IP вы постучались**. Значит, можно подключиться к любому рабочему адресу Cloudflare и всё равно попасть на свой сайт. Рецепт через файл [[Что такое файл hosts|hosts]]: - [ ] Узнайте живой IP другого сайта на Cloudflare (или IP nameserver'ов нужного сайта). - [ ] Пропишите в `hosts` строку вида «чистый IP → нужный домен». Примеры из инцидента: - Rutracker: `172.66.159.63 rutracker.net` (IP, относящийся к `4pda.to`, тоже на Cloudflare), затем сбросить кеш DNS. - 4chan: подменить `4chan.org` на IP его nameserver'ов `rita.ns.cloudflare.com` / `rick.ns.cloudflare.com`. - [ ] Сбросьте кеш DNS и перезапустите браузер. > [!warning] У трюка с подменой IP есть пределы > Подмена IP внутри Cloudflare работает, **пока** блок именно адресный (режут конкретный IP), а сам диапазон Cloudflare не вырезан целиком и фильтрация не идёт **по SNI**. Если ТСПУ начнёт резать по имени сайта (`SNI=rutracker.net`) или закроет весь диапазон — приём перестанет помогать, и подмена IP уже ничего не даст. Для ресурсов с **единственным** IP на «узком» CDN (как сообщали про `linkedin.com` — другой CDN, по сути один адрес) подменять не на что, поэтому этот метод к ним неприменим. ### 4. Мобильный DNS не работает (Мегафон, Оренбург и др.) → DNS через туннель Если оператор режет сторонние DoH/DoT-резолверы (Cloudflare, Google, AdGuard) и без них «интернета нет», то проблема не в Zapret — фильтруется сам DNS: - [ ] Как временный костыль — вернуть системный/провайдерский DNS, чтобы вернуть связь. - [ ] Для приватности и обхода — пускать DNS **через туннель** (VPN/прокси), где оператор не видит и не режет запросы. Локальный обход вроде Zapret эту конкретную проблему не закрывает. ### 5. Стратегии «полгода работали и отвалились» → это сменился DPI, а не сломался Zapret Массовый отвал давно рабочих стратегий (как на Tele2 в Москве) — это не поломка программы, а **изменение DPI у провайдера**: прежний фейк/SNI стал «видимым». Лечится подбором новой стратегии профилю, а не переустановкой. Почему «не работает» — это симптом смены DPI, подробно в [[symptom-not-cause|Почему «не работает» — это симптом, а не причина]]; пошаговый подбор — в [[zapret_not_working|Что делать, если Запрет не работает]]. > [!danger] Не делайте поспешных выводов на волатильной раскатке > Когда изменения раскатывают и в тот же день частично откатывают, легко «зафиксировать» как рабочий рецепт то, что назавтра перестанет работать (или, наоборот, заработает само). Прежде чем перестраивать все настройки — проверьте, не вернулось ли всё на место само. Адресная подмена IP и фейки от чужих доменов — это **хрупкие приёмы под конкретное состояние ТСПУ**, а не стабильное решение. ## 🎮 Twitch: снова не грузит видео В ночь на 23 июня 2026 у Twitch опять сломалась загрузка видео: при просмотре стримов сыпется ошибка `CONNECTION_RESET` на HLS-фрагментах (домен раздачи видео `cloudfront.hls.ttvnw.net` / `ttvnw.net` на инфраструктуре Amazon CloudFront). По данным агрегатора сбоев, жалобы на Twitch скачком выросли около 01:00 МСК — синхронно с обновлением ТСПУ: ![[detector404-twitch-23june2026.png]] Важно: похоже, **Twitch не был целью** — его видеодомен попал под раздачу, когда блокировали облачные подсети Amazon. То есть это **сопутствующая жертва**, а не адресный запрет (механизм — в [[subnet-whitelist-blocking-2026|заметке про блок подсетей по белому списку]]). Характерная подпись: **сайт и чат работают, а плеер не грузит** — значит, дело именно в видеодомене. > [!tip] Коротко о починке (полный разбор — в отдельной заметке) > Базовое решение — **вернуть видеодомен из исключений в обрабатываемые**: удалить `ttvnw.net` из `list-exclude` и добавить его в `list-general` (или `list-general-user`), затем подобрать стратегию. История Twitch тянется ещё с конца апреля 2026 (вместе с Reddit), решений накопилось несколько и они противоречивы — всё систематизировано в отдельной заметке **[[twitch-block-2026|Блокировка Twitch в России (2026): почему не грузится плеер и как починить]]**. ## 💬 Discord: отвалились чаты и картинки Той же ночью у Discord сломались **текстовые чаты и загрузка картинок**: сообщения не отправляются и не подгружаются, изображения не открываются. На графике сбоев жалобы на Discord так же резко подскочили около 01:00 МСК 23 июня 2026 (за сутки — около 5.1 тыс. жалоб): ![[detector404-discord-23june2026.png]] > [!tip] Картинки Discord чинятся отдельным профилем > Изображения в Discord грузятся со своего CDN, и под них в пресете выделен **отдельный профиль — `discord (images)`**. Поэтому ситуация «текст ходит, а картинки не грузятся» (или наоборот) — нормальна: подбирать стратегию нужно именно профилю картинок, а не общему `discord.com`. Найдите профиль `discord (images)` на вкладке «Профили пресета» и перебирайте стратегию у него отдельно. > > ![[discord-images-profile-gui.png]] **Как чинить (порядок важен):** 1. **Сначала чините сайт `discord.com`** — приложение не починится, пока не открывается сайт. Подбирайте стратегию профилю Discord (категория Discord TCP). 2. **Картинки — отдельно**, профилю `discord (images)` (см. callout выше). 3. **Голос/звонки — это ещё один профиль** (`discord.media` / «Голосовые звонки»); вдобавок голосу часто нужна рабочая стратегия для профиля IPset Cloudflare. Подробный пошаговый разбор починки Discord (сайт → приложение → обновления → голос, с нюансами по ошибкам `Checking for updates` и `RTC`) — в [[zapret_not_working#Как починить приложение Дискорд:|разделе «Как починить Дискорд»]]. ## 🐙 GitHub: блок IP-адресов `githubusercontent.com` С середины июня 2026 (по сообщениям — «уже больше недели») ловится блок на адреса GitHub, с которых отдаются аватары, сырые файлы и вложения: `avatars.githubusercontent.com`, `raw.githubusercontent.com` и прочие `*.githubusercontent.com`. Характер блока нетипичный, и его важно правильно прочитать: - IP (например, `185.199.110.133`) **пингуется**, трассировка проходит **до конца** — маршрут до сервера есть. - А вот сами HTTPS-запросы **не проходят** — соединение не открывается / рвётся. Это поведение **IP-блока** (точнее, блока соединения к конкретному адресу), а не DPI по содержимому: рвут не по имени сайта в ClientHello, а по адресу назначения. Поэтому подобрать рабочую стратегию Zapret здесь, как правило, **не выходит** — ломать DPI нечего, до сервера просто не дают достучаться. По сообщениям, ни одна стратегия Zapret 2 пока не подошла. > [!note] Почему «пинг есть, а сайт не грузится» > Пинг (ICMP) и трассировка проверяют, что пакеты **доходят до сети назначения**, но это другой тип трафика, чем ваш HTTPS. ТСПУ может пропускать ICMP и при этом дропать или ресетить именно TCP-соединение на 443 порт к этому адресу. Поэтому «пингуется» ≠ «работает»: блок висит на уровне TCP-сессии к IP, а не на маршруте. Та же логика, что в [[tspu-whitelist-cloudflare-june-2026#Как это чинить|разделе про определение типа блока]]. **Как обойти:** - [ ] Самое простое — **исключить проблемный IP на уровне DNS**: подменить адрес в [[Что такое файл hosts|hosts]] на другой рабочий IP того же ресурса (если он есть). - [ ] Либо **пустить ресурс через VPN/прокси** — для IP-блока это самый надёжный путь. В последнее время именно это всё чаще оказывается единственным решением, кроме VPN. > [!warning] У GitHub всего ~4 IP — манёвра мало > Все домены `*.githubusercontent.com` используют **ровно 4 адреса** (диапазон вида `185.199.108–111.133`), какой DNS ни возьми. Поэтому трюк «получить незаблокированный IP через другой DNS» здесь почти не помогает — вариантов всего четыре. Он работает только для ресурсов с **множеством** IP (см. ниже). Отсюда же резонный вопрос наблюдателей: если бы скачивание с GitHub хотели заблокировать целенаправленно, проще было бы закрыть все 4 адреса разом — а блокируют выборочно, что больше похоже на ошибку автоматики, чем на осмысленный запрет. ### Почему «половина адресов работает, половина — нет» и при чём тут DNS По наблюдениям, у ряда ресурсов **часть IP заблокирована, часть — работает**, и какой именно достанется — зависит от DNS-резолвера: - На DNS от Cloudflare «нерабочий» адрес выпадает **временами**; на DNS от Google — заметно **реже**, хотя оба anycast и адреса формально одни и те же. - Рабочая гипотеза сообщества: **ТСПУ блокируют преимущественно те IP, что отдают самые популярные DNS** (Cloudflare и Google). С менее популярным DNS/DoH выше шанс получить адрес, до которого у цензора «не дошли руки» — но **только если у ресурса много IP**, а не один-два. Это **догадка по косвенным признакам**, а не подтверждённый механизм; для ресурса с 3–4 адресами (как GitHub) выигрыша почти нет, и остаётся VPN/прокси. > [!note] Возможная причина: баг в «активном пробере» РКН > Часть таких блоков выглядит как сбой автоматики, а не осмысленный запрет. Пример: серверы обновлений игры osu! блокировались **постепенно, по одному с разрывом в недели**, и отличались между собой лишь IP-адресом и цифрой в домене — всё остальное идентично. Похоже, активный сканер-пробер ТСПУ из-за давнего бага помечает **совершенно обычные** IP как «запрещённые» (так же под раздачу в своё время попадали `win-rar.ru` и многие другие нейтральные сайты). Это объясняет, почему блок ложится на безобидную инфраструктуру и выглядит хаотично. Умышленную, целенаправленную блокировку при этом исключать нельзя — но как основное объяснение такой хаотичности она **маловероятна**: баг автоматики проще и лучше укладывается в картину. ### Последствия для инструментов разработчиков Блок раздачи с GitHub бьёт по программам, которые тянут оттуда обновления и данные, и экосистема под это подстраивается: - В панели **x-ui** (управление Xray) добавили возможность обновляться с GitHub через **свой локальный HTTP/SOCKS5-прокси**, а саму кнопку обновления сделали графической вместо консольной команды. - Отдельные администраторы раздают зависимостям обходные данные сами: например, с 8 мая 2026 один из пользователей ежедневно раздаёт **геобазы** (`geoip`/`geosite` для маршрутизации) на все российские серверы со своего сервера за рубежом, чтобы не зависеть от прямого доступа к GitHub. > [!quote] Наблюдение: бьёт по «своим», а не по цели > Закономерность, которую отмечают: чтобы просто работать (скачать образ, обновить инструмент, подтянуть зависимость), обычным разработчикам и пользователям теперь приходится **обходить блокировки**, — тогда как тем, против кого ограничения в теории направлены, обойти их куда проще, и часть из них ограничений даже не заметит. ## 📚 См. также - [[subnet-whitelist-blocking-2026|Блок подсетей Cloudflare и Amazon по белому списку]] — механизм: почему режут облака, а Discord и Twitch — жертвы по касательной - [[twitch-block-2026|Блокировка Twitch в России (2026)]] — почему не грузится плеер и как починить (история с апреля 2026) - [[zapret_not_working|Что делать, если Запрет не работает]] — общий чек-лист и стандартная процедура диагностики «не работает» - [[symptom-not-cause|Почему «не работает» — это симптом, а не причина]] — почему смена DPI ≠ поломка программы - [[desync|Техники дурения]] — механика `--lua-desync`: split, disorder, fake, смысл смещений (`sniext`, `midsld`, `endhost`) - [[ipset|Что такое ipset]] — как применять стратегию ко всему диапазону Cloudflare, а не к одному домену - [[Что такое файл hosts|Что такое файл hosts]] — подмена IP и разблокировка через hosts - [[hostlist|Хостлисты]] — какие домены отдавать на дурение, а какие убрать - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY (июнь 2026)]] — близкое по времени ужесточение DPI против TLS-обходов - [[DPI/google-dns-8888-block-july-2026|Инцидент 3 июля 2026: блокировка 8.8.8.8]] — следующая волна: блок Google DNS по TCP (DoH/DoT) и массовый «отвал» VPN-клиентов --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Zapret/tspu-whitelist-cloudflare-june-2026.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main).