В начале июня 2026 года рунет столкнулся с очередной волной «веерных» сбоев. Из-за обновлений на ТСПУ (технических средствах противодействия угрозам) под удар попали тысячи абсолютно легальных сайтов.
Пользователи видят бесконечный Connection timed out, сервера переставали пинговаться, а администраторы в панике штурмуют техподдержку хостингов.
Ранее уже выкладывал способ, Как починить блокировку легальных сайтов РКН ТСПУ одной строчкой в Chrome — он работает но не для всех и способ больше для клиентов.
Если ваш ресурс хостится на Beget, TimeWeb, Selectel, SpaceWeb или FristVDS и внезапно «прилег» для части пользователей — эта статья для вас. Мы разберем физику процесса и покажем готовое решение, которое помогло вернуть сайты к жизни.
С 5 июня 2026 РКН через ТСПУ под блокировку попали не только VPN, но и обычные, легитимные сайты. Мы разработали специальную бесплатную страницу проверки, теряет ли Ваш сайт трафик.
Вы можете подключиться к нашей защите eByeBots — защита от ботов, спама и DDoS и сохранить потенциальный трафик, сервис уже настроен. Для уточнения деталей — напишите нам в чат.
Что произошло?
- 4–5 июня 2026: Крупнейшие российские хостеры — Beget, TimeWeb, Selectel, SpaceWeb и FristVDS — массово фиксируют частичную недоступность своих ресурсов. Техподдержка разводит руками: «С нашей стороны проблем нет, это плавающие обновления ТСПУ со стороны РКН, которые зависят от региона и оператора связи».
- Симптомы: Полный таймаут подключений по SSH/RDP, недоступность протоколов HTTP/HTTPS, и даже ICMP (сервер вообще перестает пинговаться).
- Исключения: Провайдер REGRU практически не пострадал — большинство их IP-адресов изначально находятся в белых списках систем фильтрации.
Почему у многих не работает, а у нас всё хорошо?
Прошло три дня. У самого Beget не открывается сайт (не прогружается CDN), профильные чаты кипели от ярости, а от моих клиентов… тишина.
Я начал писать владельцам крупных интернет-магазинов, с которыми мы работаем, проверять доступность вручную. Жалоб нет. Всё работает как часы.
Чтобы докопаться до сути, я опубликовал в своем блоге пост: «Ищем пострадавших от блокировок ТСПУ».
Собрал группу вебмастеров, чьи сайты намертво лежали, и ради эксперимента бесплатно подключал их к нашим фильтрующим прокси-серверам eByeBots.
Трафик пошел через нас, очищался от ботов и проксировался на их реальные IP.
Результат: Сайты пострадавших мгновенно ожили. Но почему?
Физика процесса: секретный триггер ТСПУ
Оказалось, что ТСПУ в июне 2026-го начали активно триггериться на количество TLS-соединений в единицу времени от одного клиента. Они ищут подозрительные туннели и VPN-протоколы.
Проблема HTTP/1.1: Чтобы загрузить современный сайт (с кучей картинок, стилей и скриптов), браузер в режиме HTTP/1.1 открывает от 6 до нескольких десятков параллельных TCP/TLS-соединений. Для ТСПУ это выглядит как аномальный всплеск. Включается автоматический бан IP-адреса на 120 секунд.
Спасение в HTTP/2 (Мультиплексирование): В протоколах HTTP/2 и HTTP/3 клиент устанавливает всего одно TLS-соединение, а уже внутри него передает сотни запросов одновременно.
На наших фильтрующих прокси-серверах eByeBots на базе модифицированного веб-сервера Caddy по умолчанию был включен и настроен HTTP/2 Only в связке с TLS 1.2.
РКН видит всего 1 соединение, счетчик «подозрительных попыток» не превышает лимит (обычно это 3 соединения), и блокировка просто не срабатывает! Трафик признается легитимным.
Варианты решения проблемы
Если ваш сайт попал под раздачу, путей несколько:
Официальный (для юрлиц или ИП): Подать заявку хостеру (например, в Selectel) на внесение ваших подсетей в официальные белые списки РКН. Требует времени и железных обоснований.
Миграция: Переехать на хостинг, чьи IP-адреса ТСПУ пока не «кошмарит».
Переход на HTTP/2 Only и ограничение TLS до 1.2
Чтобы понять, почему связка HTTP/2 Only + TLS 1.2 спасает сайт от блокировок, нужно заглянуть «под капот» ТСПУ (Технических средств противодействия угрозам) и понять, как именно они анализируют сетевой трафик в 2026 году.
ТСПУ не блокирует ваш сайт целенаправленно — подсеть хостинга попадает под веерный (автоматический) алгоритм защиты.
Почему спасает HTTP/2
Системы глубокого анализа пакетов (DPI) на ТСПУ настроены на выявление аномалий. Одна из главных аномалий для них — множественные быстрые запросы на установку шифрованного соединения (TLS Handshakes) с одного IP-адреса на другой. ТСПУ считает это признаком работы VPN-протоколов, прокси-туннелей или DDoS-атаки и включает автоматический бан на 120 секунд.
Как работает старый HTTP/1.1: Когда обычный пользователь заходит на сайт, его браузеру нужно скачать десятки элементов (HTML, картинки, стили, скрипты). HTTP/1.1 не умеет качать их одновременно по одному каналу. Поэтому браузер вынужден открывать от 6 до 30 параллельных TCP-соединений, и в каждом из них происходит процедура TLS-хендшейка. Для ТСПУ это выглядит как резкий «всплеск» подозрительной активности. Счетчик лимитов превышен — прилетает бан.
Как работает HTTP/2 Only: В этом протоколе используется мультиплексирование. Браузер клиента создает всего одно TCP-соединение и совершает ровно один TLS-хендшейк. А уже внутри этого единого, зашифрованного «туннеля» передаются сотни файлов одновременно.
Итог: Для ТСПУ ваш сайт выглядит как абсолютно невинный одиночный запрос. Лимит (три соединения в секунду) не превышается, триггер блокировки молчит.
Почему нужно принудительно сменить TLS до версии 1.2
Казалось бы, TLS 1.3 — более современный и безопасный протокол. Зачем откатываться на TLS 1.2? Дело в том, как устроено шифрование в этих версиях.
- Проблема TLS 1.3 (Полное шифрование): В версии TLS 1.3 почти все данные хендшейка, включая расширения и отпечатки (JA3/JA4/Fingerprints), зашифрованы с самого первого пакета. Для ТСПУ это «абсолютно черная коробка». Поскольку РКН активно борется с обходом блокировок, ТСПУ обучен блокировать всё неизвестное и слишком хорошо зашифрованное, если оно идет терабайтами на популярные хостинги.
- Плюсы TLS 1.2 для ТСПУ: В протоколе TLS 1.2 часть технических данных при установлении соединения (например, пакет
Client Hello) передается в открытом (но неизменяемом) виде. ТСПУ может прочитать SNI (имя домена) и увидеть стандартную структуру старого доброго HTTPS-трафика. - Итог: TLS 1.2 выглядит для ТСПУ как «свой», понятный и легитимный трафик из прошлого, который не похож на современные скрытые VPN-туннели. Робот РКН видит стандартные маркеры и пропускает пакеты дальше.
Если HTTP/2 Only и ограничение TLS до 1.2 не работает, попробуйте сделать как у нас
Как настроить «Как у Вас»?
Если вы хотите поднять прокси своими руками, краткий алгоритм выглядит так:
На стороне бэкенда: Отключите редирект с
httpнаhttps, чтобы избежать петли (502 ошибка). Связь между прокси и бэкендом пойдет по самоподписанному сертификату.Генерация SSL: Создайте само подписанный сертификат на прокси-сервере через
openssl req -x509.Конфиг Caddyfile: Зажмите протокол в HTTP/2 и TLS 1.2, пропишите
reverse_proxyна ваш реальный IP и направьте A-записи домена на прокси.
Полный рабочий код конфигурации, разбор подводных камней и комментарии вы найдете в первоисточнике (необходимо иметь навык системного администрирования или желание разобраться)
Пока другие ищут решения и спорят в комментариях, готовая инфраструктура eByeBots уже защищает проекты наших клиентов
Что вы получаете при подключении к нам
Защиту под ключ: Мы сами арендуем для вас выделенный VPS в оптимальной локации (Москва/СПб), настроим прокси-сервер. Вам не нужно обладать навыками DevOps и следить за конфигами.
Иммунитет к сегодняшним блокировкам ТСПУ: Наш стек изначально спроектирован под правильное мультиплексирование трафика — РКН считает ваши соединения абсолютно легитимными.
Комплексную фильтрацию ботов: Мы убираем мусорный трафик, снижаем отказы в Яндекс Метрике (в наших кейсах — с 78% до нормы) и спасаем ваше SEO от накрутчиков.
Прозрачную веб-панель аналитики: Вы лично сможете контролировать каждый запрос через детальные логи (IP, User-Agent, причины блокировок). Даем 7 дней триала на панель аналитики бесплатно!
