Ранее уже выкладывал способ, Как починить блокировку легальных сайтов РКН ТСПУ одной строчкой в Chrome - он работает но не для всех.
Теперь же мы разберем ситуацию, как починить Ваш сайт если Вы Владелец / Администратор легитимного сайта, расскажу как к этому пришёл и почему это работает.
UPD: 11 Июня добавил в материал полезные ссылки (как проверять включен ли HTTP 2 и отключен ли TLS 1.3) - простые руководства, как включить HTTP 2 и отключить TLS 1.3.
Начало
5 июня: Массовый сбой сайтов на хостингах Beget, TimeWeb, Selectel и SpaceWeb из-за обновления настроек ТСПУ - об этом написали сами хостеры, мол держитесь, с нашей стороны проблем нет.
Сайт не открывается, в консоли вечный Connection timed out, а сервер даже не пингуется!
Вот пример, часть ответа TimeWeb (от 4 июня)
Вероятная причина — изменения в настройках технических средств противодействия угрозам (ТСПУ). Проводим диагностику и держим связь с профильными службами, чтобы установить причины такого поведения.
Признаки проблемы: таймаут подключений по SSH/RDP, недоступность протоколов HTTP/HTTPS/ICMP на сервере.
Часть сообщения от Beget (5 июня)
Коллеги, наблюдаем частичную недоступность некоторых ресурсов Beget у части пользователей.
Данная проблема носит плавающий характер и связана с обновлением настроек ТСПУ со стороны РКН.
Проблема затрагивает не всех наших пользователей и зависит от сочетания оператора связи, региона и используемого браузера.
Также в настоящий момент схожие проблемы наблюдаются у пользователей и других крупных провайдеров инфраструктуры.
Я сразу написал на своем сайте пост "ответов от хостеров" и стал собирать трафик для дальнейшего анализа проблемы. Как оказалось страдают многие, AdminVPS, FristVDS и другие.
А вот REGRU вообще нет (многие его IP адреса в белом списке), я не собрал запросов с этого хостинга, хотя единично в профильных чатах писали о проблеме - я не подтвердил это.
Для меня ситуация была критична, так как у меня проксирующий сервис защиты eByeBots.
Защита сайта от ботов спама и атак, и мои клиенты все подключены через 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://адрес-сайта
Посмотрите как у Вас в веб-сервере включается HTTP/2
РКН триггерится на количество 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 соединения), и блокировка не включается.
Включите HTTP/2 и проверьте наличие проблемы.
Как проверить отключен ли TLS 1.3
Вы можете проверить через специальный сайт, введя адрес сайта:
В данном случае, TLS 1.3 Disabled - отключен.
Можно проверить и через SSH
openssl s_client -connect example.com:443 -tls1_3
После запуска команды обратите внимание на первые строки вывода или на итоговый блок SSL-Session:
Если TLS 1.3 включен: вы увидите успешное подключение и строчку с протоколом:
Protocol : TLSv1.3Если TLS 1.3 НЕ поддерживается: команда завершится ошибкой (например, handshake failure или unknown option на совсем старых версиях OpenSSL), либо сервер принудительно снизит версию протокола до TLS 1.2, о чем будет написано в строке
Protocol.
Руководство, как включить HTTP 2 и отключить TLS 1.3
Я не стал подобное расписывать, так как у всех разные конфигурации и идеального решения под ключ не будет, но AdminVPS сделали такой материл для веб-сервера Nginx.
инструкция для ispmanager 6
инструкция для Fastpanel
Как это работает через наш прокси-сервер
Если HTTP 2 и отключение TLS 1.3 не поможет - попробуйте "как у нас", используем Caddy (отдельный VPS в нашем случае).
отключен редирект на основном сервере 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.crt tls_server_name {$DOMEN} dial_timeout 30s response_header_timeout 30s keepalive 60s } } } }
А записи направлены на IP прокси сервера
Если не отключить редирект, то будет 502 ошибка (циклическая переадресация), можете просто тогда заменить:
{$DOMEN}, www.{$DOMEN} { На https://сайт, www.https://сайт {
По итогу искал проблему, которой лично у меня не оказалось, надеюсь это кому то поможет.
Дополню этот пост, если будут другие рабочие варианты. Спасибо!
