Ранее уже выкладывал способ, Как починить блокировку легальных сайтов РКН ТСПУ одной строчкой в 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-соединений в единицу времени.

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 и проверьте наличие проблемы.

Как проверить отключен ли 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://сайт {

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

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