Два месяца после июньского сбоя ТСПУ: почему сайты в России всё ещё пропадают
Июньский сбой закончился, но избирательные проблемы с HTTPS, SSH и доступом к серверам остались. Разбираем подтверждённые факты, новые симптомы и способы диагностики.
В начале июня 2026 года владельцы сайтов и серверов столкнулись с необычной волной сетевых сбоев. Ресурсы на Beget, Timeweb, Selectel, SpaceWeb, AdminVPS и других площадках переставали открываться у части российских пользователей, хотя серверы продолжали работать. Одновременно пропадал доступ по SSH и RDP, а привычные проверки давали противоречивые результаты.
Прошло больше двух месяцев. Единого большого сбоя уже не видно, но сама проблема никуда не исчезла. Она стала плавающей и менее заметной: сегодня сайт не открывается у абонентов одного оператора, завтра — в другом регионе, а через мобильный интернет или Firefox внезапно работает.
Июньский эпизод правильнее считать не завершённой аварией, а моментом, после которого избыточная фильтрация стала постоянным инфраструктурным риском. Доступность сайта теперь может зависеть не только от его сервера, но и от провайдера пользователя, региона, маршрута, IP-подсети и характеристик соединения.
Июньский сбой не закончился — он изменил форму
В начале июня проблему было легко заметить: жалобы на крупные хостинговые площадки появились почти одновременно. К августу картина стала другой. Нет одного момента, когда «упало всё». Вместо этого возникают локальные и периодические отказы:
- сайт доступен через одного оператора и не открывается через другого;
- главная страница загружается, но изображения, JavaScript или API зависают;
pingиmtrработают, но HTTPS или SSH не устанавливаются;- доступ восстанавливается после смены браузера, сети или IP-адреса;
- проблема исчезает без изменений на сервере, а затем появляется снова.
Из-за этого каждый отдельный случай выглядит как неисправность хостинга, DNS, сертификата, Nginx, DDoS-защиты или самого сайта. Но если сервер доступен из другой сети и не видит запросов от пострадавшего пользователя, искать причину только внутри сервера бессмысленно.
Что теперь признают сами хостинги
Самое важное изменение последних месяцев — появление постоянных инструкций от крупных инфраструктурных компаний.
Beget сообщает, что его оборудование и серверы работают штатно, а сложности возникают на стороне внешних магистральных провайдеров и автоматических систем фильтрации трафика. Компания прямо называет проблему массовой, но избирательной: результат зависит от региона и провайдера пользователя.
В качестве временных мер Beget предлагает сменить Chromium/WebKit-браузер на Firefox, попробовать другую сеть, использовать TLS 1.2 вместо TLS 1.3 и проверить работу HTTP/2. Компания отдельно предупреждает, что универсального решения нет, а алгоритмы фильтрации продолжают меняться.
Selectel 20 июля опубликовал отдельную инструкцию «Диагностика влияния ТСПУ». В ней перечислены проблемы с SSH, HTTP/HTTPS, VPN и иногда RDP. Selectel также отмечает плавающий характер отказов и то, что чаще они наблюдаются на публичных общих IP-адресах.
Это принципиальный сдвиг. Влияние ТСПУ больше не рассматривается только как новостной инцидент: оно стало самостоятельным классом сетевых неисправностей, для которого провайдер разработал процедуру сбора данных.
Почему обычная диагностика вводит в заблуждение
Классическая проверка доступности сервера строится по уровням: DNS, маршрут, порт, защищённое соединение, HTTP-ответ. Проблема в том, что каждый уровень может работать отдельно, а пользователь всё равно не увидит сайт.
| Проверка | Что она действительно доказывает |
|---|---|
dig или nslookup
|
Домен преобразуется в IP-адрес. Это ничего не говорит о прохождении трафика до сервера. |
ping
|
ICMP-пакеты проходят по маршруту. HTTPS, SSH и RDP могут фильтроваться отдельно. |
mtr или traceroute
|
Маршрут виден хотя бы частично. Прикладное соединение всё ещё может обрываться. |
| Проверка TCP-порта | TCP handshake состоялся. TLS-handshake и передача данных ещё не проверены. |
curl -v или openssl s_client
|
Показывает, на каком этапе останавливается TLS и начинается ли HTTP-обмен. |
| Access-лог сервера | Подтверждает, дошёл ли HTTP-запрос до веб-сервера. |
Типичный подозрительный сценарий выглядит так: DNS возвращает правильный IP, TCP-порт 443 отвечает, но TLS-handshake зависает, а в access-логе нет запроса. Из зарубежной точки или через другого российского оператора тот же сервер отвечает нормально.
Важно и обратное: исчезновение ping не является обязательным признаком ТСПУ. В первоначальных жалобах встречались полные таймауты вместе с ICMP, но Selectel описывает более характерный случай, когда ICMP и трассировка проходят, а SSH или HTTPS не работают.
ТСПУ не обязательно блокирует весь протокол
Фраза «Роскомнадзор отключил HTTPS» звучит эффектно, но технически слишком груба. Наблюдаемая картина больше похожа на избирательное вмешательство в отдельные потоки трафика.
На результат могут влиять:
- оператор связи и точка установки фильтрующего оборудования;
- регион и конкретный маршрут до дата-центра;
- IP-адрес, подсеть или автономная система сервера;
- SNI — доменное имя, передаваемое в начале TLS-соединения;
- набор параметров TLS ClientHello и реализация клиента;
- TLS 1.2 или TLS 1.3;
- HTTP/1.1, HTTP/2 или HTTP/3 поверх QUIC;
- число и частота параллельных соединений.
Это не означает, что все перечисленные признаки обязательно объединены в один алгоритм. Публичной спецификации правил нет, а конфигурации могут различаться между операторами. Корректнее говорить, что результат зависит от комбинации сетевых и клиентских параметров, точный вес которых неизвестен.
Академическое исследование Censored Planet ещё раньше показало, что ТСПУ способны применять блокировки по IP, SNI и QUIC, сохранять состояние соединений и вести себя неодинаково в разных сетях. Это объясняет, почему одной проверки «из России» недостаточно: России как единой точки измерения не существует.
Июль показал, что проблема шире российских хостингов
14 июля пользователи начали сообщать о недоступности GitHub, Apple, Google и Samsung. «Коммерсантъ» самостоятельно подтвердил, что GitHub и Apple не загружались без VPN, тогда как проблемы Google и Samsung наблюдались не у всех. Позднее ресурсы начали восстанавливаться.
Роскомнадзор заявил, что не ограничивает доступ к этим сервисам. Это важная часть картины: наличие сетевых признаков фильтрации ещё не является документальным подтверждением конкретной команды ведомства.
Через несколько дней исследователи проверили инфраструктуру Apple из нескольких российских регионов. DNS работал, порт принимал соединение, но защищённый канал обрывался во время установки. Те же серверы отвечали из-за пределов России. При этом результаты различались между городами и даже между серверами одного провайдера.
Июньская история оказалась не только проблемой нескольких хостингов. Похожие симптомы могут затрагивать репозитории кода, CDN, магазины приложений, API и серверы обновлений.
Почему страница открывается наполовину
Современный сайт редко загружается с одного домена. Основной HTML может находиться на сервере владельца, а остальные части — на внешних площадках:
- изображения и видео — в CDN или объектном хранилище;
- шрифты и JavaScript — на отдельном статическом домене;
- авторизация — в стороннем сервисе;
- формы и CRM — через API;
- капча и аналитика — у внешнего поставщика;
- оплата — на стороне банка или платёжного шлюза.
Поэтому сайт может вернуть 200 OK, но остаться бесполезным для посетителя: без изображений, меню, формы, входа в аккаунт или оплаты. Проверять нужно не только главный URL, но и критические зависимости страницы.
Почему HTTP/2 и TLS 1.2 иногда помогают
HTTP/2 позволяет передавать множество запросов внутри одного соединения. Браузеру не приходится создавать отдельный TLS-канал для каждого изображения или скрипта. В результате меняются частота соединений и видимый профиль трафика.
TLS 1.2 и TLS 1.3 по-разному устанавливают защищённое соединение. Переключение версии также меняет набор данных, который видит фильтрующее оборудование до начала шифрованного обмена.
Принудительный переход на TLS 1.2 или HTTP/2 может помочь у конкретного оператора сегодня и перестать помогать после следующего изменения правил. Нельзя без проверки навсегда отключать современные протоколы на всех проектах.
Почему смена хостинга не гарантирует результат
Переезд действительно меняет IP, подсеть, автономную систему и маршрут. Поэтому после миграции сайт иногда сразу становится доступным. Но из этого не следует, что новый хостинг защищён от проблемы.
Фильтрация может зависеть от конкретного адреса или маршрута, а правила способны измениться позднее. Selectel прямо предупреждает, что даже смена IP не гарантирует восстановление трафика.
До переезда полезно провести простой эксперимент: поднять на новой площадке тестовый домен с теми же версиями TLS и HTTP и проверить его через несколько операторов. Иначе можно потратить время на миграцию и получить тот же симптом в другой подсети.
Мониторинга из одной точки больше недостаточно
Если мониторинг размещён в том же дата-центре, что и сайт, он может не видеть проблем на пользовательских маршрутах. Зарубежный сервис тоже покажет идеальный аптайм, пока российские посетители получают таймауты.
Минимальная полезная схема наблюдения должна включать несколько независимых российских сетей и одну зарубежную контрольную точку. Желательно отдельно проверять:
- DNS-ответ;
- ICMP и маршрут;
- TCP-подключение к нужному порту;
- TLS-handshake;
- HTTP-код и время ответа;
- загрузку критических изображений, скриптов и API.
Одна зелёная лампочка «сайт работает» больше не описывает реальную доступность сервиса.
Что делать владельцу сайта сейчас
- Сравнить несколько сетей. Проверить проводной интернет, мобильного оператора и внешнюю контрольную точку.
- Разделить уровни диагностики. Не ограничиваться пингом: проверить DNS, TCP, TLS и HTTP отдельно.
- Сравнить Firefox и Chromium. Разница результатов даст дополнительный технический сигнал.
- Посмотреть серверные логи. Если запрос не появился, проблема возникла до веб-сервера.
- Проверить внешние зависимости. CDN, API, авторизацию, капчу, аналитику и платёжные сервисы.
- Зафиксировать данные. Время, исходный IP, IP сервера, оператора, регион, порт и точный этап таймаута.
- Передать данные хостингу и оператору. Абстрактная жалоба «сайт не работает» почти бесполезна без пары адресов и времени проверки.
- Иметь резервный канал управления. KVM-консоль, панель хостинга или доступ через независимую сеть пригодятся при отказе SSH/RDP.
- Тестировать изменения как гипотезы. Смена IP, TLS 1.2 или HTTP/2 не должны превращаться в необратимую перестройку без сравнительных замеров.
Что можно считать доказанным, а что пока остаётся гипотезой
Подтверждается достаточно уверенно
- проблемы имеют массовый, но избирательный характер;
- результат зависит от провайдера, региона и маршрута;
- могут затрагиваться HTTP/HTTPS, SSH, VPN и иногда RDP;
- сервер способен работать штатно, пока часть пользователей не может подключиться;
- смена сети, браузера, протокола или IP иногда временно восстанавливает доступ;
- крупные хостинги уже включили влияние ТСПУ в эксплуатационную диагностику.
Нельзя выдавать за установленный факт
- единый универсальный порог параллельных соединений;
- бан всегда ровно на 120 или 600 секунд;
- одинаковый список «подозрительных» подсетей у всех операторов;
- обязательную блокировку всего TLS 1.3, SSH или HTTPS;
- единую конфигурацию ТСПУ для всей страны;
- прямую связь каждого сетевого сбоя с распоряжением Роскомнадзора.
Вывод
Главный результат последних двух месяцев — не обнаружение одного секретного алгоритма ТСПУ. Напротив, стало понятно, что универсального объяснения для всех случаев пока нет.
Где-то проходит ping, но не устанавливается HTTPS. Где-то сайт работает в Firefox, но зависает в Chromium. Где-то смена IP возвращает доступ, а через несколько дней проблема появляется снова. Такая неоднородность и делает ситуацию сложнее обычной аварии.
Для владельцев сайтов это новая эксплуатационная реальность: недостаточно обеспечить исправность сервера. Приходится отдельно контролировать, может ли пользователь из конкретной российской сети установить соединение и загрузить все критические части сервиса.