Не работают сайты после 1 июня?

В начале июня 2026 года российские хостинг-провайдеры начали массово фиксировать частичную недоступность легитимных сайтов для пользователей из РФ. Повторяющаяся картина в первичных источниках выглядит следующим образом. Сервер у провайдера функционирует штатно, однако у части абонентов — в зависимости от оператора связи, региона, а иногда от браузера — наблюдаются таймауты при доступе по HTTPS, SSH, RDP. В ряде сообщений упоминаются также сбои ICMP. Эту ситуацию публично описывали Timeweb, FirstVDS, Beget, 1dedic, а впоследствии — в эксплуатационной документации — Selectel.

Главное для практики — на текущий момент подтверждён сам факт ложных либо избыточных срабатываний фильтрации на сетевом пути, но не детальный закрытый алгоритм ТСПУ. Поэтому любые утверждения про «ровно 3 параллельных TLS-сессии», «ровно 120 секунд заморозки», «ровно такой-то список браузерных отпечатков» следует трактовать как результат обратной разработки силами сообщества, а не как официально подтверждённую спецификацию. При этом рекомендации хостинг-провайдеров удивительно согласованы между собой — уводить публичный трафик в предсказуемую схему TCP/443 → TLS 1.2 → HTTP/2, не полагаться на QUIC/HTTP/3, уменьшать всплески параллелизма, выносить наружу фронтальный обратный прокси-сервер, тестировать доступность из разных сетей РФ.

С технической стороны у этой рекомендации есть разумная логика. HTTP/2 действительно умеет мультиплексировать множество запросов внутри одного соединения, тогда как HTTP/1.1 исторически стимулирует открытие нескольких параллельных TCP-соединений. HTTP/3 функционирует поверх QUIC/UDP, а QUIC представляет собой иной путь наблюдаемости для промежуточного сетевого оборудования глубокой инспекции пакетов (DPI). Важно, однако, не повторять распространённую неточность — ни TLS 1.3, ни QUIC не делают ClientHello «полностью невидимым с первого байта» в том смысле, как это часто пишут в публикациях. В TLS 1.3 по умолчанию ClientHello вместе с SNI не скрыты; для их сокрытия требуется отдельный механизм ECH. У QUIC начальные пакеты (Initial) вовсе не считаются конфиденциальными, поскольку ключи для них тривиально выводимы из параметров соединения.

Практический вывод для интернет-агентства или владельца сайта следующий. В качестве первого эшелона имеет смысл отключить HTTP/3/QUIC, убедиться, что на публичном граничном узле реально работает HTTP/2, при необходимости временно ограничить публичную фронтальную часть до TLS 1.2 — но не на серверной части «везде подряд», а осознанно, с пониманием, что это компромисс по безопасности. Второй эшелон — вынести сайт за отдельный обратный прокси-сервер, CDN либо фронтовой сервер с выделенным IP или выделенной публичной подсетью. Третий эшелон — эксплуатационное сопровождение, включающее тесты из нескольких операторских сетей, захват пакетов, обращения к хостеру, операторские запросы, а также административные процедуры по включению в белый список.

Хронология наблюдаемых симптомов

Публичная хронология складывается достаточно ровно. Уже 5 июня 2026 Timeweb сообщал, что часть пользователей сталкивается с недоступностью инфраструктуры в сетях российских операторов, а сама проблема проявляется по-разному в зависимости от оператора связи, региона, браузера; вероятной причиной провайдер назвал изменения в настройках ТСПУ. 9 июня 2026 FirstVDS опубликовал уведомление о проблемах доступа по HTTPS, SSH, RDP, а также о возможных сбоях ICMP. В июньских публикациях Beget с 1dedic картина описана аналогично — сеть вместе с серверами провайдера исправны, а сбои находятся на внешнем фильтрационном пути. Уже в июле 2026 Selectel не только не снял тему с повестки, но оформил отдельную документацию по диагностике влияния ТСПУ, а также по требованиям к IP-адресам для процедур включения в белый список во время ограничений мобильного интернета.

Повторяющаяся симптоматика выглядит следующим образом.

• У одного пользователя сайт открывается, у другого — нет.
• Проблема зависит от провайдера доступа, региона, иногда от браузера.
• На уровне хостинг-провайдера оборудование с внутренней связностью зачастую остаются в норме.
• Нарушается работа не только веб-ресурсов, но также административных каналов — HTTPS, SSH, RDP.
• ICMP не является надёжным диагностическим признаком — в одних случаях он проходит, в других провайдеры сообщали о сбоях.

Различие по ICMP особенно существенно. В документации Selectel одним из признаков влияния ТСПУ названа ситуация, когда SSH/HTTP(S)/RDP страдают, а ICMP, mtr, telnet могут проходить. У FirstVDS вместе с Timeweb, напротив, в инцидентных сообщениях фигурируют возможные проблемы с ICMP. Из этого следует практический вывод — проверка «пинг идёт / не идёт» не может служить единственным критерием отнесения проблемы к серверу либо к ТСПУ. Необходима верификация именно прикладного протокола, версии TLS, а также согласованного HTTP-протокола.

По сути, рынок в июне–июле 2026 года пришёл к редкому консенсусу — проблема реальна, массова, внешняя по отношению к хостинг-провайдеру, требует не «перезагрузить NGINX», а перестройки поведения граничного узла ресурса наряду с аккуратной сетевой диагностикой.

Что подтверждено, а что остаётся гипотезой

1. Во многих июньских случаях серверы с сетями хостеров функционировали штатно, а проблема находилась на внешнем пути фильтрации — ПОДТВЕРЖДЕНО. Эту формулировку или её эквиваленты публично давали Timeweb, FirstVDS, Beget.

2. Проблема зависела от оператора связи, региона, иногда от браузера — ПОДТВЕРЖДЕНО. Это буквально повторяется у Timeweb вместе с Beget; FirstVDS отдельно советовал Firefox из-за отличающегося TLS-отпечатка.

3. Под удар попадали HTTPS, SSH, RDP, а местами ICMP — ПОДТВЕРЖДЕНО. Прямо указано у FirstVDS, Timeweb; Selectel также перечисляет SSH, HTTP/HTTPS, VPN, иногда RDP.

4. HTTP/2 как основной публичный режим уменьшает число параллельных TLS-сессий, что потенциально снижает риск ложных срабатываний — ПОДТВЕРЖДЕНО как инженерная рекомендация. Это публично советуют FirstVDS, 1dedic; протокольная база HTTP/2 данному тезису соответствует.

5. Отключение QUIC/HTTP/3 совместно с временным ограничением фронтальной части до TLS 1.2 может помочь — ПОДТВЕРЖДЕНО как практическая мера, но не как гарантированное решение. Это рекомендуют несколько хостинг-провайдеров; Beget отдельно помечает меру как негарантированную.

6. Разделяемые IP-адреса рискованнее, чем выделенный IP либо выделенная публичная подсеть — ПОДТВЕРЖДЕНО. Selectel прямо указывает, что проблемы чаще наблюдаются на публичных разделяемых адресах, предлагая смену IP или выделенную подсеть как один из шагов.

7. ТСПУ анализирует ClientHello, SNI, браузерные/TLS-отпечатки, лавинообразную параллельность, а затем «замораживает» соединения на 120 секунд — НЕ ПОДТВЕРЖДЕНО. Предположения сообщества, не подкреплённые официальными данными.

8. Фильтрация перешла от отдельных IP к подсетям крупных хостеров — частично согласуется с полевыми наблюдениями. Хостинг-провайдеры публично говорят лишь о массовой избирательности, иногда о целых пулах.

9. В июньском инциденте применялись именно JA3/JA4 — правдоподобно, но не доказано. Для мартовской блокировки Snowflake в РФ анализ JA3/JA4/DTLS зафиксирован; для июньских отказов легитимных ресурсов публичного первичного подтверждения применения JA3/JA4 нет.

Наиболее аккуратная формулировка звучит так — подтверждён результат фильтрации, подтверждены наиболее действенные обходные инженерные меры; закрытый алгоритм точного соответствия ТСПУ в июньской волне публично не раскрыт. Это существенно, потому что бизнесу часто продают либо «волшебную одну галочку», либо, наоборот, конспирологию про совершенно точные правила. Реальность посередине — есть устойчивая техническая картина, но нет официальной технической спецификации «как работает ТСПУ в июне 2026».

Протоколы: почему они меняют видимость трафика для систем глубокой инспекции

HTTP/1.1, HTTP/2, HTTP/3 вместе с разными версиями TLS важны здесь не как «модные технологии», а как разные способы упаковать одни те же запросы к веб-ресурсу. HTTP/2 описан IETF как более эффективное представление протокола HTTP с возможностью нескольких параллельных обменов в рамках одного соединения. Для класса проблем, где ложное срабатывание предположительно связано с количеством рукопожатий, это фундаментально меняет внешний профиль трафика.

HTTP/1.1, напротив, исторически побуждает клиентов открывать несколько соединений к одному серверу-источнику, поскольку одна TCP-сессия не решает задачу современной страницы с десятками CSS/JS/изображений так же удобно, как HTTP/2. В RFC 9113 это объяснено прямо — из-за ограничений HTTP/1.0, а частично HTTP/1.1, клиенты используют множественные соединения для одновременных запросов. Для нынешнего инцидента это означает не «HTTP/1.1 плох в целом», а то, что он хуже выглядит для системы, способной реагировать на всплеск параллельных TLS-установок.

HTTP/3 — это уже HTTP поверх QUIC, а QUIC работает поверх UDP, предоставляя мультиплексирование потоков, установление соединения с пониженной задержкой, прочие транспортные преимущества. Но для рассматриваемой проблемы важна не столько скорость, сколько иной профиль сетевого пути — UDP/443, начальные пакеты QUIC, анонс Alt-Svc, другое поведение промежуточного сетевого оборудования. Именно поэтому хостинг-провайдеры почти синхронно советовали не опираться на QUIC/HTTP/3 на публичном входе, даже если в обычных условиях он полезен для производительности.

Есть важная методологическая поправка. Популярная фраза «QUIC зашифрован с первого байта, DPI ничего не видит» технически слишком груба. В RFC 9001 прямо сказано, что начальные пакеты используют ключи, тривиально выводимые из идентификатора соединения назначения, потому не считаются обеспечивающими конфиденциальность или защиту целостности; при этом все прочие QUIC-пакеты уже получают сильную криптографическую защиту. Иными словами, QUIC действительно труднее обрабатывать старым TCP-центричным оборудованием, но это не равно «абсолютной невидимости ClientHello с первого байта».

С TLS ситуация похожая. В TLS 1.3 после ServerHello большая часть значимых данных рукопожатия уже идёт в зашифрованной форме; серверный сертификат действительно скрыт. Но ClientHello сам по себе по умолчанию не скрывается, а SNI использует расширение server_name, которое клиент отправляет в ClientHello. Чтобы прятать чувствительное содержимое ClientHello, нужен отдельный стандарт ECH, опубликованный только в 2026 году как RFC 9849. Следовательно, тезис «отключите TLS 1.3, потому что ТСПУ не видит SNI» тоже в строгом виде неверен — без ECH показатель SNI в TLS 1.3 по-прежнему не исчезает из наблюдаемого рукопожатия.

Из этого следует более точное объяснение, почему многие провайдеры советовали временно оставить на фронтальной стороне только TLS 1.2. Не потому, что TLS 1.3 «невозможно проанализировать вообще», а потому, что конкретные фильтрационные эвристики на практике устойчивее пропускали более предсказуемый, привычный для них профиль трафика. Это полевое эксплуатационное обходное решение, а не академическое доказательство того, что TLS 1.3 «сломал интернет». Более того, Cloudflare вместе с RFC-документацией считают TLS 1.3 более новой, более безопасной версией; значит, откат до TLS 1.2 надо рассматривать как временную меру на граничном узле, а не как желаемое долгосрочное состояние.

Для удобства сравнения приведена таблица.

Основание для таблицы — RFC 9113, RFC 9114, RFC 9000/9001, RFC 8446/6066/9849, а также рекомендации хостинг-провайдеров июня 2026 года.

Практические варианты смягчения с примерами конфигурации

Ниже приведена сравнительная матрица. Оценка трудозатрат/результативности — редакционная, но опирается на июньские сообщения хостинг-провайдеров, протокольные особенности HTTP/TLS, текущую документацию вендоров сетевого стека.

HTTP/2 на граничном узле вместе с временным ограничением до TLS 1.2

Именно эта связка чаще всего фигурирует в июньских рекомендациях хостинг-провайдеров. FirstVDS совместно с 1dedic советовали использовать HTTP/2 как основной режим, избегать HTTP/1.1 в качестве публичного доминирующего пути, на фронтальном прокси-сервере отключать TLS 1.3, оставляя TLS 1.2. Для NGINX HTTP/2 поддерживается модулем ngx_http_v2_module; версии TLS задаются директивой ssl_protocols; для HTTP/2 по TLS нужен ALPN, появившийся в OpenSSL 1.0.2+. Для Apache HTTP/2 включается через директиву Protocols, а модуль mod_http2 отдельно подчёркивает требование «современного TLS», включая TLS 1.2+.

Минимальный пример для NGINX / NGINX Plus + OpenSSL.

server {
    listen 443 ssl;
    http2 on;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Временное обходное решение на публичном граничном узле
    ssl_protocols TLSv1.2;

    location / {
        proxy_pass https://10.0.0.10:443;
        proxy_ssl_server_name on;
        proxy_ssl_name example.com;
        proxy_ssl_trusted_certificate /etc/nginx/backend-ca.pem;
        proxy_ssl_verify on;
    }
}

Проверка сборки вместе с согласованным протоколом для NGINX/OpenSSL.

nginx -V 2>&1 | tr ' ' '\n' | egrep 'OpenSSL|http_v2_module'
openssl version
curl -Ivs --http2 --tlsv1.2 https://example.com/
openssl s_client -connect example.com:443 -servername example.com -tls1_2 -alpn h2 </dev/null

Для Apache HTTP Server.

<VirtualHost *:443>
    ServerName example.com

    SSLEngine on
    SSLCertificateFile    /path/fullchain.pem
    SSLCertificateKeyFile /path/privkey.pem

    # Временное обходное решение на граничном узле
    SSLProtocol -all +TLSv1.2

    # На практике это «HTTP/2 предпочтительно»,
    # а не жёсткая фиксация для любого клиента
    Protocols h2 http/1.1

    ProxyPass        / https://10.0.0.10/
    ProxyPassReverse / https://10.0.0.10/
</VirtualHost>

Для Caddy важно знать ограничение — документация прямо указывает, что при включённом HTTP/2 стандартная библиотека Go не позволяет отключить HTTP/1.1. То есть строгий «только h2» в буквальном смысле здесь недоступен; зато можно убрать h3, оставить h1 h2, а TLS ограничить до версии 1.2 на публичной стороне.

{
    servers :443 {
        protocols h1 h2
    }
}

example.com {
    tls {
        protocols tls1.2 tls1.2
    }

    reverse_proxy 10.0.0.10:443 {
        transport http {
            tls
            tls_trust_pool file /etc/caddy/backend-ca.pem
            tls_server_name example.com
            versions 1.1 2
        }
    }
}

Для HAProxy конфигурация обычно строится по принципу «анонсировать h2 через ALPN, сохранить запасной h1, ограничить версию TLS». HAProxy официально поддерживает HTTP/2 по HTTPS; ALPN нужен для h2,http/1.1; минимальную с максимальной версии TLS задают ssl-min-ver, ssl-max-ver.

frontend fe_https
    mode http
    bind :443 ssl crt /etc/haproxy/certs/example.pem \
        alpn h2,http/1.1 \
        ssl-min-ver TLSv1.2 ssl-max-ver TLSv1.2
    default_backend be_app

backend be_app
    mode http
    server app1 10.0.0.10:443 ssl verify required \
        ca-file /etc/haproxy/backend-ca.pem \
        sni str(example.com) \
        alpn h2,http/1.1

Для Cloudflare картина сложнее. Можно отключить HTTP/3 для посетителей, включить HTTP/2 к серверу-источнику, ограничить минимальную версию TLS до 1.2; можно также отключить TLS 1.3 на граничном узле. Но считать Cloudflare «строго только HTTP/2» входным слоем для посетителей нельзя — документация прямо описывает запасной механизм HTTP/1.1 наряду с отдельной логикой согласования между граничным узлом с сервером-источником. Если цель — именно «минимум всплесков рукопожатий к серверу-источнику», Cloudflare полезен прежде всего как мультиплексирующий слой H2 между граничным узлом с сервером-источником.

Практически это означает следующий набор настроек в панели управления Cloudflare.

Speed → Settings → Protocol Optimization → HTTP/3 = Off
Speed → Settings → Protocol Optimization → HTTP/2 to Origin = On
SSL/TLS → Edge Certificates → Minimum TLS Version = 1.2
SSL/TLS → Edge Certificates → TLS 1.3 = Off   # только как временная мера

Если нужно, чтобы Cloudflare меньше распараллеливал запросы к серверу-источнику, обратите внимание на параметр origin_h2_max_streams — на тарифе Enterprise его можно уменьшать. Cloudflare также уважает заголовок SETTINGS_MAX_CONCURRENT_STREAMS, который анонсирует ваш сервер-источник. Это полезный рычаг, если вы уже стоите за Cloudflare, но опасаетесь, что агрессивное мультиплексирование перегрузит серверную часть.

Плюсы данной связки мер — быстро внедряется, согласуется с полевым опытом хостинг-провайдеров, чаще всего даёт наибольший шанс на немедленное улучшение. Минусы — TLS 1.2 является понижением уровня по сравнению с TLS 1.3; кроме того, выражение «только HTTP/2» в реальной эксплуатации нередко означает «HTTP/2 предпочтительно, без HTTP/3», потому что часть стеков сохраняет осмысленный запасной переход на HTTP/1.1.

Отключение QUIC вместе с HTTP/3

Как экстренный шаг это почти всегда стоит сделать первым. Cloudflare прямо указывает, что HTTP/3 использует QUIC; NGINX имеет quic-параметр в listen; HAProxy включает HTTP/3 через bind quic4@:443; хостеры 1dedic совместно с FirstVDS в своих рекомендациях советовали не использовать QUIC/HTTP/3 на публичном фронте, держать наружу классическую схему TCP/443 → TLS 1.2 → HTTP/2.

Если у вас NGINX, уберите QUIC-слушатель, не публикуйте заголовок Alt-Svc для h3. Если у вас HAProxy, не добавляйте bind quic4@:443, не ставьте заголовок alt-svc 'h3=":443"'. Если у вас Cloudflare, переведите HTTP/3 в Off на граничном узле. Если перед ресурсом собственный межсетевой экран, можно временно закрыть UDP/443.

Временный сетевой пример для межсетевого экрана Linux.

# nftables
sudo nft add rule inet filter input udp dport 443 drop

# или iptables
sudo iptables -I INPUT -p udp --dport 443 -j DROP

Плюсы — быстро, безопасно откатывается, обычно не ломает ресурс целиком. Минусы — теряете преимущества HTTP/3 на мобильных/нестабильных сетях, а если у вас агрессивно кэшировался заголовок Alt-Svc, часть клиентов может кратковременно продолжать попытки соединения по H3 до обновления состояния.

Снижение параллельности запросов, разветвления загрузки страницы

Эта мера полезна там, где нет возможности быстро поменять сеть, IP или сетевой стек фронтальной части. Она не фигурирует как отдельный официальный протокольный стандарт, но прямо вытекает из общей логики рекомендаций хостинг-провайдеров — меньше отдельных соединений, меньше одновременных установок — меньше шанс спровоцировать фильтрационный триггер на всплеск. Именно поэтому FirstVDS совместно с 1dedic подталкивали к HTTP/2, к отказу от HTTP/1.1 как публичной основы.

Практически это означает следующее.

• Включить отложенную загрузку для медиа, для изображений ниже первого экрана.
• Сократить число доменов-источников на странице.
• Объединить мелкие CSS/JS-файлы, где это ещё рационально.
• Убрать лишние сторонние виджеты, шрифтовые зависимости.
• Включить долгий кэш для статических ресурсов.
• Снизить одновременный запросный шквал на сервер-источник через CDN/прокси, через настройки приложения.

Это не устраняет проблему SSH/RDP, не заменяет исправление на уровне сетевой фронтальной части, но для сценария «только сайт, только страница разваливается частями» часто даёт измеримое улучшение уже в первые сутки. Основной риск — начать бороться не с причиной, а с симптомом, параллельно усложняя конвейер фронтальной доставки. Поэтому снижение разветвления — хороший второй шаг, но плохая единственная стратегия.

Обратный прокси-сервер перед серверной частью

Это один из наиболее зрелых эксплуатационных подходов. Хостинг-провайдеры прямо советовали ставить перед ресурсом отдельный фронтальный прокси-сервер — клиент приходит на внешний прокси, а тот уже обращается к серверной части. Смысл здесь двойной — меняется внешний сетевой профиль ресурса, появляется возможность отдельно управлять HTTP/2/TLS 1.2 на фронтальной стороне, не перепиливая приложение. Selectel в смежной документации также прямо проводит линию между разделяемым IP, выделенной подсетью, выделенным входом.

Что важно сделать правильно.

• Фронтальная часть должна принимать публичный трафик на выделенном IP либо в выделенной публичной подсети, а не на разделяемом/плавающем адресе, если у вашего провайдера есть такое различие.
• Серверную часть желательно не оставлять публичной точкой входа.
• Если между прокси-сервером с серверной частью используется HTTPS с собственным сертификатом — настройте нормальную валидацию CA/SNI, а не insecure skip verify.
• Не создавайте циклическую переадресацию HTTP→HTTPS на серверной части, если схема терминации TLS уже изменилась.

Для самостоятельно размещённого фронтального узла самый прагматичный путь — NGINX, Caddy или HAProxy с конфигурацией из предыдущих блоков. Для варианта со сторонним провайдером — CDN-сервис уровня Cloudflare или российский эквивалент, если нужна география, Anycast, быстрое сокрытие сервера-источника. Но в стороннем случае отдельно оцените следующее.

• Где реально терминируется TLS.
• Нужен ли вам российский IP / российская локация.
• Можно ли получить выделенный адресный ресурс.
• Не создадите ли вы себе новые ограничения нормативного соответствия для конкретного бизнеса.

Смена хостинга, смена IP, выделенная подсеть, процедуры включения в белый список

Смена IP иногда помогает — это признают FirstVDS, Selectel. Но обе стороны подчёркивают, что гарантии нет — сегодня заработало, завтра проблема вернулась. Если фильтрация применяет правила не к одному адресу, а к пулу/подсети/типу адреса, простая смена IP может быть только временной передышкой.

Более осмысленный вариант — уход с разделяемого/публичного плавающего IP на адрес, выделенный исключительно под ваш сервис. В документации Selectel это разложено предельно практично — процедуры включения в белый список требуют, чтобы IP находился в РФ, был выделен исключительно под ваш ресурс; разделяемые/публичные плавающие/публичные прямые IP для этого не подходят, а для VDS-серверов такой тип адреса вообще может быть недоступен, поэтому провайдер прямо советует облачный сервер в публичной подсети либо выделенный сервер.

Здесь важно не смешивать две разные административные дорожки.

Первая — операторско-хостерская эскалация по ТСПУ. Selectel рекомендует собрать диагностику, открыть тикет, а если подозрение на влияние ТСПУ подтверждается, обращаться к оператору связи; при необходимости оператор может подать заявление в личном кабинете владельца технологической сети. Сразу оговорено — это не гарантирует решение.

Вторая — включение в белый список для периодов ограничений мобильного интернета, о котором Selectel пишет отдельно. Там запрос подаётся в Минцифры; подать его может только владелец — юридическое лицо либо индивидуальный предприниматель; IP должен соответствовать требованиям выделенности, локации в РФ. Это не универсальная «кнопка от всех ложных блокировок», а отдельный административный режим доступа.

Клиентские обходные решения

Клиентские обходные решения — это не стратегия владельца ресурса, а мера поддержки для тех, кто уже не может зайти на сайт. Хостинг-провайдеры в июне 2026 года чаще всего советовали три вещи — попробовать Firefox вместо браузеров на движке Chromium, сменить сеть доступа, в отдельных рекомендациях — отключить QUIC/HTTP/3 в браузере. Beget совместно с FirstVDS прямо упоминали Firefox; 1dedic — отключение QUIC через chrome://flags/#enable-quic.

С точки зрения владельца ресурса эту меру стоит подавать честно — она полезна для службы поддержки, но не масштабируется на всех пользователей, плохо контролируется вами, не решает доступность для платёжных сценариев, CRM, личных кабинетов, SEO-трафика. VPN как пользовательский обход тоже работает только на стороне пользователя, потому не может считаться планом восстановления для ресурса. Если ресурс нужен бизнесу, чинить нужно граничный узел с сетевой архитектурой, а не надеяться, что все клиенты сами включат правильный флаг в браузере.

Диагностика, мониторинг, тестирование из разных сетей РФ

Минимальный контрольный перечень проверки из нескольких сетей РФ выглядит следующим образом. Проверьте ресурс минимум из следующих точек.

1. Один проводной домашний провайдер.
2. Один мобильный оператор.
3. Одна альтернативная фиксированная сеть либо офисный канал.
4. Одна контрольная точка вне РФ или через независимый внешний зонд, чтобы отделить проблему сервера-источника от проблемы российского пути.

Для каждой точки сохраните результаты следующих команд.

# DNS
nslookup example.com

# ICMP
ping -c 4 example.com

# Маршрут
traceroute example.com
# или
mtr -bwzrc 100 example.com

# HTTPS: сравнить HTTP/2 с TLS 1.2
curl -Ivs --http2 --tlsv1.2 https://example.com/

# HTTPS: принудительно HTTP/1.1 для сравнения
curl -Ivs --http1.1 --tlsv1.2 https://example.com/

# TLS-рукопожатие, ALPN
openssl s_client -connect example.com:443 -servername example.com -tls1_2 -alpn h2 </dev/null

Поддержка самих инструментов тут тоже документирована. У curl есть штатные опции --http2, --tlsv1.2; openssl s_client является официальным диагностическим SSL/TLS-клиентом, поддерживает параметры -tls1_2, -tls1_3, -servername, -alpn.

Для браузерной диагностики полезно сохранить сетевой лог на стороне клиента. Для Chrome совместно с Edge корпорация Microsoft описывает NetLog через chrome://net-export, edge://net-export; этот лог особенно полезен, когда вы хотите сопоставить реальные сетевые события, согласованный протокол, DNS, поведение на уровне сокетов, а не только видеть «страница не открылась». Параллельно в инструментах разработчика полезно смотреть, не загружается ли сам HTML-документ или уже статические ресурсы после начального документа.

Если ресурс стоит за CDN/обратным прокси-сервером, обязательно отдельно проверьте следующее.

• Согласованный протокол на граничном узле.
• Согласованный протокол от граничного узла к серверу-источнику.
• Не остался ли заголовок Alt-Svc для h3.
• Сколько параллельных потоков допускает сервер-источник.
• Не происходит ли неожиданный откат на HTTP/1.1.

Cloudflare прямо документирует поддержку HTTP/2 к серверу-источнику, ограничение параллельных потоков, поведение совместимости с сервером-источником.

Заключение

Июнь–июль 2026 года стали для российского хостинг-рынка периодом массового столкновения с побочными эффектами систем глубокой инспекции трафика — ТСПУ. Ключевой итог этого периода можно сформулировать в нескольких тезисах.

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

Инженерное сообщество пришло к устойчивому консенсусу относительно мер смягчения, хотя внутренний алгоритм ТСПУ официально не раскрыт. Связка HTTP/2 на граничном узле, отключение QUIC/HTTP/3, временное ограничение до TLS 1.2 при размещении на выделенном IP — вот набор практических мер, подтверждённых полевым опытом нескольких независимых провайдеров. Эти меры не являются гарантированным решением, но существенно снижают вероятность ложного срабатывания фильтрации.

Важно различать уровни реагирования. Экстренные меры на уровне протоколов (отключение QUIC, настройка TLS 1.2) решают острую фазу проблемы. Архитектурные меры — вынос обратного прокси-сервера на выделенный IP, разделение фронтальной части с серверной — обеспечивают более устойчивую защиту. Административные процедуры включения в белый список через операторов связи либо Минцифры дополняют техническую сторону, однако имеют собственные ограничения по срокам, требованиям, гарантиям.

Клиентские обходные решения — смена браузера, отключение QUIC в настройках — полезны исключительно как мера поддержки для конечных пользователей. Они не заменяют исправление на стороне серверной инфраструктуры, не масштабируются на массовую аудиторию. Владельцу ресурса, критичного для бизнеса, необходимо сосредоточиться на серверных мерах — настройке граничного узла, сетевой архитектуре, регулярном мониторинге доступности из разных точек РФ.

Ситуация продолжает развиваться. Рекомендации, актуальные на момент написания этого материала, могут потребовать корректировки при изменении параметров фильтрации. Поэтому ключевым элементом стратегии остаётся постоянный мониторинг — регулярное тестирование ресурса из различных операторских сетей, отслеживание обновлений в документации хостинг-провайдеров, готовность оперативно корректировать конфигурацию сетевого стека.