РКН триггерится на количество TLS-соединений в единицу времени.
Проблема HTTP/1.1: Традиционные прокси (или браузер без оптимизации) для загрузки множества элементов сайта или при передаче пачки данных внутри туннеля открывают от 6 до десятков параллельных TCP/TLS-соединений. Для РКН это выглядит как аномальный всплеск, срабатывает триггер бан на 120 секунд.
Спасение (HTTP/2): В HTTP/2 (и HTTP/3) используется мультиплексирование. Браузер или клиент устанавливает всего одно TLS-соединение, а уже внутри него передает сотни запросов одновременно.
У нас фильтрующий модицицированный прокси-сервер на Caddy. Он по умолчанию настроен на HTTP/2 и HTTP/3, имеет отличный встроенный TLS-стек (на Go) и заставляет клиента слать всё через один единственный TLS-хендшейк.
РКН видит всего 1 соединение, счетчик «подозрительных попыток» не превышает лимит (3 соединения), и блокировка не включается.
Как починить блокировку Вашего сайта от РКН ТСПУ — реальный кейс
https://habr.com/ru/articles/1045684/
UPD от 10 июня 2026 года, для тех кто писал - что не работает, попробуйте иначе, есть еще 1 настройка, которая меняет отпечаток JA4. Тесты проводил так, же на Beget.
После настройки - пускает.
Заходим в chrome://flags/
Ищите Enable benchmarking - включаете Match Field Trial Testing Config
Нужно уточнить, что это может помочь при "сибирской блокировке" в вариации с учитыванием фингерпринта браузера, но не для других случаев (их довольно много). А так любопытная находка, спасибо.
Как починить блокировку легальных сайтов РКН ТСПУ одной строчкой в Chrome
https://habr.com/ru/articles/1045438/
Как мы знаем, некоторые VPN‑сервисы маскируют трафик под легальные российские ресурсы, используя для этого мощности отечественных облачных провайдеров.
Несколько провайдеров, в том числе Selectel, Beget, Timeweb, подтвердили сбои. Причиной они назвали обновление настроек ТСПУ, которые РКН использует для фильтрации трафика.
Поскольку трафик зашифрован, ТСПУ не могут определить его содержание и принимают решения о блокировке по косвенным признакам: диапазону IP-адресов сервера, характеристикам защищённого соединения, частоте подключений и цифровому отпечатку браузера. Из-за этого под ограничения может попадать и обычный, не связанный с VPN трафик, пояснил один из собеседников.
К наиболее уязвимым для «случайных» блокировок специалисты относят мобильные приложения, которые постоянно обмениваются данными по защищённому каналу, сервисы с непрерывно открытым соединением в реальном времени, облачные платформы и b2b‑сервисы с множеством API, а также проекты, использующие решения вроде Cloudflare для ускорения и защиты медиаконтента.
РКН борется с каскадными VPN-туннелями, когда клиент подключается к серверу в России, а оттуда — к серверу вне России.
глава RUVDS Никита Цаплин
«"Более логично", если бы РКН информировал провайдера о подозрительной активности на конкретном адресе, а не блокировал адрес без предупреждения. Тогда хостинг мог бы связаться с клиентом и решить вопрос. Такой алгоритм сейчас прорабатывается», — добавил он.
РКН устроил проблемы с доступом российским облачным сервисам и сайтам
https://habr.com/ru/news/1046025/
Я кстати думаю, что по последним случаям это уже ИИ-шку натравили