Полгода назад я написал здесь разбор «почему VLESS работает» — он собрал 169 тысяч просмотров и под тысячу закладок. Я тогда уверенно заявил: REALITY не отличить от обычного HTTPS, поэтому он держится там, где всё остальное давно отвалилось. Прошло полгода — и оказалось, что я был прав ровно наполовину.

В феврале ТСПУ перешёл на поведенческий анализ, а в июне — на то, что в чатах называют «заморозкой по fingerprint». И тут разом перестали подключаться мои собственные конфиги — и конфиги тысяч других людей. Приложение бодро рапортует «connected», а трафика нет. А привычный совет «обнови клиент» вдруг превратился в пустой звук.

Вот я и вернулся — посмотреть, что осталось от моих же выводов. Это разбор со стороны клиентского устройства — угла, который обычно недозанят. Что на самом деле творится в телефоне, когда «всё зелёное, а интернета нет». Как устроена новая детекция. И как измерить её самому, чтобы не потерять доступ к легальным сервисам, которые попали под ложные срабатывания.

Пара слов о том, чему верить. Тема скользкая, источников мало, и я не хочу делать вид, что у меня на руках спецификация системы. Поэтому дальше честно помечаю, где у меня твёрдый пруф, а где — реконструкция по одному источнику. Самое важное сразу: ядро всей новой схемы (разделы 2–4) собрано по одному структурированному первоисточнику — посту в Obsidian/Zapret, где автор разбирает поведение через инструмент dpi-ch. Это не выписка из документа РКН и не консенсус исследователей ТСПУ. Академические работы (ensafi/IMC 2022, gfw.report) такой схемы вообще не описывают — как и кодового имени, под которым она ходит в обсуждениях. Так что всё про конкретные пороги — «>3 хендшейка», «350–400 мс», «120/600 с» — это инженерная реконструкция чёрного ящика по одному наблюдению, а не доказанное устройство системы. Числа читайте как рабочие гипотезы.

1. Что случилось в июне: от сигнатур к поведению

Июньский сдвиг готовился не один месяц, так что сначала пройдёмся по волнам — иначе будет непонятно, откуда всё выросло.

До 2024. ТСПУ работала по сигнатурам: фиксированные байтовые паттерны в начале потока, SNI-списки, IP-блоклисты. OpenVPN ловился по характерному хендшейку, WireGuard — по детерминированной структуре handshake-сообщений (Handshake Initiation 148 байт, Handshake Response 92 байта — это свойства самого протокола, привожу для контекста, не как параметр ТСПУ). Дёшево по CPU и тупо в лоб.

Ноябрь — декабрь 2025. Пошли первые региональные волны по VLESS: в ноябре Татарстан, Удмуртия, Нижегородская область; в декабре докатилось до Свердловской. Тогда же ТСПУ получила обновление и начала использовать косвенные признаки вместо прямых сигнатур — в зону активного детектирования попали SOCKS5, VLESS, L2TP [факт, digirpt.com, multihop.ru].

17 февраля 2026. Массовая блокировка связки VLESS+Reality поверх голого TCP на проводных операторах (Dom.ru, Skynet, Ростелеком). Паттерн характерный: первые ~16 KB проходят нормально, дальше — заморозка (это февральское наблюдение Habr 1000694; отдельный, более поздний замер net4people #490 даёт порог ~15–20 KB / ~25 пакетов — это другое событие и другой замер, см. раздел 5, путать не надо). SSH через порт 22 живёт, VLESS на 443 — нет. На том же устройстве мобильный LTE (Билайн, МТС) ещё работает [факт, Habr 1000694, digirpt.com]. Важная оговорка из комментариев на Habr: один пользователь зафиксировал полный отказ VLESS только с 18 марта — то есть 17 февраля это начало волны, а не единый глобальный рубильник.

21–22 мая 2026. Первые тестовые прогоны нового поведенческого модуля. В обсуждениях он ходит под прозвищем «Siberian», с отсылкой к посту исследователя П. Осетрова. Подчеркну отдельно: и имя, и атрибуция, и параметры схемы — из одного источника (Zapret/Obsidian). Другие документы тот же эффект описывают, но модуль так не зовут и автора не упоминают. Зондирующие окна — 21:00–00:00 и 11:00–12:00 на следующий день, география ограниченная. Полигоном стали Москва и Сибирь [один источник по схеме; факт тестовых окон — mentoday.ru]. Главное отличие схемы — срабатывает она не по содержимому пакетов, а по пересечению нескольких поведенческих сигналов одновременно.

25 мая 2026. Развёртывание по Сибири и Москве. Новосибирская обл. — 13% жалоб, Томск и Кемерово — по 9%, Омск — 6%, Иркутск — 5%. Под раздачу попали VLESS, Xray, MTProto, WireGuard, gRPC. SSH не тронули [факт, mentoday.ru, Techora].

5 июня 2026. Третья и самая крупная волна. Около 07:00 МСК (на Дальнем Востоке наблюдатели фиксируют уже с 00:00 МСК) одновременно посыпалось всё: массовый сбой сайтов на Beget, TimeWeb, Selectel, SpaceWeb, AdminVPS, Reg.ru — тысячи сайтов частично недоступны, сисадмины теряют SSH/RDP к своим серверам; блокировка MTProto-прокси Telegram (у Билайна и МегаФона связь восстанавливалась на 1–2 часа, потом отваливалась через 20–30 минут); просадка трафика облачных сервисов. Особенно показателен кейс Delta Chat: ТСПУ заблокировала TLS-соединения с JA3-отпечатком Rust-библиотеки ring и сломала почту на Beget и Timeweb. 6 июня разработчики выкатили PR, заменив ring на aws-lc-rs, а 7 июня Timeweb признал проблему [факт, eByeBots, allslava.com, techora.ru].

2 июня 2026 — и тут же отдельный инфраструктурный фактор, к ТСПУ вообще не относящийся: европейский ДЦ nLighten без предупреждения обесточил стойки. О нём подробно в разделе 7, и сразу подчеркну: смешивать его с «заморозкой по fingerprint» — методологическая ошибка.

Почему «обнови клиент» перестало помогать. Раньше, при сигнатурной фильтрации, подмена JA3-отпечатка через uTLS решала всё: поменял подпись — проскочил. Теперь подпись — лишь один сигнал из нескольких. Хуже того: смена fingerprint, когда заморозка уже наступила, по тому же единственному источнику не просто не помогает, а раздувает штраф со 120 до 600 секунд [один источник, Habr 1044396]. Система перестала заглядывать внутрь пакета. Теперь она считает снаружи.

2. Сигналы решения ТСПУ при TLS-handshake

Это ядро всего разбора — и здесь оговорка из шапки работает на полную. Всё, что ниже, — реконструкция по одному источнику (Habr 1044396 на основе наблюдений через dpi-ch), а не официальная спецификация. По этой реконструкции заморозка срабатывает только при одновременном выполнении нескольких условий — логическое AND. И это принципиально: каждый сигнал по отдельности встречается и у честного трафика, мишенью предположительно служит именно их совпадение.

Сигнал 1: AS/подсеть сервера

ТСПУ смотрит на destination IP того TCP-соединения, которое вы инициируете, и сверяет его с базой «подозрительных» CIDR/ASN.

• зарубежные ДЦ (Hetzner, DigitalOcean, OVH) — давно;

• ряд российских облачных провайдеров — с конца мая / начала июня 2026. Вот отсюда и растёт коллатеральный ущерб для российских проектов: туда же хостятся реальные прокси-серверы, ТСПУ их не разграничивает, и весь трафик к подсети уходит на поведенческую проверку.

А вот про имена — осторожно. В обсуждениях в «подозрительный» список заносят Selectel, Yandex.Cloud, Cloud.ru. К этим именам я отношусь с холодком: «совпадение нескольких источников» здесь — это перепечатывающие друг друга телеграм-каналы (digirpt, multihop, mentoday), а не независимые tcpdump-замеры. Yandex.Cloud — системообразующий провайдер, за которым стоит изрядная доля рунета; его попадание в список поведенческой заморозки — заявление экстраординарное, и пруф ему нужен уровня пакетного дампа, которого в открытом доступе попросту нет. Итого: коллатеральный ущерб для российских облаков виден [факт по симптому, eByeBots], но конкретный поимённый состав списка — [один источник / непроверено]. Я и сам прогнал 12-часовой замер с RU-машины (Ростелеком, AS34168, 72 цикла, 14 июня) к GitHub/PyPI/Fastly: ни одной заморозки, медиана TLS-хендшейка ~135 мс, доступность 99–100%. Это вполне согласуется с выборочностью списка — на одном операторе в эти часы всё проходило чисто. А значит, поимённый состав «подозрительных» ASN тем более требует дампа, а не перепечаток.

Один этот критерий заморозку не вызывает — нужна комбинация. Крупные CDN (Cloudflare, Akamai, Google) в «подозрительный» список целиком не входят: иначе легла бы половина легального рунета [анализ]. Отсюда, кстати, и живучесть CDN-индирекции как архитектурного приёма. Блокировки подсетей Cloudflare в этот период случались, но это отдельный вектор (история с ECH тянется ещё с ноября 2024), а не описываемая схема.

Чего точно не знаю: как устроена сама база и как она обновляется — централизованно из ЦМУ ССОП или локально на операторском железе. По архитектуре ТСПУ (Habr 1027012) управление централизованное, а реализация размазана по операторским DPI-узлам — это и объясняет, почему в разных регионах всё работает по-разному.

Сигнал 2: TLS-fingerprint клиента (JA3/JA4)

Первым незашифрованным сообщением при TLS-соединении летит ClientHello — на нём и происходит фингерпринтинг.

JA3 (исторический стандарт): MD5-хэш от конкатенации пяти полей ClientHello — SSLVersion,Cipher,SSLExtension,EllipticCurve,EllipticCurvePointFormat (так они названы в оригинальной спецификации Salesforce). Тут важна точность насчёт GREASE: в каноническом JA3 GREASE-значения (0x?A?A) попадали в хэш и были источником нестабильности; их исключение появилось позже — в JA3N/JA4, а не в JA3 «вообще». Отдельная боль JA3: начиная с Chrome 110 и Firefox 114 браузеры рандомизируют порядок TLS-расширений, и одна и та же версия Chrome выдаёт разные JA3 при каждом соединении [факт]. Для опознания конкретной версии браузера JA3 стал бесполезен, но для грубого «это вообще не браузер» по-прежнему годится: нестандартный TLS-стек видно независимо от рандомизации.

JA4 (FoxIO, 2023): сортирует cipher suites и extensions перед хэшированием — тем самым гасит рандомизацию порядка; GREASE по спеке исключается. В формат входят версия TLS, ALPN, число расширений. Разберём пример t13d1516h2_8daaf6152771_b0da82dd1658: t — транспорт TCP, 13 — TLS 1.3, d — SNI присутствует (domain), 15 — 15 cipher suites, 16 — 16 extensions, h2 — ALPN h2; дальше два усечённых SHA256-хэша (от отсортированных cipher suites и от extensions+signature algorithms). А вот signature algorithms намеренно НЕ сортируются — их порядок несёт информацию о библиотеке [факт, FoxIO JA4 spec].

Почему fingerprint, имитирующий Chrome/Safari/iOS, оказался «подозрительным». Сами браузеры, очевидно, легитимны. Проблема в том, что подделанный fingerprint не бьётся с поведением и контекстом:

1. Стандартная Go-библиотека crypto/tls имеет статичный предсказуемый профиль: нет GREASE, фиксированный порядок extensions, отсутствуют ALPS/brotli/ECH. Это резко не браузер. Прокси-операторы массово маскировали это через uTLS с шаблоном Chrome — и Chrome-fingerprint стал самым частым среди клиентов в «подозрительных» подсетях. ТСПУ, по реконструкции, оценивает метку контекстно: Chrome-профиль на Hetzner — подозрительно; Chrome на google.com — норма [один источник по механике, анализ по интерпретации].

2. uTLS-имитация устаревшей версии (скажем, Chrome 105 при актуальной 124) даёт несоответствие порядка cipher suite/extension и GREASE-паттерна реальному Chrome [Habr 1009542].

3. Реальный браузер после хендшейка генерирует специфичные паттерны — API-запросы, тайминги, ALPN. А туннель — это непрерывный двунаправленный поток без характерных пауз и смены размеров пакетов.

Отдельно про post-quantum key_share (X25519MLKEM768). Иногда его отсутствие предлагают как маркер «не-браузер». Это слабый дискриминатор, и подаю я его именно так: PQ key_share в 2026 не шлёт огромная доля совершенно легитимного трафика — старые Android, не-Chromium браузеры, мобильные и корпоративные TLS-стеки. Детектор «нет PQ → прокси» гарантированно выдал бы вал ложных срабатываний — ровно тот коллатеральный ущерб, на который жалуется раздел 3. Так что отсутствие PQ — в лучшем случае слабый довесок к контексту, а не самостоятельный признак [анализ].

«Лояльные» fingerprints, по наблюдениям пользователей в июне 2026: Firefox, Edge, Android-стек (Conscrypt/BoringSSL), 360 Browser, QQ Browser — они реже встречаются в прокси-конфигах. Это наблюдаемый эффект; а вот сам механизм whitelist и конкретный список — гипотеза из практики, а не задокументированный РКН-перечень. Не читайте это как «установленный белый список».

И ещё про точность формулировок: «Chrome/Safari подозрительны» означает конкретный fingerprint, имитирующий эти браузеры через uTLS из «подозрительной» подсети, а не сами браузеры в живой пользовательской сессии.

Сигнал 3: Частота параллельных хендшейков

Реконструированный порог: больше 3 параллельных TLS-соединений к одному SNI с малой задержкой между ними → заморозка ~120 с. И тут сама фактура сама себе противоречит: в одном источнике временное окно описано как залп < ~350–400 мс, в другом — как окно 60 секунд. Фиксирую оба варианта и не выбираю между ними [один источник Zapret/Obsidian + Habr 1044396; инженерное наблюдение, не официальная константа].

Почему это прокси-специфичный паттерн. VLESS-клиенты (Happ, v2rayTun, Hiddify) по умолчанию используют мультиплексирование (XMUX/Mux) или connection pooling — на старте туннеля открывают сразу несколько параллельных TCP/TLS ради снижения latency. Браузер тоже открывает параллельные соединения, но к разным хостам (подресурсы страницы), а не 4–8 одновременных хендшейков к одному SNI/IP подряд. Обычный пользователь, открывая условный сайт, делает 1–2 соединения к CDN-IP, а не 6 к одному узлу.

Что происходит, когда совпали все условия (по реконструкции):

• Трафик к узлу замораживается на ~120 секунд.

• Это не RST и не FIN, а packet drop / blackholing. Клиент шлёт пакеты, ответ дропается на стороне ТСПУ. Аналогичный по сути механизм задокументирован для GFW (Китай), но не для ТСПУ: после триггера GFW дропает все пакеты с тем же (client IP, server IP, server port) на 120–180 секунд [факт, GFW USENIX 2023]. Подчеркну отдельно: число «120–180 с» — китайское, по GFW; близость российской ~120 с — наблюдательное совпадение по одному источнику, а не перенос китайской константы на ТСПУ как доказанной.

• Выглядит это как «плохой интернет», а не как явная блокировка: растёт RTT, падает throughput.

• Попытка быстро сменить fingerprint под нагрузкой, по реконструкции, добавляет расширенный бан на 600 секунд на все TLS к этому узлу — независимо от fingerprint и SNI [один источник].

3. Сопутствующий ущерб: почему лёг легитимный рунет

Поведенческий фильтр, в отличие от сигнатурного, не знает, что именно передаётся, и реагирует на совокупность признаков. А каждый из этих признаков по отдельности водится и у честного трафика:

• Сервер в «подозрительном» ASN. Если российский ДЦ угодил в список (см. оговорку в Сигнале 1), весь трафик к нему проходит поведенческую проверку.

• Параллельные хендшейки. Тяжёлый сайт на Next.js/React при первой загрузке открывает десятки параллельных TLS-соединений. А legacy-эндпоинты на HTTP/1.1 до сих пор открывают по одному TCP на каждый запрос.

• Fingerprint клиента. Chrome — самый популярный браузер, и его профиль ровно тот, что массово имитировали прокси.

И вот пользователь Chrome открывает легальный корпоративный сайт, который живёт в облаке из «подозрительного» диапазона, условия совпадают — и на 120 секунд наступает заморозка. Сайт «лагает» или вовсе недоступен [анализ, согласуется с наблюдениями eByeBots].

Про банковские приложения нужна честность, а не нагнетание. Расхожий тезис «банки триггерят, потому что Go-подобный профиль через OkHttp» технически некорректен: OkHttp — это Java/Kotlin-клиент на Android, он использует Conscrypt/BoringSSL, и его fingerprint никакой не «Go-подобный», у него свой собственный профиль. А перечисление страшных слов (certificate pinning, QUIC 0-RTT, HTTP/2 prefetch, connection prewarming) без единого конкретного JA3 или замера — это спекуляция, а не анализ. Обоснованно сказать можно вот что: банковские приложения хостят API в облаках, агрессивно открывают несколько соединений при старте сессии и используют нестандартные (не-браузерные) TLS-стеки — то есть теоретически могут задевать те же сигналы. Но без конкретных замеров это гипотеза, а не установленный факт [гипотеза, замеров нет].

А вот кейс Delta Chat (раздел 1) — наоборот, документированная иллюстрация: TLS-отпечаток Rust-библиотеки ringсовпал с «нестандартным», и почта легла, хотя никакого прокси там и в помине нет.

Разница принципиальная. При сигнатурном подходе ложноположительный отсекается по точному байт-паттерну. При поведенческом исключать приходится по поведению, а статическое правило «>3 параллельных TLS к одному SNI» контекста не имеет — оно не отличает прокси от честного браузера. Снизить ложные срабатывания, не теряя чувствительности к настоящим целям, — задача тяжёлая. Зато для владельца легитимного сайта решение простое: включить HTTP/2 и свести весь трафик к одному мультиплексированному TLS-соединению [Habr 1045684].

4. Взгляд со стороны устройства: что происходит в телефоне при «заморозке»

Вот он, тот самый недозанятый клиентский угол. Пользователь видит «зелёный» статус клиента — сервер доступен, TCP-хендшейк прошёл, — а данные не идут. Потому что заморозка (по реконструкции) случается после завершения TCP handshake — в момент TLS handshake или сразу за ним.

Если разложить по шагам:

1. TCP SYN → SYN-ACK → ACK — проходит. Клиент считает соединение установленным (ТСПУ stateful и in-path [факт, TSPU IMC 2022, ensa.fi], TCP-уровень пропускается).

2. Клиент шлёт ClientHello (PSH+ACK) — пакет проходит, ТСПУ фиксирует fingerprint и счётчик параллельных соединений.

3. Сервер отвечает ServerHello + Certificate — ответ доходит.

4. Клиент шлёт Finished (ChangeCipherSpec + Finished) — и здесь, либо сразу после, начинается дроппинг.

5. Клиент ждёт Application Data. Сервер шлёт — пакеты дропаются на ТСПУ.

6. Sliding window заполняется, отправитель встаёт в ожидании Window Update, которого не будет. Keepalive уходят без ответа на уровне данных.

7. Через ~120 с TCP-стек вызывает таймаут (или исчерпывает retransmit-лимит). Таймаут TLS-handshake в мобильных стеках — 10–30 с; post-handshake read() висит дольше.

8. Клиент переподключается — и если fingerprint и счётчик те же, цикл повторяется.

В логах клиента (Xray/sing-box) это выглядит как цикл без внятной ошибки:

[INFO] connecting to server:443
[INFO] TLS handshake started
[ERROR] read tcp: i/o timeout (after ~30s)
[INFO] reconnecting...
[INFO] TLS handshake started
[ERROR] read tcp: i/o timeout (after ~30s)

Возможны варианты: failed to read client hello на стороне сервера, connection reset by peer если ТСПУ активно инжектирует RST, либо просто таймаут без явной ошибки при чистом packet drop. Нет connection refused, нет ICMP unreachable — и отличить это от реально плохого канала клиент не может в принципе.

Ретраи только усугубляют. Агрессивный retry-логик плодит новые параллельные хендшейки, счётчик снова перебирает порог в пределах окна, начинается новый цикл. Клиент влетает в retry storm и сам продлевает себе заморозку, а смена fingerprint в этот момент, по реконструкции, добавляет 600-секундный штраф. Состояние блокировки привязано к (src_IP, dst_SNI), так что новое соединение с того же IP к тому же SNI мгновенно попадает под ту же блокировку.

А SSH при этом работает (порт 22 или нестандартный): другой fingerprint (SSH handshake), другой порт, никакой browser-имитации, никакого залпа параллельных хендшейков к одному SNI.

5. Воспроизводимая методика измерения заморозки

Цель — зафиксировать факт паузы ~120 с и тип блокировки. Это методика наблюдения за поведением сети, а не маскировки трафика.

Что понадобится: Wireshark 4.4+ / tcpdump, tshark для CLI, curl с verbose TLS, машина в российской сети (или VPS в российском ДЦ). Опционально — dpi-ch (упомянут в Habr 1044396) и curl-impersonate для воспроизведения браузерных fingerprint.

Шаг 1. Baseline handshake timing.

curl --connect-timeout 35 --max-time 35 -o /dev/null -s \
  -w "connect:%{time_connect} tlshs:%{time_appconnect} total:%{time_total}\n" \
  https://TARGET_IP:443/

В норме time_appconnect (до завершения TLS) — 50–200 мс. При заморозке mid-handshake он улетит в --connect-timeout.

Шаг 2. Захват в Wireshark. Фильтр: tcp.port == 443 && ip.dst == TARGET_IP. Запускаем залп из 5 параллельных соединений (имитируем браузер с вкладками):

for i in {1..5}; do curl -sk --connect-timeout 5 https://TARGET:443/ & done; wait

В дампе увидим: SYN → SYN-ACK (TCP проходит), ClientHello → тишина (нет ServerHello), через ~30 с RST или таймаут без RST.

Шаг 3. Идентификация паузы. Statistics → TCP Stream Graphs → Time/Sequence: при заморозке — горизонтальная линия (нет новых seq) длиной ~120 с, затем ретрансмиссии. Фильтр аномальных пауз:

tcp.time_delta > 5 && tcp.port == 443

Длительность penalty = дельта между началом заморозки и моментом, когда следующий одиночный curl вернёт time_appconnect в норму. И заранее не закладывайтесь ровно на 120 с — измерьте; именно это число в фактуре держится на одном источнике, и ваш собственный замер ценнее его.

Шаг 4. Проверка порога по объёму. net4people/bbs #490 фиксирует freeze после ~25 пакетов / ~15–20 KB payload (это отдельный замер, отличный от февральского ~16 KB по Habr — не считайте их одним порогом). Statistics → Conversations → TCP → нужный поток → Bytes/Packets A→B / B→A. Сопоставьте, при каком суммарном payload наступает freeze в вашем случае.

Шаг 5. Тип блокировки.

Если RST есть, но TTL отличается от серверного — это инжектированный RST промежуточного узла (он не выставляет TTL под hop-count реального сервера). Если RST нет, просто тишина — blackholing.

Шаг 6. Чувствительность к fingerprint и параллельности. Сравните time_appconnect при разных ClientHello (curl-impersonate с профилем Chrome/Firefox) к одному серверу в одной подсети. Параллельность: tls.handshake.type == 1 — если при 4+ соединениях в коротком окне все freezeят, а одиночное проходит, гипотеза о пороге параллельности получает локальное подтверждение.

6. Поведенческая разница транспортов

Почему под удар попал именно VLESS+REALITY-over-TCP, а xHTTP/gRPC/Hysteria2 «пока» проходят. И ключевое слово тут — «пока»: по состоянию на 5 июня 2026 xHTTP и gRPC уже попадали под частичные блокировки в Сибири [Techora]. Устойчивость здесь относительная, не абсолютная.

REALITY: в чём была сила и где трещина

REALITY устраняет классическую слабость TLS-прокси — фиктивные сертификаты. Сервер не терминирует TLS сам: он проксирует ClientHello к реальному upstream (например, microsoft.com), получает настоящий ServerHello и сертификат, а в поток вставляет криптографический «маяк» на основе X25519-ключей. Авторизованный клиент видит маяк и разворачивает туннель; неавторизованный probe получает настоящий upstream-сайт — подлинный сертификат, легитимное поведение [факт, XTLS/Xray DeepWiki]. Именно это закрывает active probing. Но от поведенческого анализа снаружи — не защищает никак.

TLS-in-TLS: фундаментальная проблема

Исследование USENIX Security 2024 (Xue, Kallitsis, Houmansadr, Ensafi) «Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes» показало вот что: когда внутри туннеля приложение устанавливает собственное TLS-соединение, во внешнем зашифрованном потоке проступает характерный burst, соответствующий вложенному ClientHello, — по размеру первого бурста, временному паттерну и числу round-trip до начала потока данных. Заявленная точность — >70% TPR на Shadowsocks, VMess, VLESS, Trojan, obfs4, REALITY в стандартных конфигах; метод развёрнут у mid-size ISP с 1M+ пользователей [факт]. И тут две существенные оговорки. Первая: TPR без FPR — это половина метрики. «>70% true positive» сам по себе ни о чём не говорит, потому что не указывает, какой ценой в ложных срабатываниях он достигнут. Для статьи, вся вторая половина которой про ложные срабатывания, это критично: без FPR/precision цифра — не приговор транспорту, а лишь верхняя оценка обнаружимости при неизвестном пороге ложных. Вторая: тестировали в ISP-среде, не в ТСПУ; российская реализация может крутить другие пороги.

xtls-rprx-vision частично противодействует: при обнаружении TLS 1.3 внутри туннеля переключается на splice (прямую передачу без двойного оборачивания) и добавляет padding к handshake-сообщениям. Детектируемость по TLS-in-TLS это снижает, но при пассивном timing-анализе — не устраняет [анализ на основе USENIX 2024].

Поведенческие профили транспортов

VLESS+REALITY+TCP (Vision) — под ударом:

• одно TCP-соединение = один логический поток (без mux); несколько вкладок = несколько TCP+TLS к одному SNI/IP — прямой триггер Сигнала 3;

• почти симметричный двунаправленный поток (туннель 1:2–1:3 против реального веба 1:10–1:50 [FOCI 2024]);

• отсутствие idle-пауз — непрерывный поток под нагрузкой;

• равномерные размеры пакетов при MTU-padding (1400–1500 байт) против вариативного HTTPS.

VLESS+gRPC+REALITY — устойчивее:

• один долгоживущий HTTP/2-over-TLS канал с мультиплексированием до ~100 streams → нет залпа параллельных хендшейков, снаружи похоже на видеостриминг/WebSocket push;

• HPACK маскирует метаданные заголовков; ALPN h2;

• блокировка gRPC = высокий коллатеральный ущерб (Google Cloud и пр.);

• про active probing нужна точность: поскольку gRPC идёт поверх REALITY, стандартный gRPC-probe упрётся в проксируемый настоящий upstream-сайт, а не в gRPC-эндпоинт — то есть REALITY закрывает и этот вектор. Реальная уязвимость gRPC не в active probing, а в том, что 25 мая он частично попал под блокировки в Сибири (по поведенческим/иным признакам, а не по отклику на probe).

VLESS+xHTTP — устойчивее:

• разделяет upstream и downstream на отдельные HTTP-транзакции, связанные UUID в path; upstream — короткие POST с непредсказуемым padding, downstream — chunked/одиночный response;

• нет постоянного двунаправленного TCP-потока; выглядит как scatter-API (много POST + длинный GET); совместим с обычным nginx/CDN;

• уязвимость: если DPI научится детектировать «один долгий GET + много коротких POST к одному path» как аномалию — попадёт под удар [XTLS #4113].

Hysteria2 / QUIC — наиболее устойчив в моменте, но с оговоркой про обфускацию:

• UDP-based — TCP-специфичный механизм «>3 хендшейка» к нему напрямую не применяется;

• маскируется под HTTP/3: при unauthorized-запросе отдаёт настоящий HTTP/3-ответ; аутентификация через POST к /auth;

• Salamander: каждый QUIC-пакет XOR-обфусцируется ключевым потоком из BLAKE2b-256 от (random 8-byte salt + PSK). И вот тут важно не переоценить механизм. Salamander — это именно обфускация, а не шифрование payload (он и так зашифрован QUIC/TLS): она убирает узнаваемую QUIC-структуру в заголовке, мешая сигнатурному «это QUIC». Но размеры и тайминги пакетов она не прячет — то есть против поведенческого/timing-анализа, на котором по логике статьи и держится «заморозка по fingerprint», Salamander сам по себе не помогает. Это защита от сигнатуры, не от поведения;

• блокировка QUIC/UDP на 443 = блокировка HTTP/3 для всего рунета (YouTube, Google, Cloudflare) — РКН этого избегает;

• но: алгоритм Brutal (наращивает скорость при потерях) создаёт аномальный трафик-профиль, потенциально детектируемый; UDP/QUIC периодически блокируется у части операторов [Habr 1008554, multihop.ru]. Цифра «~40% detection rate в Китае» для ТСПУ не верифицирована — GFW и ТСПУ всё-таки разные системы.

Отдельно — MTProto-прокси (легли 5 июня): детектируются по JA3 Fake-TLS, однородному распределению размеров пакетов, симметрии upload/download и регулярности keep-alive [Habr 1041486]. Плюс новый корреляционный маркер 2026: множество клиентов с разных IP к одному серверу с идентичным JA3 — у реальных пользователей браузеры и версии разные, для легитимного сервиса такой паттерн нехарактерен.

7. Европейский след: FIOD и nLighten

Два события совпали по времени с июньскими блокировками, но к ТСПУ прямого отношения не имеют, и сваливать их в один нарратив о «заморозке по fingerprint» — ошибка.

18 либо 22 мая 2026 (источники расходятся: KrebsOnSecurity и BleepingComputer датируют рейд 22 мая и изъятие ~800 серверов, аналитические разборы — 18 мая; единой даты в фактуре нет) нидерландская FIOD провела обыски в Энсхеде, Алмере и двух ДЦ (Дронтен, Схипхол-Рейк), изъяла 800+ серверов и задержала двоих: директора 57 лет и провайдера/брокера connectivity 39 лет. Компания — Stark Industries Solutions, действовавшая через WorkTitans B.V. / THE.Hosting; инфраструктуру использовала группа NoName057(16) для DDoS на нидерландские госресурсы. Основание — нарушение санкционного режима ЕС. Цепочка: Stark Industries → MIRhosting → PQHosting (санкции ЕС, май 2025) → WorkTitans/THE.Hosting [факт, KrebsOnSecurity, BleepingComputer].

2 июня 2026 nLighten без предупреждения отключил серверные стойки с оборудованием MIRhosting (физический хостинг ~800 серверов в Almere). Пострадали VDSina, McHost, THE.Hosting, UFO.Hosting, GEO.Hosting — доступ потеряли больше 15 000 сайтов. Это самостоятельное действие нидерландского ДЦ, не РКН [факт, mentoday.ru].

Как это наложилось. Часть провайдеров, обслуживавших российских пользователей, держала exit-ноды именно в nLighten-экосистеме. Их одновременный отвал плюс поведенческая блокировка ТСПУ внутри России дали конечному пользователю один и тот же симптом — «не работает», — и разобрать причинно-следственную связь в реальном времени было почти нереально. Но это два независимых процесса. Сбои Selectel/Beget/Timeweb 5–6 июня вызваны обновлением конфигурации ТСПУ, а не делом Stark Industries.

8. Архитектурный вывод: решает не протокол, а адаптивность

Сразу о жанре раздела: исторический ряд OpenVPN → WireGuard → Shadowsocks → VLESS → REALITY — это иллюстрация, а не доказательство. «Любой фиксированный протокол рано или поздно описывается сигнатурой» — общее место, и за открытие я его не выдаю. Полезен он только тем, что задаёт правильную рамку постановки задачи, поэтому держу его коротко.

Стратегия цензора структурно проще стратегии протокола: набрать статистику, обучить классификатор, выкатить правило. У цензора масштаб и время, у протокола — инерция обновления у пользователей. Поэтому «искать необнаруживаемый протокол» — это неверная постановка задачи.

Правильная рамка следует прямо из логики AND-схемы (с поправкой, что сама схема — реконструкция по одному источнику): если детекция требует одновременного выполнения нескольких условий, достаточно нейтрализовать одно, чтобы соединение не попало под триггер. Отсюда три принципа устойчивости — на уровне механики, без готовых конфигов:

1. Снижение числа видимых соединений (multiplexing). Вместо N параллельных TCP+TLS к узлу — одно долгоживущее соединение с мультиплексированием логических потоков внутри. DPI видит один поток, похожий на стриминг, а не залп. Это воздействует на Сигнал 3 (mux/xmux в Xray, smux в sing-box, нативный мультиплекс QUIC в Hysteria2 — с разными trade-off по head-of-line blocking).

2. Правдоподобный fingerprint. Профиль должен соответствовать реальному браузеру с актуальными расширениями. Шаблон Firefox или Edge в 2026 менее скомпрометирован, чем Chrome, просто потому что реже встречается в прокси-конфигах. Режим "randomized" опасен: синтетическая генерация может создать физически невозможную комбинацию extensions — а это само по себе fingerprint. Но fingerprint — лишь один из сигналов: идеальный Firefox-профиль на «подозрительной» подсети с 6 параллельными соединениями всё равно попадёт под триггер.

3. Разрыв между адресом узла и «подозрительной» подсетью (CDN-индирекция). Если реальный IP скрыт за CDN, Сигнал 1 не срабатывает — CDN-IP не в списке. Это единственный рычаг, воздействующий именно на Сигнал 1; mux и fingerprint здесь не помогут. Ограничение: CDN поддерживают не все транспорты — gRPC и WebSocket да, VLESS+TCP напрямую нет.

Общий принцип: устойчивость в 2026 — это не «магический протокол», а минимизация числа одновременно выполненных детекционных условий плюс способность транспортного слоя адаптироваться к смене ситуации.

9. Дисклеймер, ограничения метода и где это оставляет пользователя

Закончу тем, с чего начал. Полгода назад я написал, что REALITY неблокируем — и был прав ровно наполовину. Маскировка рукопожатия действительно держится: её по-прежнему не вскрывают. Ошибся я в другом — думал, что маскировки достаточно. А фильтр просто перестал смотреть на рукопожатие и начал смотреть на поведение туннеля после него — и тут «неотличимый снаружи» VLESS выдаёт себя ровностью потока. Так что свой вывод годичной давности перепишу одной строкой: побеждает не протокол, который выглядит как HTTPS, а сервис, который меняет поведение быстрее, чем фильтр учится его описывать. Это единственное, что пережило последние полгода без поправок.

Нейтральный дисклеймер. Материал носит образовательный и исследовательский характер: он описывает, как устроена поведенческая детекция трафика, и даёт методику её измерения — для понимания происходящего и для диагностики сбоев у легитимных сервисов, попавших под ложные срабатывания. Применяйте описанное в рамках действующего законодательства вашей юрисдикции.

Ограничения разбора (повторю прямо, потому что это определяет статус всей статьи):

• Ядро описания поведенческой схемы (разделы 2–4) — реконструкция чёрного ящика по одному структурированному источнику (Zapret/Obsidian, атрибуция П. Осетрову, наблюдения через dpi-ch). Кодовое имя модуля — фольклор обсуждений, не номенклатура; академические работы по ТСПУ его не используют. Пороги (350–400 мс / 60 с, ~120 с, penalty 600 с, «>3 хендшейка») кросс-проверкой независимыми измерениями не подтверждены — это рабочие гипотезы, правдоподобные и согласующиеся с симптомами, но не верифицированные константы. Поимённый состав «подозрительных» российских ASN (Selectel/Yandex.Cloud/Cloud.ru) — из перепечатывающих друг друга телеграм-источников, без пакетных дампов.

• Число «120–180 с» packet-drop — это измерение GFW (Китай) из USENIX 2023, а не российский замер; близость к нему российской ~120 с по одному источнику — совпадение, а не доказанный перенос.

• «>70% TPR» из USENIX 2024 приведено без FPR/precision в самой работе в удобном для цитирования виде — поэтому это оценка обнаружимости, а не вердикт о применимости детектора.

• ТСПУ децентрализована: оборудование (EcoFilter и др.) стоит у каждого оператора по-своему, параметры различаются у МТС, Ростелекома, Билайна. Что работает у одного — может не работать у другого. Исследования (TSPU IMC 2022, ensa.fi) фиксируют >650 AS за ТСПУ-устройствами при неоднородных конфигурациях.

• Тезис «ТСПУ использует нейросети/ML» не подтверждён: комментаторы со ссылкой на утечки утверждают, что EcoFilter не имеет ресурсов даже на анализ QUIC. Заявления РКН есть, данных о реальном продакшен-развёртывании ML-детектора — нет.

• «92%» — это KPI эффективности ограничения доступа к средствам обхода за счёт сигнатурного анализа к 2030 году (документ № 25-66883-01845-R от 13.01.2025), а не «92 заблокированных сервиса». Реальное число — 469 сервисов на февраль 2026 (динамика: 167 в 2021 → 197 в окт. 2024 → 258 в 2025 → 469). Цель по охвату трафика — 98% (до 831 Тбит/с, пересмотрено до 954 Тбит/с в марте 2026), бюджет ~20 млрд руб. на 2026 и столько же на 2027–2028 [факт, Habr 1031242, Xakep, Коммерсант].

• «Пока проходит» по xHTTP/gRPC/Hysteria2 — временная характеристика, уже опровергаемая отдельными регионами.

Где это оставляет рядового пользователя. Большинство не будет руками настраивать uTLS-шаблоны и mux-параметры. Практическая точка выбора для них — оценивать сервис не по обещаниям, а по тому, насколько его инфраструктура соответствует архитектурным принципам из раздела 8: не держит ли ноды в «подозрительных» подсетях, применяет ли CDN-прослойку, обновляет ли fingerprint-шаблоны вслед за сменой ситуации.

---

Источники: Habr 1009542, 1044396, 1009560, 992232, 1027012, 1000694, 1041486, 1045684, 1008554, 1031242; net4people/bbs #490, #546; USENIX Security 2023 (gfw.report) и 2024 (Xue et al.); TSPU IMC 2022 (ensa.fi); FoxIO JA4 spec; XTLS/Xray DeepWiki и discussion #4113; Hysteria2 Protocol Spec; FOCI 2024; Techora, Meduza, vc.ru/РБК, 3dnews, mentoday.ru, eByeBots, allslava.com, digirpt.com; KrebsOnSecurity, BleepingComputer; kod.ru, lenizdat.ru, Xakep, Коммерсант. Статусы [факт]/[один источник]/[гипотеза]/[анализ] проставлены по тексту. Ядро разделов 2–4 — реконструкция по одному источнику, не верифицированное описание системы.