Заморозка по fingerprint: как ТСПУ в июне 2026 ломает соединения по поведению, а не по протоколу

Полгода назад я написал здесь разбор «почему 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. И это принципиально: каждый сигнал по отдельности встречается и у честного трафика, мишенью предположительно служит именно их совпадение.

ТСПУ смотрит на 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-узлам — это и объясняет, почему в разных регионах всё работает по-разному.

Первым незашифрованным сообщением при 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 не бьётся с поведением и контекстом:

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

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

Реальный браузер после хендшейка генерирует специфичные паттерны — 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 параллельных 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 или сразу за ним.

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

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

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

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

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

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

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

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

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

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

Возможны варианты: 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.

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

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

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

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

Длительность 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. Тип блокировки.

Наблюдение в Wireshark

Интерпретация

SYN без SYN-ACK

IP-блокировка

SYN-ACK есть, ClientHello уходит, ServerHello нет

Freeze mid-handshake (ТСПУ)

Handshake завершён, RST после ~N КБ

packet-count / volume threshold

Всё проходит, но +задержка на каждом пакете

throttling (деградация, не блокировка)

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

Исследование 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 и ТСПУ всё-таки разные системы.

Транспорт

Видимых сессий

ALPN

Timing

Устойчивость к поведенческой схеме

VLESS+REALITY+TCP

N (по потокам)

h1/h2

Burst N handshakes

Низкая (Сигнал 3)

VLESS+gRPC+REALITY

1 долгоживущий

Stream-like

Выше (probing закрыт REALITY)

VLESS+xHTTP

1 / мало

h1/h2

POST-like API

Выше

Hysteria2+Salamander

UDP, не TLS

Random UDP

Другой детектор; обфускация ≠ timing-защита

VLESS+TCP+mux

1 долгоживущий

Единый поток

Выше

Отдельно — 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-схемы (с поправкой, что сама схема — реконструкция по одному источнику): если детекция требует одновременного выполнения нескольких условий, достаточно нейтрализовать одно, чтобы соединение не попало под триггер. Отсюда три принципа устойчивости — на уровне механики, без готовых конфигов:

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

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

Разрыв между адресом узла и «подозрительной» подсетью (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 — реконструкция по одному источнику, не верифицированное описание системы.