Zapret Wiki

Недавно обновлено

время чтения ~10 мин.

.md

🕸️ Блок подсетей Cloudflare и Amazon по белому списку: почему Discord и Twitch — сопутствующие жертвы

О чём заметка

Разбор механизма, при котором ТСПУ (Технические Средства Противодействия Угрозам — российские системы DPI) блокируют не конкретный сервис, а целые подсети облачных провайдеров (Cloudflare, Amazon/AWS и др.), пропуская наружу лишь то, что внесено в белый список. Из-за этого «умирают» популярные сервисы вроде Discord или Twitch — но не потому, что их выбрали целью, а потому что они физически размещены на задетых облаках и попали под раздачу. Конкретная хроника, как это проявилось 23 июня 2026, — в отдельной заметке Инцидент 23 июня 2026. Это другой «белый список», чем в белых списках на мобильных сетях — про различие см. раздел в конце.

Статус: реконструкция по наблюдениям сообщества

Описанный механизм собран из публичных наблюдений и обсуждений (в т.ч. в Telegram-канале «Канал для умных манулов» (@nerdpapers)) и из поведения блокировок, а не из официальных данных или прямого доступа к конфигурации ТСПУ. Внутреннее устройство фильтров публично не подтверждено, оборудование настраивается неравномерно по операторам и регионам. Поэтому относитесь к тексту как к наиболее правдоподобному объяснению, а не как к доказанному факту; отдельные детали со временем меняются.

TL;DR

  • Цель блока — облачные подсети (Cloudflare, Amazon/AWS), а не сами Discord, Twitch, YouTube. Сервисы ломаются «по касательной», потому что хостятся на этих облаках.
  • Сменилась модель фильтрации: с «серых списков» (резали только заведомо плохое или то, чего нет в известных подсетях) на «белые списки» — теперь рубится всё, чего нет в списке разрешённого. Для оборудования так проще и «надёжнее» с точки зрения цензора.
  • Cloudflare задели, возможно, в попытке мешать VPN-сервисам на его инфраструктуре (например, WARP) — но это слабая гипотеза; зачем так держатся за Amazon/CloudFront, непонятно, он даже не использовался в фейках.
  • Обход смещается в сторону «вернуть домен под дурение / подменить IP на незаблокированный / уйти в VPN», а не «подобрать хитрый сплит»: против блока целой подсети чистый DPI-десинк помогает не всегда.
  • Конкретное рабочее решение для видео Twitch (см. ниже) — пример того, что «лечится» это часто простым возвращением домена сервиса в обрабатываемые списки.

Главная мысль: цель — облако, а не сервис

Когда «падает Discord» или «не грузится Twitch», интуитивно кажется, что заблокировали именно их. По наблюдениям, картина обратная: блокируют диапазоны IP облачных провайдеров, на которых эти сервисы живут, — а сервис просто оказывается внутри задетого диапазона.

На пальцах: перекрыли не магазин, а весь торговый центр

Представьте, что нужный вам магазин закрылся. Вы думаете «закрыли магазин» — а на деле перекрыли весь торговый центр, в котором он арендует угол, потому что в этом ТЦ замечен кто-то «неблагонадёжный». Магазин ни при чём, но войти в него нельзя, пока он там. Так и Discord/Twitch: их «угол» — в облаке Cloudflare или Amazon, и когда перекрывают облако, перекрывается и они.

Из этого следует важное: «поломка» Discord-видео или Twitch — не признак, что взялись именно за них. По сообщениям профильных ресурсов, в бан шли все подсети, в том числе Cloudflare, Amazon и другие крупные; затронутая часть Discord (видео/медиа) попала под раздачу именно потому, что хостится на задетом облаке.

От «серых списков» к «белым»: что изменилось

Ключевое изменение — в логике фильтра, и его стоит понять отдельно.

  • Раньше — «серый список». Блокировалось выборочно: либо заведомо запрещённые ресурсы, либо то, что не относилось к известным «нормальным» подсетям. Всё остальное по умолчанию пропускалось.
  • Теперь — «белый список». На «подозрительных» облачных диапазонах по умолчанию рубится всё, и наружу пропускается только то, что явно разрешено (внесено в белый список), — конкретные сайты или их «фейки» (поддельные SNI, которыми притворяется обходной трафик).

Почему цензору это выгодно

Модель «блокируй всё, кроме разрешённого» проще для оборудования и надёжнее закрывает нежелательное: не нужно вести и постоянно обновлять огромный чёрный список — достаточно держать сравнительно короткий белый. Поэтому переход к белым спискам выглядит логичным шагом, а не случайностью. Обратная сторона — массовый сопутствующий ущерб: любой ресурс на том же облаке, не попавший в белый список, перестаёт открываться.

Этот же механизм объясняет, почему во время сбоев на 23 июня 2026 одни ресурсы внезапно открывались, а другие отваливались: перетряхивали именно списки исключений/разрешений для облачных подсетей. Подробная хроника — в инциденте 23 июня 2026.

Почему именно Cloudflare и Amazon (и при чём тут WARP)

  • Cloudflare — на его инфраструктуре работает множество обходных и VPN-сервисов, в том числе WARP (VPN от Cloudflare). Одна из версий: подсети Cloudflare давят, пытаясь мешать WARP и подобным туннелям. Сами авторы наблюдений считают это маловероятным основным мотивом — слишком велик сопутствующий ущерб, — но как один из факторов не исключают.
  • Amazon / CloudFront — здесь мотив ещё менее понятен: по наблюдениям, эти подсети «нигде толком не использовались» в обходных фейках, и зачем за них так держатся — неясно. Тем не менее под блок они тоже попали, и вместе с ними — сервисы на AWS/CloudFront (например, видеоинфраструктура Twitch).

Почему результат «плавающий»: замедление по IP и роль DNS

У части ресурсов одни IP заблокированы/замедлены, другие — работают, и какой достанется, зависит от DNS-резолвера (подробно — в разделе про DNS в инциденте). Практический вывод тот же: иногда достаточно перенаправить домен на другой, незамедленный IP того же провайдера — и ресурс начинает работать, хотя домен и стратегия не менялись.

Тонкость: белый список привязан к провайдеру и устаревает

Белый список — это не просто «домен разрешён», а связка домен + конкретные IP/подсеть провайдера. Если сервис переезжает с одного облака на другое, старая запись указывает на прежнего провайдера и перестаёт совпадать с реальностью: домен оказывается «разрешён там, где его уже нет, и заблокирован там, где он теперь живёт».

DeepSeek: разрешён для старого Cloudflare, заблокирован для актуального Amazon

По наблюдениям, chat.deepseek.com ведёт себя ровно так. Если вручную привязать его к старым IP Cloudflare, на которых он сидел раньше, — RST не прилетает, разрыва нет, но сайт всё равно не отдаётся: приходит ошибка Cloudflare (сервиса там уже нет). А на актуальном Amazon, где DeepSeek живёт сейчас, он заблокирован. Вывод наблюдателей: РКН разрешил chat.deepseek.com, но по устаревшей информации — только для Cloudflare, а для нового Amazon разрешение не выписали. Это «кривая привязка»: белый список не поспел за переездом сервиса между облаками.

Тот же корень и у эффекта «ручные исключения пропали»: всё, что операторы заносили в разрешённое вручную, при перетряске списков слетело или перестало совпадать с актуальными адресами провайдеров.

Как это бьёт по конкретным сервисам

  • Discord — отвалились текстовые чаты и картинки (медиа-инфраструктура на задетых облаках). Что чинить и в каком порядке — в разделе про Discord.
  • Twitch — CONNECTION_RESET на видео; пострадал HLS-домен раздачи видео cloudfront.hls.ttvnw.net (CloudFront/AWS). Характерная деталь: проверочные сайты вроде twitch-check.rte.net.ru могут показывать «всё работает», потому что проверяют основной домен, а сломана именно отдельная видеоподсеть. Решение и полная история — в отдельной заметке про Twitch (и кратко ниже).
  • YouTube — по сообщениям, тоже лихорадило в те же часы; механика та же (облачные подсети + троттлинг).
  • OpenStreetMap — openstreetmap.org периодически резолвится на 151.101.1.55 (Fastly), который в блоке; отсюда «то работает, то нет». Тянется ещё с марта — начала апреля 2026.
  • 7TV (эмоуты для Twitch: 7tv.app, 7tv.io, api.7tv.app; хостинг Hetzner) — заблокированы 3 из 4 IP: 95.217.169.88 и 95.217.169.233 полностью, а на 65.109.41.220 не проходит ClientHello (рабочий «белый» SNI подобрать не удалось). У части пользователей 7tv.app при этом работает по QUIC — проверьте, покрывает ли ваша стратегия QUIC. Похоже на триггерный «16к-блок» (срабатывает на соединение). Рецепт обхода — ниже.

Что с этим делать (обход)

Поскольку режется подсеть/адрес, а не имя сайта, упор смещается с «подобрать сплит» на три приёма:

  1. Вернуть домен сервиса под обработку (в «общий» список), убрав его из исключений. Если домен раньше был в списке-исключении (его не трогали, считая «и так разрешённым»), а теперь разрешение слетело — его нужно вернуть в обрабатываемые, чтобы Zapret снова применял к нему дурение (фейк с «хорошим» SNI и т.п.).
  2. Подменить IP на незаблокированный/незамедленный адрес того же провайдера через hosts — работает, если у ресурса много адресов и не вся подсеть закрыта.
  3. Уйти в VPN/прокси — самый надёжный путь, когда режут именно IP/подсеть и манёвра с адресами нет.

Подробные пошаговые рецепты под каждый случай — в разделе «Как это чинить» инцидентной заметки.

Рабочий рецепт для 7TV (по сообщениям)

Совмещение приёмов 2 и 1 — подмена IP на чистый адрес Hetzner плюс «белый» SNI. В hosts прописать 95.217.175.63 7tv.app, плюс стратегия Zapret 1:

--dpi-desync=fake --dpi-desync-fake-tls-mod=sni=gitlab.archlinux.org --dpi-desync-fooling=ts

Здесь sni=gitlab.archlinux.org — «хороший» разрешённый SNI, которым притворяется ClientHello, а fooling=ts — подделка timestamp в пакете-обманке. Помогает не у всех (зависит от того, какой IP/SNI у вас «чистый»), но показывает логику: дать незаблокированный адрес и притвориться разрешённым именем.

Рабочее решение для видео Twitch (по сообщениям)

Для сборок на основе хостлистов (Flowseal zapret-discord-youtube): удалить ttvnw.net из list-exclude и добавить cloudfront.hls.ttvnw.net в list-general (или list-general-user). Смысл — вернуть видеодомен Twitch из «исключённых» в «обрабатываемые», чтобы к нему снова применялась стратегия. Помогает не на всех стратегиях (у автора решения заработало на ALT11). Полный разбор всех решений (история с апреля 2026, противоречивые рецепты, подбор стратегии) — в отдельной заметке Блокировка Twitch в России (2026). Источник: issue Flowseal/zapret-discord-youtube #15298 и Канал для умных манулов.

То, что сервис «лечится простым добавлением домена», и подтверждает главный тезис: его не блокировали адресно — он просто выпал из белого списка вместе с облаком.

Наблюдение: бьёт по «своим»

Закономерность, которую отмечают: чтобы просто пользоваться нейтральными сервисами, обычным людям теперь приходится обходить блокировки, — тогда как те, против кого ограничения в теории направлены, обходят их без труда, а часть из них перемен даже не замечает.

Не путать с другими «белыми списками»

Слово «белый список» в теме блокировок встречается в трёх разных смыслах — их легко перепутать:

  1. Белый список подсетей облаков (эта заметка). ТСПУ режут диапазоны Cloudflare/Amazon и пропускают только разрешённое; сервисы-жертвы — по касательной.
  2. Белые списки на мобильных сетях — когда оператор при ограничении мобильного интернета (например, в период веерных шатдаунов) оставляет доступными лишь отдельные «социально значимые» сервисы. Это про мобильный доступ и другой контекст — см. Белые списки и whitelist-unlock у Билайна.
  3. Конкретный инцидент 23 июня 2026 — разовая волна сбоев, когда списки исключений для облаков «слетели» и их откатывали: Инцидент 23 июня 2026.

📚 См. также

🤖 Эти статьи открыты — можно обучать на них ИИ

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

Вид графа

Обратные ссылки