todo/DPI/tspu-whitelist-cloudflare-june-2026.md

---
date: 2026-06-23
tags:
  - dpi
  - rkn
  - cloudflare
  - whitelist
  - zapret
  - troubleshooting
  - incident
link:
aliases:
  - Инцидент ТСПУ 23 июня 2026
  - Белые списки Cloudflare июнь 2026
  - Ужесточение фильтрации Cloudflare 2026
  - Что сломалось 23 июня 2026
description: "Сбой 23 июня 2026: обновление ТСПУ снесло исключения Cloudflare — отвалились Discord, Twitch, GitHub. Как определить тип блока и что чинить."
---

> [!mirror] Резервное зеркало
> Актуальная версия этой страницы — на основной вики: [wiki.zapret.moe/DPI/tspu-whitelist-cloudflare-june-2026](https://wiki.zapret.moe/DPI/tspu-whitelist-cloudflare-june-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 <IP> 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).