В начале июня 2026-го года сообщество в очередной раз проявило беспокойство: у многих "отвалились" их средства обхода блокировок, в т.ч. построенных на классической базе: xray + VLESS + REALITY. Был произведен реверс-инжиниринг внутреннего устройства проблемы, и в данной статье будет описан алгоритм искомой волны ограничений.
Алгоритм ограничений
По своей сути это напоминает "сибирскую блокировку", но параметры стали более жесткие, а охват более широкий. Применяется как на мобильных, так и домашних провайдерах.
Работы алгоритма не опирается напрямую на конкретные IP адреса промежуточных узлов в сети (напр., ваших серверов). Что, в общем-то, неплохо — ведь это означает, что оные узлы не улетели в некий черный список. Особенно в свете того, что некоторые приложения "стучат". Однако, плохая новость в том, что затронуты целые подсети и даже AS, в т.ч. и популярных российских дата-центров (напр., Selectel, Яндекс.Облако, Cloud.ru и др.), что заметно отличается от методов, которые затрагивали только зарубежных провайдеров — tcp 16-20 (aka l4-25) и проч.; такие подсети далее будем называть "подозрительными".
Дело в том, что цензор оценивает ClientHello при TLS handshake для каждого TLS соединения. Среди прочего, он учитывает такие атрибуты:
IP адрес сервера (точнее: его подсеть, AS или ещё более широкий "сетевой" признак);
SNI (Server Name Indication);
Фингерпринт "браузера" (точнее того, кто пытается под него мимикрировать, что и делает в т.ч. Reality через uTLS).
На их основе действует алгоритм (если ответ на любой вопрос ниже "нет" — пропускаем трафик без ограничений, если "да" — анализируем дальше по цепочке):
IP адрес сервера является подозрительным?
Фингерпринт "браузера" является подозрительным? Таковыми, в среднем, являются отпечатки от: Chrome, Safari, и iOS (при этом, Firefox, Android OkHttp, Edge, 360 Browser, QQ Browser — пока что проходят у большинства операторов);
Было ли более 3 параллельных попыток установить TLS соединение к серверу (т.е. с задержкой между ними менее ~350-400 мс) в течение последних 60 секунд? И это в рамках одного SNI, т.е. его смена "обнуляет" кол-во/меняет контекст. Здесь также стоит заметить, что десятки подключений одновременно — типично для различных клиентов для обхода ограничений, особенно если не используется mux и проч.
Итак, если ответ на последний вопрос положительный, то все текущие и дальнейшие попытки соединений замораживаются на 120 секунд. Могут успевать проходить некоторые этапы TLS хендшейка (в т.ч. вплоть до получения ServerHello), но не более.
При этом, интересный нюанс: если вы таки добились заморозки на 120 секунд (что, конечно, не очень сложно), и попытаетесь сменить фингерпринт "браузера" (в т.ч. на "неподозрительный"), то вы дополнительно поймаете блокировку на 600 секунд. В течение этого времени замораживаются любые TLS соединения (TCP всегда коннект проходит), вне зависимости от фингерпринта и SNI. Схематично всё это можно представить примерно так:
Что касается того, о каких версиях HTTP и TLS идет речь:
TLS 1.2 / 1.3 — оба подвержены этому ограничению;
HTTP/1.1 или HTTP/2 — без разницы, все ограничивается. Однако, в случае HTTP/2 браузер обычно ограничивается одним соединением в рамках scheme + host + port, поэтому "серфинг" в этом случае должен пострадать заметно меньше.
Насколько можно судить, цензор вообще не оценивает ServerHello (а значит не знает, какие версии в итоге были выбраны). А что касается ClientHello — помним, что учитываются браузерные фингерпринты и есть некий их черный список (иначе ограничения не применяются), а все современные браузеры в начале TLS хендшейка "декларируют" поддержку TLS 1.3 и HTTP/2. При попытке изменить это поведение вы поменяете фингерпринт.
Субъективная оценка
Использование обсуждаемого метода ограничений, особенно с такими суровыми параметрами, выглядит довольно сомнительно и тревожно, по меньшей мере потому что он работает слишком грубо. Например, могут не открываться многие вполне легитимные веб-сайты (во вполне легитимных браузерах), которые хостятся в т.ч. в РФ дата-центрах. А при смене браузера (вместе с ним меняется и фингерпринт) ненароком можно получить "длинную" заморозку запрошенного сервиса. То есть, это деструктивно влияет в т.ч. и на работу "суверенного" сегмента сети — Рунета.
Однако, есть некоторая вероятность, что параметры ограничений будут смягчены в дальнейшем — похожее поведение уже наблюдалось, напр., в конце 2025-го года.
Что делать
В силу известных нюансов, нельзя что-то посоветовать, решать вам. Однако, для информации и сугубо гипотетически: пока что достаточно нарушить любое из условий цепочки алгоритма выше (напр., подобрать лояльный фингерпринт) чтобы обсуждаемый метод ограничений не применялся. Естественно, что в зависимости от региона, провайдера и с течением времени описываемые в статье значения параметров (тайминги, подсети и т.д.) могут немного отличаться.
Кстати, утилита dpi-ch (в рамках проекта dpi-checkers) была адаптирована к этому виду ограничений:
В версии v0.7.0 был добавлен соотв. субчекер в рамках webhost checker для анализа на предмет данного ограничения — результат его работы можно найти в колонке "Siberian" (на это название вдохновил @0ka когда-то) в табах Infrastructure Providers и Popular Web Services;
В версии v0.8.0 в штатной конфигурации была добавлена новая секция "Russian Infrastructure Providers" (в отдельном табе), а старая переименована в "Foreign Infrastructure Providers". Таким образом можно будет удобно проверять популярных российских провайдеров инфраструктуры, не меняя конфигурацию. Также теперь можно создавать свои собственные секции, группируя результаты субчекера webhost.
Важно отметить, что помимо штатной конфигурации, в .yaml конфиге можно задать любые интересующие вас подсети (вплоть до одного IP адреса; а также по многим другим признакам: ASN, название организации, доменное имя и т.д.).
Пример результатов на одном из домашних интернет-провайдеров для популярных российских инфраструктурных операторов:
Можно заметить, что картина довольно "любопытная". А для зарубежных операторов не забывают и про tcp 16-20, что практически полностью парализует их работу (по крайней мере, без дополнительных контрмер):
Такие дела, спасибо за внимание!
С уважением,
Петр.
