Zapret Wiki

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

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

.md

🧱 Инцидент 23 июня 2026 (не работает Дискорд, Твич заблокировали): при обновлении ТСПУ слетели «белые списки» Cloudflare

Twitch и Discord не работают в России их заблокировали в интернете обход блокировок Запрет 2

О чём заметка

Хроника и разбор волны изменений в блокировках Рунета 23 июня 2026: в этот день у многих разом «поплыли» давно рабочие настройки обхода, часть ранее закрытых сайтов внезапно открылась, а часть рабочих — наоборот, отвалилась. Ниже — что именно наблюдали, какова рабочая гипотеза о причине, и как чинить каждый из симптомов. Сам механизм (почему ТСПУ режут облачные подсети по белому списку, а Discord и Twitch — лишь сопутствующие жертвы) вынесен в отдельную заметку Блок подсетей Cloudflare и Amazon по белому списку. Общий чек-лист диагностики «не работает» — в Что делать, если Запрет не работает; почему «Запрет сломался» — это почти всегда симптом смены DPI, а не поломки программы — в Почему «не работает» — это симптом, а не причина.

Статус данных: наблюдения сообщества, часть изменений откатили

Почти все факты ниже — сообщения пользователей из разных сетей и регионов за 23 июня 2026 (в т.ч. из Канала для умных манулов (@nerdpapers)), а не результат контролируемого замера. ТСПУ (Технические Средства Противодействия Угрозам — российские системы DPI) настраиваются неравномерно по операторам и регионам, поэтому у вас картина может отличаться. Главное: часть изменений в тот же день откатили назад — значит, это была, скорее всего, раскатка/тест новой конфигурации, а не финальное состояние. Воспринимайте заметку как снимок волатильной ситуации на конкретную дату, а не как описание устоявшегося режима блокировок.

TL;DR

  • В ночь на 23 июня 2026, по версии сообщества, обновление ТСПУ прошло со сбоем: списки исключений из «16к-блока» Cloudflare слетели — и под ковровый блок разом попало всё, что раньше из него было выведено.
  • Из-за этого у многих одновременно отвалились давно рабочие настройки и доступ к ресурсам, которые годами открывались нормально; характерный пример — Amazon: ранее разрешённые исключения «сбросились».
  • Пока списки перетряхивало, картина была противоречивой: часть закрытых ранее ресурсов временно открылась (fandom.com, di.fm), а часть рабочих обходов — наоборот, отвалилась (отпали фейки/SNI под Cloudflare).
  • К моменту записи РКН часть блоков откатили — восстанавливают исключения, — поэтому состояние нестабильно и меняется по ходу.
  • Параллельно — точечные доработки по сервисам (Twitch снова режет HLS-видео) и DNS-проблемы у мобильных операторов (сторонний DoH перестал работать в ряде регионов).
  • Чинится по-разному и зависит от типа блока: сначала отличите IP-блок от DPI-блока, дальше — конкретный рецепт (см. ниже).

На пальцах: «белый список» вахтёра на проходной

Представьте проходную, где вахтёр пускает не «всех, кроме чёрного списка», а наоборот — только тех, кто в белом списке, а всех остальных разворачивает «ковром», не разбираясь. Так устроен «ковровый блок» на диапазонах Cloudflare: под одним IP-диапазоном живут тысячи сайтов, и ТСПУ пропускает лишь явно разрешённые, а прочие рубит «до кучи» — даже если конкретного сайта нет в чёрном списке РКН. 23 июня 2026 вахтёру переписали белый список: кого-то в него добавили (сайт внезапно заработал), кого-то проверять стали строже (рабочий пропуск-«фейк» перестал срабатывать).

Что наблюдали 23 июня 2026

Downdetector: синхронный всплеск жалоб в ночь на 23 июня

То, что сломалось не у одного сервиса, а у многих сразу, хорошо видно по агрегаторам сбоев. Жалобы на совершенно несвязанные между собой сервисы — онлайн-игру PUBG, стриминг Twitch, мессенджер Discord — скачком выросли около 01:00 МСК 23 июня 2026 и дали второй «горб» днём. Синхронный всплеск у независимых друг от друга сервисов указывает не на аварию у каждого по отдельности, а на общее событие в сети — обновление ТСПУ. Пример для PUBG (за сутки — около 2.6 тыс. жалоб):

Графики Twitch и Discord с тем же ночным пиком — в посвящённых им разделах ниже (Twitch, Discord).

Главное: при обновлении ТСПУ слетели списки исключений

Ведущая в сообществе версия событий проще, чем «вручную переписали белый список»: обновление ТСПУ прошло со сбоем, и списки исключений из «16к-блока» слетели целиком. Чтобы понять, почему от этого ломается сразу всё, нужно держать в голове, как устроен ковровый блок Cloudflare.

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

Именно такую картину и описывают: массовый одновременный отказ давно рабочих вещей у разных людей и операторов, без единого «нового» запрета конкретных сайтов. Это куда лучше объясняется сбросом исключений при кривом обновлении, чем адресной блокировкой каждого ресурса по отдельности. Дальше РКН начал откатывать изменения — восстанавливать исключения, — отсюда и «часть блоков уже откатили». Пока откат идёт, состояние списков противоречиво: что-то уже вернули, что-то ещё под ковром, а что-то по ошибке оказалось разрешено шире обычного.

Это реконструкция по симптомам, а не подтверждённый факт

Версию «обновление слетело и снесло исключения» сообщество выводит из косвенных признаков (массовость, одновременность, быстрый частичный откат), а не из официальных данных или прямого доступа к конфигурации ТСПУ. Внутреннее устройство «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) в дурение, перестали проходить. На проводном Tele2 (РТК), Москва разом перестали работать стратегии против «16к-блока», стабильно работавшие полгода. Это согласуется со слетевшими исключениями: пока списки не восстановили, под ковёр попало и то, что раньше из-под него выводилось, и часть прежних настроек просто потеряла смысл.

Что такое «16к-блок» (он же ковровый блок Cloudflare)

«16к-блок» — народное название в сообществе для коврового блока на диапазонах Cloudflare, при котором соединение к «неразрешённому» ресурсу обрывается. Точный внутренний механизм и происхождение названия публично не подтверждены, поэтому здесь термин используется как ярлык наблюдаемого поведения, а не как описание устройства фильтра. Практически важно одно: под этот блок попадают сайты, которых нет даже в чёрном списке РКН — их рубит «за компанию», просто потому что они на «подозрительном» хостере и не попали в белый список.

«Сброс» ранее разрешённых исключений

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

Кратковременный IP-блок CDN при раскатке

В момент обновления ТСПУ ряд пользователей словил полное пропадание пинга до подсетей сразу нескольких CDN/хостеров: Amazon, Cloudflare, Hetzner, Melbicom, Oracle, Zenlayer. Вскоре доступность вернулась — то есть это был временный IP-блок на время раскатки апдейта, а не постоянное состояние. Важно не путать его с DPI-блоком: пока пинга и TCP-коннекта нет вообще, никакой Zapret не поможет (см. про типы блокировок).

Отдельные сервисы, которые пострадали заметнее всего, разобраны ниже в своих разделах: Twitch и 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-клиенты с этим резолвером в конфиге. Разбор — в Инцидент 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) — в концептуальной заметке.
  • chat.deepseek.com — наглядный пример «кривой привязки» белого списка: РКН разрешил его, похоже, только для старого Cloudflare, а на актуальном Amazon — нет. Разбор — в концептуальной заметке.
  • Начало — примерно конец мая 2026. Ещё раньше, в марте и начале апреля 2026, периодический блок ловили на openstreetmap.org — он, по наблюдениям, периодически резолвится на 151.101.1.55 (Fastly), который в блоке, отсюда «то работает, то нет».

Почему «лечится как Cloudflare» работает не всегда

Для CDN с anycast-маршрутизацией (Fastly, как и Cloudflare) приём с подменой IP на чистый адрес того же CDN в принципе применим. А вот для обычного хостинга-VPS без anycast (DigitalOcean — это аренда серверов, а не CDN) подменять адрес не на что: у ресурса свой конкретный IP, и если режут именно его диапазон, помогает уже не Zapret и не правка hosts, а туннель (VPN/прокси). Это та же развилка «IP-блок против DPI-блока», что и в разделе про починку.

Прочее

  • Десктоп-клиент Spotify, по сообщению, перестал проигрывать песни без обхода — звук затыкается на 5-й секунде, при этом браузерный и Android-клиенты работали штатно. Позже сообщили, что откатили.
  • Трекеры: анонсер bt.tracktor.in забанили по IP, из-за чего на торрентах ЛостФильма обезлюдело — особенно на старых private-раздачах, где другого анонсера нет (без рабочего анонсера пиры не находят друг друга).
  • Утром 23 июня в Москве, по сообщениям, отвалился не только Twitch, но и доступ к x.com / twimg.com (картинки Twitter/X) — вместе с очередным отвалом стратегий против «16к-блока». Twitter/X и SoundCloud, по другим сообщениям, отваливались и раньше, ещё до этой волны.
  • По характеру это, как описывают, «стандартный блок на Ревизоре, как и на YouTube» — то есть штатный механизм ТСПУ (АС «Ревизор» — система мониторинга РКН, следящая за исполнением блокировок операторами), а не какая-то новая, отдельная технология. Меняется не способ блокировки, а что под неё попадает.

Рабочая гипотеза о причине

Коротко: при обновлении ТСПУ слетели исключения из коврового блока, дальше — частичный откат

Складывая наблюдения, наиболее правдоподобная картина такая: в ночь на 23 июня 2026 обновление ТСПУ прошло криво и обнулило списки исключений из «16к-блока» Cloudflare, из-за чего ковровый блок разом накрыл массу ранее работавших ресурсов; следом РКН начал откатывать изменения и восстанавливать исключения. Видимые «добавили в белый список» (что-то открылось) и «ужесточили SNI» (что-то отвалилось) — это две стороны одной перетряски списков, а не отдельные осмысленные правки. Это реконструкция по косвенным признакам, а не подтверждённый официально факт; часть изменений в тот же день откатили. Близкий по времени разбор ужесточения DPI против TLS-обходов (VLESS+REALITY) — в «Как DPI замораживает VLESS+REALITY».

Наглядный тест: два слоя блокировки на одном Cloudflare

Один из пользователей продемонстрировал, что на Cloudflare работают два разных слоя блокировки. Тест (воспроизведение на свой риск, результат зависит от вашего ТСПУ):

  1. Открыть wiki.cavesofqud.com (Cloudflare) без Zapret → ловится «16к-блок». Домена нет ни в белом, ни в чёрном списке — он закрыт просто ковровым блоком на диапазоне Cloudflare.
  2. Запустить Zapret с обычным multisplit по ipset с адресами Cloudflare, а в качестве фейка подсунуть имя живого разрешённого домена (в тесте — stackoverflow.org) → wiki.cavesofqud.com открывается. То есть ковровый слой обходится дурением.
  3. Открыть 4chan.org (тоже Cloudflare) той же стратегией из п.2 → снова «16к-блок». Причина другая: IP «плохой», потому что 4chan попал в чёрный список РКН ещё до эпохи блокировок целыми автономными системами (AS), и его конкретные адреса режут адресно.
  4. Подменить в hosts адрес 4chan.org на IP его же nameserver’ов Cloudflare (rita.ns.cloudflare.com, rick.ns.cloudflare.com) → теперь 4chan открывается с той же стратегией из п.2.

Вывод из теста: «ковровый» слой (за то, что ресурс на Cloudflare и не в белом списке) снимается дурением с фейком от разрешённого домена, а адресный слой (конкретный IP в чёрном списке) — только подменой IP на чистый адрес из того же диапазона Cloudflare. По сообщению автора теста, к моменту публикации это поведение уже откатили.

Как это чинить

Сначала определите тип блока — это решает всё

Прежде чем подбирать стратегию, отделите IP-блок от DPI-блока, иначе будете чинить не то. Проверка простая: попробуйте установить TCP-соединение к IP ресурса на 443 порт (например, ncat -z -w 2 <IP> 443, либо просто пинг). Соединение вообще не устанавливается (нет ответа / RST на SYN) → это IP-блок, и Zapret здесь бессилен — нужен туннель (VPN/прокси) или подмена IP на чистый (см. ниже). Соединение устанавливается, но страница не грузится / рвётся → это DPI-блок по содержимому, вот тут Zapret и работает. Подробнее про различие — в «Тип блокировки определяет эффективность».

1. Ресурс внезапно заработал без Zapret → уберите его из хостлиста

Если сайт после 23 июня 2026 открывается без обхода (его добавили в белый список), а с Zapret — наоборот ломается, значит дурение ему больше не нужно и только мешает: фейковые пакеты доходят до настоящего сервера, тот считает их мусором и рвёт связь.

  • Уберите домены этого ресурса из хостлиста заблокированных (пример из инцидента: d35aaqx5ub95lt.cloudfront.net пришлось убрать, чтобы на Duolingo снова грузились скрипты).
  • Либо назначьте профилю стратегию-исключение --lua-desync=pass («ничего не делать, пропустить как есть») — см. про профиль-исключение.

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

2. Ковровый «16к-блок» на Cloudflare → multisplit по ipset + фейк от разрешённого домена

Для сайта, который закрыт только ковровым блоком (он на Cloudflare, не в белом списке, но и не в чёрном):

  • Включите профиль с multisplit по ipset с диапазонами Cloudflare (чтобы стратегия применялась ко всему трафику на адреса Cloudflare, а не к одному домену).
  • В параметрах фейка подставьте имя живого разрешённого домена (в тесте сработал stackoverflow.org). Идея: DPI видит «хороший» SNI и пропускает соединение.

Это снимает именно ковровый слой. Если после этого ресурс всё равно даёт «16к-блок» — вероятно, дело уже не в ковровом слое, а в адресном (пункт 3).

3. IP «плохой» (адрес в чёрном списке) → подмена IP на чистый адрес того же Cloudflare

Если конкретный IP ресурса режут адресно (ресурс давно в чёрном списке РКН), стратегия не поможет — нужно сменить адрес назначения на другой живой IP из диапазона Cloudflare, который под адресный блок не попал. Это возможно благодаря тому, что Cloudflare — anycast-сеть: она маршрутизирует запрос к нужному сайту по имени (SNI/Host), а не по тому, на какой именно её IP вы постучались. Значит, можно подключиться к любому рабочему адресу Cloudflare и всё равно попасть на свой сайт.

Рецепт через файл 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 и перезапустите браузер.

У трюка с подменой 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, подробно в Почему «не работает» — это симптом, а не причина; пошаговый подбор — в Что делать, если Запрет не работает.

Не делайте поспешных выводов на волатильной раскатке

Когда изменения раскатывают и в тот же день частично откатывают, легко «зафиксировать» как рабочий рецепт то, что назавтра перестанет работать (или, наоборот, заработает само). Прежде чем перестраивать все настройки — проверьте, не вернулось ли всё на место само. Адресная подмена IP и фейки от чужих доменов — это хрупкие приёмы под конкретное состояние ТСПУ, а не стабильное решение.

🎮 Twitch: снова не грузит видео

В ночь на 23 июня 2026 у Twitch опять сломалась загрузка видео: при просмотре стримов сыпется ошибка CONNECTION_RESET на HLS-фрагментах (домен раздачи видео cloudfront.hls.ttvnw.net / ttvnw.net на инфраструктуре Amazon CloudFront). По данным агрегатора сбоев, жалобы на Twitch скачком выросли около 01:00 МСК — синхронно с обновлением ТСПУ:

Важно: похоже, Twitch не был целью — его видеодомен попал под раздачу, когда блокировали облачные подсети Amazon. То есть это сопутствующая жертва, а не адресный запрет (механизм — в заметке про блок подсетей по белому списку). Характерная подпись: сайт и чат работают, а плеер не грузит — значит, дело именно в видеодомене.

Коротко о починке (полный разбор — в отдельной заметке)

Базовое решение — вернуть видеодомен из исключений в обрабатываемые: удалить ttvnw.net из list-exclude и добавить его в list-general (или list-general-user), затем подобрать стратегию. История Twitch тянется ещё с конца апреля 2026 (вместе с Reddit), решений накопилось несколько и они противоречивы — всё систематизировано в отдельной заметке Блокировка Twitch в России (2026): почему не грузится плеер и как починить.

💬 Discord: отвалились чаты и картинки

Той же ночью у Discord сломались текстовые чаты и загрузка картинок: сообщения не отправляются и не подгружаются, изображения не открываются. На графике сбоев жалобы на Discord так же резко подскочили около 01:00 МСК 23 июня 2026 (за сутки — около 5.1 тыс. жалоб):

Картинки Discord чинятся отдельным профилем

Изображения в Discord грузятся со своего CDN, и под них в пресете выделен отдельный профиль — discord (images). Поэтому ситуация «текст ходит, а картинки не грузятся» (или наоборот) — нормальна: подбирать стратегию нужно именно профилю картинок, а не общему discord.com. Найдите профиль discord (images) на вкладке «Профили пресета» и перебирайте стратегию у него отдельно.

Как чинить (порядок важен):

  1. Сначала чините сайт discord.com — приложение не починится, пока не открывается сайт. Подбирайте стратегию профилю Discord (категория Discord TCP).
  2. Картинки — отдельно, профилю discord (images) (см. callout выше).
  3. Голос/звонки — это ещё один профиль (discord.media / «Голосовые звонки»); вдобавок голосу часто нужна рабочая стратегия для профиля IPset Cloudflare.

Подробный пошаговый разбор починки Discord (сайт → приложение → обновления → голос, с нюансами по ошибкам Checking for updates и RTC) — в разделе «Как починить Дискорд».

🐙 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 пока не подошла.

Почему «пинг есть, а сайт не грузится»

Пинг (ICMP) и трассировка проверяют, что пакеты доходят до сети назначения, но это другой тип трафика, чем ваш HTTPS. ТСПУ может пропускать ICMP и при этом дропать или ресетить именно TCP-соединение на 443 порт к этому адресу. Поэтому «пингуется» ≠ «работает»: блок висит на уровне TCP-сессии к IP, а не на маршруте. Та же логика, что в разделе про определение типа блока.

Как обойти:

  • Самое простое — исключить проблемный IP на уровне DNS: подменить адрес в hosts на другой рабочий IP того же ресурса (если он есть).
  • Либо пустить ресурс через VPN/прокси — для IP-блока это самый надёжный путь. В последнее время именно это всё чаще оказывается единственным решением, кроме VPN.

У 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/прокси.

Возможная причина: баг в «активном пробере» РКН

Часть таких блоков выглядит как сбой автоматики, а не осмысленный запрет. Пример: серверы обновлений игры osu! блокировались постепенно, по одному с разрывом в недели, и отличались между собой лишь IP-адресом и цифрой в домене — всё остальное идентично. Похоже, активный сканер-пробер ТСПУ из-за давнего бага помечает совершенно обычные IP как «запрещённые» (так же под раздачу в своё время попадали win-rar.ru и многие другие нейтральные сайты). Это объясняет, почему блок ложится на безобидную инфраструктуру и выглядит хаотично. Умышленную, целенаправленную блокировку при этом исключать нельзя — но как основное объяснение такой хаотичности она маловероятна: баг автоматики проще и лучше укладывается в картину.

Последствия для инструментов разработчиков

Блок раздачи с GitHub бьёт по программам, которые тянут оттуда обновления и данные, и экосистема под это подстраивается:

  • В панели x-ui (управление Xray) добавили возможность обновляться с GitHub через свой локальный HTTP/SOCKS5-прокси, а саму кнопку обновления сделали графической вместо консольной команды.
  • Отдельные администраторы раздают зависимостям обходные данные сами: например, с 8 мая 2026 один из пользователей ежедневно раздаёт геобазы (geoip/geosite для маршрутизации) на все российские серверы со своего сервера за рубежом, чтобы не зависеть от прямого доступа к GitHub.

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

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

📚 См. также

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

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

Вид графа

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