Как починить блокировку Вашего сайта от РКН ТСПУ — реальный кейс

Ранее уже выкладывал способ, Как починить блокировку легальных сайтов РКН ТСПУ одной строчкой в Chrome — он работает но не для всех.

Теперь же мы разберем ситуацию, как починить Ваш сайт если Вы Владелец / Администратор легитимного сайта, расскажу как к этому пришёл и почему это работает.

Начало

5 июня: Массовый сбой сайтов на хостингах Beget, TimeWeb, Selectel и SpaceWeb из-за обновления настроек ТСПУ — об этом написали сами хостеры, мол держитесь, с нашей стороны проблем нет.

Сайт не открывается, в консоли вечный Connection timed out, а сервер даже не пингуется!

Вот пример, часть ответа TimeWeb (от 4 июня)

Вероятная причина — изменения в настройках технических средств противодействия угрозам (ТСПУ). Проводим диагностику и держим связь с профильными службами, чтобы установить причины такого поведения.

Признаки проблемы: таймаут подключений по SSH/RDP, недоступность протоколов HTTP/HTTPS/ICMP на сервере. 

Часть сообщения от Beget (5 июня)

Коллеги, наблюдаем частичную недоступность некоторых ресурсов Beget у части пользователей.

Данная проблема носит плавающий характер и связана с обновлением настроек ТСПУ со стороны РКН.

Проблема затрагивает не всех наших пользователей и зависит от сочетания оператора связи, региона и используемого браузера.
Также в настоящий момент схожие проблемы наблюдаются у пользователей и других крупных провайдеров инфраструктуры.

Я сразу написал на своем сайте пост ответов от хостеров и стал собирать трафик для дальнейшего анализа проблемы. Как оказалось страдают многие, AdminVPS, FristVDS.

А вот REGRU вообще нет (да и многие его IP адреса в белом списке), я не собрал запросов с этого хостинга, хоте единично в профильных чатах писали о проблеме — я не подтвердил это.

Для меня ситуация была критична, так как у меня сервис по защите сайта от ботов спама и атак, и мои клиенты все подключены через Beget. Потерять клиента — легко.

Я оповестил о частичной проблеме всех клиентов через тг канал и забыл про это..

У Beget не открывается сам сайт (не грузится CDN) и без VPN юзеры просто не доходят до сайта.

Потом я наткнулся на статью О схеме ограничений РКН в июне 2026-го изучил и понял что нужно как-то сменить TLS отпечаток, но это со стороны пользователя, получилось через флаг Cryptography Compliance (CNSA) — многим помогло.

И тут я поймал себя на мысли, а есть ли вообще у моих клиентов проблема?

Есть клиенты у которых большие интернет-магазины, и они даже на пишут, а с некоторыми я вообще общаюсь по почте. Если какая недоступность, мне пишут.. Начал уточнять, а была ли проблема за эти 3 дня, и как оказалось — жалоб нет. Отлично!

Тут я решил уже на своем сайте разместить пост мол Ищем пострадавших, собрал круг пострадавших, ставил им прокси-сервер (трафик шел через прокси сервер, фильтровался легитимные заходы проксировались на основной IP) и на удивление всё работало.

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

Написал автору hyperion_cs (рекомендую изучить его пост О схеме ограничений РКН в июне 2026-го), мол так и так — все кто подключены к прокси серверу — проблем не испытывают и тут мы начали тестировать почему. Большое спасибо за уделённое время.

hyperion-cs протестировал сайты клиентов через своё решение — dpi-checkers

Была теория о том что у кого стоит TLS 1.2 (а не TSL 1.3) — у тех всё хорошо, и Вы знаете — в профильных чатах люди писали что отключили TLS 1.3 и проблема ушла, ну вот так, да.

А на наших фильтрующих прокси-серверах, как раз стоит TLS 1.2 (помня ситуацию с Cloudfalre)

Я искал владельцев сайтов у кого стоит TLS 1.2 и всё равно проблема

Варианты решения проблемы были следующие

• Принудительный откат с TLS 1.3 на TLS 1.2

• Установка прокси-заглушки (на айпи который не блочится оборудование ТСПУ и мол уведомление о Firefox, потом дошло что если айпи не подозрительный, то это сработает (судя по графику)

  

• переехать на хостинг где нет проблем

• Подача заявки на внесение в официальные белые списки Для Selectel (думаю и не только) — если вы юридическое лицо или ИП, вы можете обосновать исключение фильтрации ТСПУ для вашей подсети.

• Есть умельцы, кто продаёт айпи из белых списков\

• Ждать костыли

Решение: включите HTTP/2 only

У меня на всех прокси-серверах для сайтов, включен HTTP/2

Посмотрите как у Вас в веб-сервере включается HTTP/2

curl -Iv https://адрес-сайта

РКН триггерится на количество TLS-соединений в единицу времени.

1. Проблема HTTP/1.1: Традиционные прокси (или браузер без оптимизации) для загрузки множества элементов сайта или при передаче пачки данных внутри туннеля открывают от 6 до десятков параллельных TCP/TLS-соединений. Для РКН это выглядит как аномальный всплеск, срабатывает триггер бан на 120 секунд.

2. Спасение (HTTP/2): В HTTP/2 (и HTTP/3) используется мультиплексирование. Браузер или клиент устанавливает всего одно TLS-соединение, а уже внутри него передает сотни запросов одновременно.

У нас фильтрующий модицицированный прокси-сервер на Caddy. Он по умолчанию настроен на HTTP/2 и HTTP/3, имеет отличный встроенный TLS-стек (на Go) и заставляет клиента слать всё через один единственный TLS-хендшейк.

РКН видит всего 1 соединение, счетчик «подозрительных попыток» не превышает лимит (3 соединения), и блокировка не включается.

Включите HTTP/2 и проверьте наличие проблемы.

У нас это работает примерно так:

• отключен редирект на основном сервере http > https

• выдан само подписанный сертификат от прокси сервера — работает между прокси сервером и вашим бэкендом

openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \  -keyout /etc/caddy/my_private.key \  -out /etc/caddy/my_selfsigned.crt \  -subj "/CN=ваш-сайт" \  -addext "subjectAltName = DNS:ваш-сайт, DNS:*ваш-сайт"

• сам Caddy выдает автообновляемый Let’s Encrypt сертификат

• минимальный конфиг caddyfile для проксирования
  {$BACKEND_IP} — вставляете айпи основного сервера
  {$DOMEN} — Ваш домен

{$DOMEN}, www.{$DOMEN} {    tls {protocols tls1.2 tls1.2}encode zstd gzip@www {host www.{$DOMEN}}handle @www {redir https://{$DOMEN}{uri} permanent}##########################################################################route {reverse_proxy https://{$BACKEND_IP} {header_up Host {http.request.host}header_up X-Real-IP {http.request.remote.host}transport http {tls_trusted_ca_certs /etc/caddy/my_selfsigned.crttls_server_name {$DOMEN}dial_timeout 30sresponse_header_timeout 30skeepalive 60s}}}}

• А записи направлены на IP прокси сервера

Если не отключить редирект, то будет 502 ошибка (циклическая переадресация), можете просто тогда заменить:

{$DOMEN}, www.{$DOMEN} {Наhttps://сайт, https://сайт {

По итогу искал проблему, которой лично у меня не оказалось, надеюсь это кому то поможет.

Дополню этот пост, если будут другие рабочие варианты. Спасибо!