Fake-TLS перестал спасать — разбираю, что технически означает «анализ сигнатур протокола», почему статистика трафика выдаёт прокси и где предел этой гонки
В конце мая 2026 рунет накрыло волной сообщений о массовых отказах MTProto-прокси. Сервисы, через которые пользователи обходили замедление Telegram, перестали работать почти у всех операторов одновременно. «Код Дурова» зафиксировал, по их формулировке, беспрецедентное количество жалоб. Технические каналы запестрели заголовками в духе «РКН прокачал блокировки, обойти невозможно».
Я хочу разобрать это не как новость, а с инженерной стороны: что технически стоит за фразой «DPI научился анализировать сигнатуры протокола», почему механизм Fake-TLS, который работал годами, внезапно перестал спасать, и какие фундаментальные свойства трафика выдают прокси, даже когда полезная нагрузка зашифрована.
Сразу обозначу жанр. Это разбор теории обнаружения протоколов — области на стыке сетевого анализа, статистики и DPI. Это не инструкция по обходу блокировок: конкретных рецептов «как сделать так, чтобы у вас работало» здесь не будет, для этого есть профильные ресурсы. Цель — понять, как технически устроена детекция, потому что это интересная инженерная задача сама по себе, и понимание механики полезно любому, кто работает с сетями.
Краткая вводная: что такое MTProto и Fake-TLS
Чтобы разговор был предметным, нужна база.
MTProto — собственный транспортный протокол Telegram. Он создавался не только для шифрования, но и для работы в условиях фильтрации трафика. Внутри Telegram есть встроенный механизм прокси — MTProxy, который работает прямо в клиенте, без дополнительного софта.
Ключевая фишка MTProxy последних лет — Fake-TLS (он же FakeTLS, padded TLS). Идея в том, чтобы замаскировать соединение под обычный HTTPS. Когда вы открываете любой сайт по HTTPS, между клиентом и сервером происходит TLS handshake — обмен сообщениями ClientHello, ServerHello, обмен ключами. Fake-TLS оборачивает MTProto-трафик так, чтобы начало соединения выглядело как легитимный TLS 1.3 handshake к какому-нибудь нормальному домену.
Для DPI, который смотрит только на начало соединения, это выглядело как обычный визит на сайт. Поэтому годами Fake-TLS MTProxy спокойно проходил через фильтры — система не могла отличить его от рядового веб-серфинга, не ломая попутно весь HTTPS.
Это работало. До определённого момента.
Этап 1: детекция по TLS handshake (что было раньше)
Первый уровень детекции, который применялся в начале 2026 года — анализ самого TLS handshake. И тут есть тонкость, которую важно понять.
Fake-TLS имитирует TLS, но имитирует не идеально. Реальный TLS-стек браузера (BoringSSL в Chrome, NSS в Firefox) формирует ClientHello с определённым набором полей в определённом порядке: список cipher suites, extensions, эллиптические кривые, форматы точек, ALPN, signature algorithms. Этот «отпечаток» получил название JA3 (и его развитие JA4) — хеш от параметров ClientHello, по которому можно идентифицировать клиентскую библиотеку.
У реализации Fake-TLS в MTProxy этот отпечаток отличается от настоящего браузера. Не сильно, но измеримо. Где-то другой порядок extensions, где-то отсутствует расширение, которое есть у настоящего Chrome, где-то набор cipher suites не совпадает с актуальной версией браузера.
DPI с базой JA3/JA4-отпечатков популярных браузеров может сравнивать: вот пришёл ClientHello, который заявляет себя как Chrome, но его JA3-хеш не совпадает ни с одной реальной версией Chrome. Подозрительно — помечаем.
Именно это произошло в марте-апреле 2026. ТСПУ получили обновлённые правила, которые ловили несоответствие TLS-отпечатка. Разработчики прокси отвечали подгонкой fingerprint под актуальные браузеры — классическая гонка щита и меча.
Но детектирование по handshake имеет фундаментальное ограничение: отпечаток можно подделать. Если знать, какой именно JA3 у свежего Chrome, можно сформировать ClientHello с точно таким же. Это вопрос инженерных усилий, не принципиальной возможности. Поэтому регулятор перешёл к следующему уровню — там, где подделка гораздо сложнее.
Этап 2: статистический анализ сигнатур протокола
Вот здесь начинается самое интересное с технической точки зрения. Новый виток, о котором писали в конце мая 2026 — анализ не handshake, а поведения трафика на всём протяжении соединения.
Ключевая идея: даже если начало соединения идеально замаскировано под TLS, дальнейший обмен данными подчиняется логике другого протокола — MTProto. А у каждого протокола есть статистические инварианты, которые сложно скрыть, не сломав сам протокол.
Что конкретно анализируется.
Размеры пакетов и их распределение
Реальный HTTPS-трафик при загрузке веб-страницы имеет характерный паттерн: большой всплеск в начале (HTML, CSS, JS, изображения летят крупными TLS-records близкими к MTU), потом затишье, потом мелкие запросы по мере взаимодействия. Распределение размеров пакетов веб-сессии — это «рваный» профиль с явными фазами.
MTProto в режиме мессенджера ведёт себя иначе. Это поток мелких сообщений — текст, статусы набора, пинги, подтверждения доставки. Распределение размеров пакетов другое: много мелких пакетов схожего размера, ровный поток без характерных веб-всплесков. Даже завёрнутый в TLS-обёртку, этот паттерн статистически отличается от реального просмотра сайтов.
DPI может строить гистограмму размеров пакетов в соединении и сравнивать её с эталонными профилями. Веб-сессия и MTProxy-сессия дают разные гистограммы.
Тайминги и направление трафика
Второй сигнал — временная структура. Веб-загрузка асимметрична: клиент отправляет маленький запрос, сервер отвечает большим объёмом данных. Соотношение upload/download для веб-серфинга сильно смещено в сторону download.
Мессенджер-трафик симметричнее: вы и отправляете, и принимаете сообщения сопоставимого размера. Плюс есть характерный «долгоживущий» паттерн — соединение держится открытым часами с периодическими keep-alive пингами через регулярные интервалы. Веб-соединения так себя не ведут — они короткоживущие, открылись-закрылись.
Регулярность пингов — отдельный сильный маркер. Если в «TLS-соединении» каждые N секунд проходит пакет фиксированного размера — это очень похоже на keep-alive мессенджера, а не на веб.
Энтропия и структура полезной нагрузки
Третий уровень — анализ энтропии зашифрованного потока. Тут тонко: и TLS, и MTProto шифруют данные, так что полезная нагрузка в обоих случаях выглядит как высокоэнтропийный «шум». Но есть нюансы в том, как структурированы TLS-records поверх шифрования: их длины, заголовки, паттерн фрагментации. MTProto поверх Fake-TLS формирует records не совсем так, как настоящий TLS-стек при передаче HTTP/2-трафика.
Поведенческая корреляция по IP
И, наконец, маркер, о котором прямо писали в новостях: корреляция подключений к одному IP. Логика такая. Публичный MTProxy обслуживает много пользователей. Все они подключаются к одному IP-адресу. Если Fake-TLS у всех них имитирует одну и ту же версию браузера (потому что прокси-сервер использует один и тот же fingerprint), то DPI видит странную картину: на один IP приходят десятки и сотни клиентов, и все с идентичным TLS-отпечатком одной и той же, часто устаревшей, версии браузера.
В реальном мире так не бывает. К одному сайту подключаются пользователи с разными браузерами, разными версиями, разными ОС — естественный разброс fingerprint. А когда сто клиентов приходят с побайтово одинаковым ClientHello «Chrome версии полугодовой давности» — это статистическая аномалия, которая прямо указывает на прокси.
Почему это работает, а подделать сложнее, чем handshake
Тут ключевой инженерный момент, ради которого я и затеял разбор.
Подделать статический отпечаток (JA3 handshake) — относительно просто: скопировал параметры настоящего браузера, сформировал такой же ClientHello. Один раз настроил — работает, пока браузер не обновится.
Подделать динамическую статистику протокола — принципиально сложнее. Потому что эта статистика порождается самой логикой работы MTProto. Чтобы профиль размеров пакетов и таймингов был неотличим от веба, нужно либо:
генерировать фейковый «веб-подобный» трафик поверх реального — это огромный overhead, который убивает производительность и всё равно не идеален;
переписать сам способ упаковки данных так, чтобы он статистически совпадал с настоящим HTTP/2 over TLS — это, по сути, и есть «переработать протокол», о чём писали в новостях. Именно поэтому фраза «избежать нельзя, Telegram должен переработать протоколы» в исходной новости — не совсем кликбейт. Доля правды в ней есть: косметической подгонкой fingerprint от статистической детекции не уйти, нужно менять то, как протокол формирует трафик на уровне паттернов.
Хотя «нельзя» — это преувеличение. Можно. Просто это требует более глубоких изменений, чем подмена одного хеша. И это снова гонка, просто на новом уровне.
Контекст: почему это часть большой гонки
Стоит понимать, что детекция MTProxy — лишь один фронт. С декабря 2025 по май 2026, судя по публикациям, DPI-системы научились распознавать по сигнатурам и другие протоколы обхода: WireGuard, OpenVPN, VLESS, SOCKS5, L2TP. Логика везде одинаковая — у каждого протокола есть статистический отпечаток, и при достаточных вычислительных мощностях его можно выделить.
Ответ со стороны обходных инструментов тоже идёт по понятному вектору — обфускация, которая не имеет стабильной сигнатуры. Протоколы вроде AmneziaWG (обфусцированный WireGuard) добавляют случайный шум в трафик, рандомизируют размеры пакетов и тайминги, чтобы у соединения не было устойчивого статистического профиля. Это прямой контр-приём против статистической детекции: если профиль каждый раз разный, эталон для сравнения построить сложно.
Это классическая динамика censorship-resistance: детекторы ищут инварианты, обходные инструменты их устраняют, детекторы ищут новые. Академически это хорошо описано в работах про обнаружение и обфускацию протоколов — например, исследования группы Tor про pluggable transports, работы про обнаружение Shadowsocks китайским GFW.
Ограничение со стороны железа
Есть ещё одна сторона, без которой картина неполна — стоимость детекции.
Анализ TLS handshake дёшев: посмотрел первые несколько пакетов соединения, посчитал хеш, сравнил с базой. Это можно делать на лету для всего трафика.
Статистический анализ поведения дороже. Чтобы построить гистограмму размеров пакетов и профиль таймингов, нужно отслеживать соединение на протяжении времени, накапливать состояние, считать статистику. Это требует памяти под каждое соединение и вычислений. При миллионах одновременных соединений нагрузка на оборудование растёт кратно.
В апреле 2026 был показательный эпизод: при попытке нагрузить ТСПУ большим количеством правил фильтрации (по публикациям, около 40 тысяч против обычных 10-15 тысяч) система на части узлов ушла в bypass — то есть начала пропускать трафик без фильтрации, включая ранее заблокированные ресурсы. Это прямое следствие того, что глубокий анализ ресурсоёмкий, а суммарная пропускная способность оборудования конечна.
Получается интересный парадокс, который отмечали эксперты: чем больше пользователей включают прокси, тем выше нагрузка на систему фильтрации, тем хуже она справляется со всем остальным. Детекция по статистике усиливает этот эффект, потому что она дороже простой проверки handshake.
Что из исходной новости правда, а что преувеличение
Раз уж повод — конкретная новость, разберу её формулировки с технической точки зрения.
«DPI анализирует не только handshake, но и сигнатуры протокола — размер пакетов, fingerprint» — это технически корректно. Именно переход от анализа handshake к анализу поведенческой статистики и есть суть нового витка.
«Если к одному IP подключаются разные клиенты с одинаковой устаревшей версией браузера — это признак прокси» — корректно и логично. Это та самая поведенческая корреляция по IP, сильный и дешёвый в вычислении маркер.
«Избежать этого сейчас нельзя» — преувеличение. Точнее будет «нельзя избежать косметической подгонкой fingerprint». Статистическую детекцию обходят обфускацией с рандомизацией, и эти методы существуют (AmneziaWG как пример). Гонка продолжается, а не закончилась.
«Telegram должен полностью переработать протоколы» — частично правда. Чтобы Fake-TLS снова стал неотличим, нужно менять не отпечаток, а способ формирования трафика — это глубже, чем подмена хеша. Но «полностью переработать» — драматизация.
Типичная картина для технических новостей: основные факты верны, выводы драматизированы до уровня «всё пропало».
Что из этого полезно вынести
Несколько мыслей, выходящих за рамки конкретного кейса с Telegram.
Шифрование полезной нагрузки не скрывает метаданные трафика. Это фундаментальный принцип. Можно идеально зашифровать содержимое, но размеры пакетов, тайминги, направление, длительность соединения остаются видимыми. Анализ трафика (traffic analysis) — отдельная мощная дисциплина, и она работает поверх любого шифрования. Это касается не только обхода цензуры, но и, например, деанонимизации в Tor по таймингам, и утечек в зашифрованных мессенджерах через размеры пакетов.
Статический отпечаток подделать легко, динамическое поведение — трудно. Это общий принцип для любой детекции. Сигнатура, которую можно скопировать один раз — слабая защита. Поведенческие инварианты, порождаемые самой логикой системы — куда более устойчивый признак. Это применимо и в антифроде, и в обнаружении ботов, и в fingerprinting устройств.
Любая детекция упирается в стоимость. Чем глубже анализ, тем дороже он вычислительно. Это создаёт фундаментальный предел: систему можно перегрузить объёмом. Защита и нападение здесь — это всегда ещё и экономика вычислений, не только алгоритмы.
Обфускация против сигнатур — это про устранение инвариантов. Лучший способ не быть пойманным по статистике — не иметь стабильной статистики. Рандомизация размеров, таймингов, добавление шума. Это контр-приём, который работает против любого детектора, ищущего устойчивый паттерн.
Резюме
То, что произошло в мае 2026 с MTProxy — это переход детекции с уровня «как выглядит начало соединения» на уровень «как ведёт себя соединение во времени». Технически это закономерный шаг: анализ handshake обходится подделкой fingerprint, поэтому регулятор перешёл к статистическому анализу, который подделать сложнее.
Это не «конец Telegram» и не «обойти невозможно» — это новый виток давней гонки между детекцией и обфускацией протоколов. Статистическую детекцию, в свою очередь, обходят рандомизацией трафика, и инструменты для этого уже существуют. Параллельно вся система упирается в потолок вычислительных мощностей — глубокий анализ дорог, и это объективное ограничение.
С чисто инженерной точки зрения это красивая задача на стыке сетевого анализа, статистики и теории обнаружения. И понимание её механики полезно далеко за пределами темы блокировок — те же принципы работают в traffic analysis, антифроде, обнаружении ботов и анализе зашифрованных каналов.
Это технический разбор механики обнаружения протоколов, не политическое высказывание и не руководство по обходу блокировок. Если у вас есть корректировки по технической части — пишите в комментариях.
Источники и для дальнейшего чтения:
Документация по JA3/JA4 fingerprinting (Salesforce, FoxIO)
Исследования Tor Project про pluggable transports и обнаружение obfs4
Работы про обнаружение Shadowsocks системой GFW (различные академические публикации по censorship measurement)
Спецификация MTProto в открытой документации Telegram
Комментарии (116)
LiamBlue
30.05.2026 11:44У меня есть вообще предложение, чтобы уйти от простых банальных TCP соединений с серверами и использовать их для обхода блокировок. Надо теперь перейти на уровень самих IP пакетов, и слать их в массовых количествах, напрямую к серверам обходов блокировок. TCP соединение можно сбросить, а что ты сделаешь с IP пакетами? Весь поток к IP адресу перекроешь?
Но вот для вспомогательных целей, подтверждения доставки и прочего действительно можно организовать TCP соединение. Однако же, отчего же надо это соединение организовывать непременно с хостом, который лежит по тому же IP адресу, что и сервер обхода блокировок? Можно организовать ещё какой-нибудь сервер в сторонке, который будет помогать, и слать часть нужной нам информации от своего имени.
Да и вообще, можно организовать параллельную работу по обходу блокировок через несколько слаженных хостов, со своими IP адресами, работающих сообща.
HardWrMan
30.05.2026 11:44Весь поток к IP адресу перекроешь?
Ну, допустим, UDP успешно перекрывают, оставляя окно строго только для TCP.
LiamBlue
30.05.2026 11:44Ну дык можно слать к серверу IP пакеты, выглядящие как фрагменты TCP сессии. И только посвященные будут понимать что это не просто рядовые какие-то пакеты. К ним должна быть особая интерпретация. Воспринимающая их на самом деле, как что-то вроде UDP датаграмм.
HardWrMan
30.05.2026 11:44Рандомные ТСР уже выглядят странно, особенно, если там бардак с флагами, выходящий за рамки стейт-машины состояния сессии.
LiamBlue
30.05.2026 11:44Я хочу сказать, что в условиях произвольных блокировок и хаоса в сетях - явное установление соединений, которые могут быть заблокированы и сброшены, это проблема. Подход, где информация передается порциями, как-то налаживается за ней контроль передачи, маршрутеризация по разнообразным маршрутам передачи, не обязательно постоянно одним и тем же - этот подход выглядит куда более живучим и надёжным. А порции информации могут быть как UDP пакеты, так и просто передача через временно устанавливаемые TCP соединения, на которых не рассчитывается что они проживут долго и могут быть разорваны в любой момент.
HardWrMan
30.05.2026 11:44Если бы сеть состояла только из IP маршрутизаторов, то ваша идея вполне себе рабочая, что можно не ограничиваться только UDP или только TCP и делать хоть каждый день свой IP протокол. Однако, такое было бы возможно при наличии у каждого своего личного и уникального адреса (привет IPv6!), который может пиринговаться напрямую каждый с каждым. Но легаси IPv4 и некоторые "особенности" сетестроения в прошлом принесло нам несчётное количество NAT узлов в этой сети. И каждый из них должен уметь работать с каждым выдуманным протоколом. Об этом уже намекнули ниже.
F01D32
30.05.2026 11:44В принципе уже есть что-то похожее на описываемое, вроде условного udp2raw. Правда не думаю, что можно далеко ускакать от TCP/UDP/ICMP. Не эксперт в теме, но по-моему иначе эта идея разобьется об провайдерский NAT, даже не дойдя до ТСПУ
Было бы проще, распространись уже IPv6. Жаль его в дикой природе домашнего интернета я пока даже ни разу не видел
LiamBlue
30.05.2026 11:44Вот скажем да, сделать 3 сервера A, B, C. Через A будет идти служебный трафик, с подтверждением доставки пакетов. Через B будет идти outbound трафик, через C будет идти inbound трафик. Но можно даже не так строго, а трафик может варьироваться. То значит через B пошлют всё-таки порции inbound трафика, то через C пошлют ещё сколько-то там outbound трафика.
А между собой сервера A, B, C коммуницируют, и объединяют всю информацию, которая от них уходит или поступает.
LiamBlue
30.05.2026 11:44Ещё добавлю, что если группировка сервером будет не из 3-х хостов, а большого их количества, можно будет вообще не держать постоянно открытые соединения с какими-то отдельными серверами, а время от времени их открывать, гнать трафик, закрывать. Открывать другие соединения с другими серверами. И так до бесконечности. Но виртуальное соединение между нашим компьютером и группировкой серверов будет продолжать поддерживаться.
Vindicar
30.05.2026 11:44Вы исходите из логики чёрного списка. А тут всё ближе логика списка белого. Недостаточно скрепный трафик - в /dev/nul.
MyraJKee
30.05.2026 11:44Задрали уже. Их бы энергию в мирное русло.
Onito
30.05.2026 11:44Энергию говна куда не направь получится говно
Survtur
30.05.2026 11:44В говне можно растения выращивать. В том числе съедобные и вкусные.
wepp
30.05.2026 11:44Предлагаете использовать тепло от избыточной работы инфраструктуры блокировок на обогрев теплиц?
vlagrid
30.05.2026 11:44Хреновый из вас агроном, в говне ничего не растёт, говно должно превратиться в перегной
igorich
30.05.2026 11:44олег за всё берётся смело
всё превращается в говно
а если за говно берётся
то просто тратит меньше сил =)
Mizantrop777
30.05.2026 11:44Хз, может до меня ещё не дошло, но личный прокси работает пока.
HardWrMan
30.05.2026 11:44Дык, это же основа конспирации: пока ты используешь только сам (ну, пусть ещё твоя жена и дети) ключ на антивирус/виндовс/etc то его не блокируют. Но стоит его разместить на варезнике с хорошим охватом и вот его уже заблокировали. Это же применимо и к сетевым ресурсам: статистика использования конкретных адресов решает.
Oncenweek
30.05.2026 11:44Интересно, но выглядит так, что новые блокировки (конец мая) таки все же как то детектируют особенности ClienHello (в обсуждении issue d tdlib предполагали, что по соответствию Chome определенной версии, и якобы эта версия хрома сайты тоже открывает нестабильно) - тормозит именно хендшейк, но если соединение установлено, то далее прокся работает нормально
NeoCode2
30.05.2026 11:44Да, последнее время vless+reality+xhttp на своем vps работает из рук вон плохо. Пока есть резервные каналы - бесплатные прокси-расширения для браузеров, некоторые android-приложения которые сами как-то умеют обходить блокировки, но все равно тревожно.
Я не такой крутой специалист чтобы понять в чем там дело, единственное - внимательно слежу за статьями и комментариями на Хабре, вдруг кто что дельного посоветует.
Oncenweek
30.05.2026 11:44Кстати, мне на десктопе внезапно помогло завернуть адрес своей прокси в zapret
Alexinthecold
30.05.2026 11:44Скорее всего ваш хостер замедлен а запрет при определённых настройках пробивают незаконные замедление хостеров и cdn
0ka
30.05.2026 11:44Детектируют реальный TLS client hello от хрома, но только если устанавливается несколько сессий (что и делает телеграм и большинство vless проксей). К этому ещё есть динамический триггер блок - при запросе на популярные в проксях sni (например github.com), полностью блокируется https с fingerprint chrome к некоторым хостинг провайдерам (напр vdsina).
А ещё есть полный блок https со sni к некоторым хостингам (например justhost)
В самом начале новых блокировок я видел что у людей срабатывал блок начиная со второй TLS сессии с отпечатком chrome на любой ip (на сколько я знаю это уже откатили, но это не точно. у меня сейчас ограничение это 6 сессий хрома на определённые хостинг провайдеры типа vdsina и h2nexus)
Nemoumbra
30.05.2026 11:44DPI с базой JA3/JA4-отпечатков популярных браузеров может сравнивать: вот пришёл ClientHello, который заявляет себя как Chrome, но его JA3-хеш не совпадает ни с одной реальной версией Chrome.
ClientHello не может заявлять себя, как хром. Юзер-агент будет только в HTTP. На уровне TLS - только косвенные признаки, так что фраза вводит в заблуждение. LLM, как обычно, врёт в важных деталях.
Я правильно понимаю, что в статье художественный вымысел про ТСПУ (не подкреплённый никакими воспроизводимыми исследованиями) в стиле "чё там чисто в теории можно было бы сделать" смешан с реальными фактами? Автор, признавайся!
Allaire
30.05.2026 11:44Автор вряд ли в чем-то сможет признаться, ибо является нейросетью, это особенно очевидно по первой версии статьи.
Bobr-Kurwa
30.05.2026 11:44LLM просто криво сформулировала вот это "заявляет себя". А по сути, в TLS всё-таки можно по порядку следования и составу полей определить клиента.
MTProxy притворяется Google Chrome. Раньше это делалось криво, поэтому блокировали. Потом исправили (см. статью), и теперь TLS отпечаток не отличается от Chrome.
в статье художественный вымысел про ТСПУ (не подкреплённый никакими воспроизводимыми исследованиями)
именно так
Wolf4D
30.05.2026 11:44Дурной вопрос - а почему не проложат тоннель через реальный https? Условно, клиент держит у себя кастрированный electron, который обращается к прокси как к обычному сайту, а полезная нагрузка передаётся через get/post запросы, или вебсокет, или через любой другой мало-мальски адекватный механизм. Прокси, соответственно, возвращает абсолютно валидную веб-страницу с размещённым посреди ответом. И хэдеры на месте, и порядок загрузки всего добра правильный будет.
LiamBlue
30.05.2026 11:44Так уже давно используют https под совершенно другие задачи, чем он предназначен изначально. Те же VPN маскируются под https соединения, и гонят в них совсем не HTTP запросы.
Wolf4D
30.05.2026 11:44Да, и я об этом же. А что, если собственно и не маскировать, а именно что легитимно оборачивать? Ведь внутри зашифрованного соединения, гонящего HTML-страницы, никто не поймёт, картинка котика там пришла в числе прочего наполнения, или жирный кусок данных.
Oncenweek
30.05.2026 11:44Потому что ТСОЦ увидит, что пользователь гоняет гигабайты данных до какого-то неизвестного сайта типа Wolf4D.freemyip.com, тыкнет его, увидит что на нем даже главная не отрывается (active probing) и отправит его в блок. Или даже сразу отправит его в блок
akakoychenko
30.05.2026 11:44ну хз
как будто бы, в век ии, генерировать уникальные гладковыглядящие сайты можно тысячами за миску рисаOncenweek
30.05.2026 11:44Хостинги, сертификаты и доменные имена для этих тысяч обойдутся уже совсем не в миску риса
akakoychenko
30.05.2026 11:44Почему же? Сертификаты бесплатны нынче. Хостить индивидуально тоже их все не надо, а проксировать все невалидные запросы на 1 сервер с тысячами (пусть, даже нестатических сайтов), на который приходит по пару открытий сайтов в минуту тоже ниочем. Остаются только домены. Но, кажется, ip v4 нынче сильно дороже 1го домена типа fun/space/xyz и так далее, если, конечно, не требуется держать его на балансе больше года (а это не нужно), и, выходит, что, если держатель прокси раздобыл ipv4 и виртуалку, способную проксировать, то все остальное уже крохи от понесенных затрат
Oncenweek
30.05.2026 11:44А потом ТСОЦ вычислит что у юзера идут гигабайты с одного айпишника но разными SNI и отправит его в блок. Какой-нибудь LetsEncrypt тоже думаю не шибко рад будет если у него начать серты тысячами прям запрашивать.
akakoychenko
30.05.2026 11:44А зачем плодить домены на 1 ip?
1 прокс-1 домен-1 уник сайт. То, что их таких тысячи на один ориджин смотрят при клоакинге, только админу ведомо.
Oncenweek
30.05.2026 11:44Ну так CIDR то у запросов ко всем сайтам один же? Или даже без этого: отлитит в бан одна прокся по ip, отлетят все за ней, а ТСОЦ видит, что вы гигабайты льете с какого-то левого сайта постоянно.
edit: кажется понял что вы предлагаете, но это защитит только от active probing, а вот паттерны трафика вида “гоняет гигабайты на один сайт” или “частота пакетов похожа на стриминг видео” вполне может быть вычислена и прокся отлетит в бан. В принципе это от vless мало чем отличается
Wolf4D
30.05.2026 11:44А может это у меня форум любителей котиков, и мы там смотрим видяшки с котиками? :) но вообще такой канал не про видяшки, а скорее про обмен единичными сообщениями. Видяшку можно и по-другому выгрузить, чтобы пакеты не гонять.
Помню, во времена местечковых провайдеров с развитыми локалками и дорогим трафиком "в мир", были люди с безлимитом, изобретали irc ботов, которым пишешь адрес веб-странички, а бот лезет в большой интернет, выкачивает её и укладывает в локальный FTP.
P.S. С современным ИИ вполне можно и "мёртвоинтернетный" форум из ботов соорудить, где будет дикая фейковая активность.
Oncenweek
30.05.2026 11:44Ну вот его сначала заблокируют, а потому будете доказывать что это форум любителей котиков. Тут у половины страны вся подсеть cloudfire не работает, потому что TLS1.3 c EncryptedClientHello по умолчанию использует, а блокировка из сабжа рубит и часть легитимных соединений через Хром. Думаете ваш сайт любителей котиков кого-то остановит?
Wolf4D
30.05.2026 11:44Я не про оправдания. Чтобы заблокировать - надо сначала найти. А тут маскировка под вполне легитимный ресурс, а главное - под легитимный use-case.
JBFW
30.05.2026 11:44Плевать они хотели на легитимность: вон, местами заблочили google-com, в других местах - заблочили карты OSM.
Зачем, почему? Легитимность? что это? Распоряжение начальника - вот легитимность!
LiamBlue
30.05.2026 11:44Вот эти вот рассуждения, что а может у меня что-то такое, что вполне легитимно... Оно не прокатит с нынешним РКН. Если он делает что хочет, блокирует кого хочет - никакие оправдания неуместны. РКН что-то не понравится хоть слегка, и он ваш сайт заблокирует. И даже не почешется. И даже достучаться до него не выйдет, т.к. он не ответственнен перед народом. Для РКН имеет значение только мнение начальства.
yahooyaks
30.05.2026 11:44А может начать выявлять функционеров РКН и начать публиковать из персональные данные с фотографиями? Ведь это же слуги народа, который просто обязан знать их в лицо и понимать, кого он кормит своим трудом.
kuza2000
30.05.2026 11:44active probing
Кстати, это точно есть. У меня маскировочный nginx на vps когда упал - соединение vless моментально пропадает, хотя все работает на обоих сторонах. Режут. Сайт поднимается - коннект возникает. Содержимое сейчас не проверяют - должен быть просто ответ любым http кодом. Если не накрутили уже еще чего...
alex09102026
30.05.2026 11:44скорее потому, что у тебя упавший nginx не пересылает пакеты на интерфейс xray
kuza2000
30.05.2026 11:44Нет. Зачем вы делаете уверенные предположения без диагностики и даже без деталей настройки? :)
Там вообще, все наоборот - xray пересылает пакеты nginx. И я все проверил - пакеты на vps вообще перестают приходит, если сайт маскировки не отвечает.JBFW
30.05.2026 11:44Хех, но логичнее как раз было бы, чтобы был сайт про котиков и рецепты, а уже xray где-то там, среди мейнкунов и пирожков с яблоками...
kuza2000
30.05.2026 11:44В таком варианте надо как-то учить распознавать сайт замаскированный трафик. Гораздо проще повесить на 443 xray и фолбэком ему назначить nginx на внутреннем порту. В этом случае заходим по 443 браузером и видим котиков) А c xray по этому порту можно поговорить, только если знать протокол и иметь ключ, иначе будут только котики...
HardWrMan
30.05.2026 11:44В своё время, когда был популярен IRC 15+ лет назад, был такой сайт mibbit, с лягушкой в эмблеме, он позволял использовать IRC в браузере, достаточно было знать адрес сервера, имя канала и юзер/пароль, если требовались. Вашей идее 100 лет в обед.
Loundy
30.05.2026 11:44Если Вы используете Reality, то это обычное поведение. При инициировании TLS-соединения Reality подключается к маскировочному сайту. Когда этот сайт не отвечает, не работает и прокси.
alex09102026
30.05.2026 11:44маскировка под сайт выглядит так -
- nginx отдаёт нормальный сайт на /
- на пути /x98fgRtenxkdgfj75 (какой-то длинный рэндомный путь) — проксирует в xray
NAI
30.05.2026 11:44что на нем даже главная не отрывается
Чисто теоретически, что будет делать ТСОЦ если у нас mTLS? Пускать под нож всю идеологию ZeroTrust ну такое себе (я конечно понимаю что там всем пофигу, но тут уж проще только православные сертификаты выдавать, а остальное блочить)
semmaxim
30.05.2026 11:44Так VLESS+XRAY именно так и работают. Они "сбоку" видятся как обычный https трафик. И даже если ТСПУ сам постучится на сервер, то ему ответ придёт в виде вполне легитимной и правильной странички.
Wolf4D
30.05.2026 11:44Это да, но статья о том, что ТСПУ это отслеживает по несовпадению характера трафика с загрузкой веб-страниц. А я о том, что ведь можно и пойти дальше, и пользователю также возвращать веб-страницы, только с пейлоадом. Тогда ни один детектор не отличит, где срач на форуме, а где редирект сообщений через "фейковый" форум
mrcatnapper
30.05.2026 11:44Это возможно, но очень недружелюбно к конечному пользователю туннеля и администратору сервера:
-
Нужно хостить конкретный новый сайт типа
funny-cats-not-suspicious.ru, чтобы его бэк мог после TLS-терминирования прочитать расшифрованное тело GET/POST и отправить ответ обратно. Соответственно, весь сайт можно полностью заблокировать по SNI после первого подозрения.Теоретически, можно использовать любой чужой двунаправленный разрешённый канал передачи (типа чата Avito или Яндекс.Телемост, но это другое семейство подходов).
На клиентской стороне снова придётся использовать что-то похожее на браузер, смешивающее и расщепляющее обратно настоящие смешные картинки с полезным proxy-трафиком.
Иначе, если используем настоящий браузер, фронтенд сайта должен общаться с условным
127.0.0.1:12345в LAN (или на самой машине/смартфоне), на котором слушает TUN- или проще socks-proxy, который как раз перекидывает трафикapp <-> socks <-> browser[cats.ru].
Пока писал, понял, что подход интересный, и неплохо формализуется: достаточно иметь несложную JS-либу для фронтенда/бэкенда, и клиентское/серверное приложения, с которыми общается эта либа (большую часть можно собрать из готовых кирпичей).
Минусы:
в п.1, бэк сайта должен быть полностью подконтролен администратору входной ноды;
как сказано, сайт очень просто заблокировать по SNI, если соединение без Encrypted Client Hello;
плохая защита от реверс-инжинирига: в JS на клиентской стороне даже с обфускацией можно будет явно найти попытку соединения с условным
127.0.0.1:12345— значит, сайт-то непростой, в бан его.сайт-носитель должен быть постоянно открыт (решаемо, но может быть противно, держать на том же устройстве или в LAN работающий набор вкладок).
Плюсы:
можно прятаться за CDN;
носитель соединения — настоящий браузер, отличить его от настоящих соединений при хорошем shaping нереально;
ну и собственно shaping — можно сколько угодно аккуратно троттлить и фрагментировать трафик, делая его неотличимым от обычного сёрфинга.
(Микрореклама: работаю над проектом FPS, который, теоретически, способен использовать любые TLS-носители для передачи полезного трафика.)
-
cucumslice
30.05.2026 11:44Учитывая статистический подход к анализу трафика, где кучу параметров у TLS/TCP анализируется - будто хорошей идеей становится гонять трафик на высоких UDP портах, который вообще ни на что не похож абсолютно.
Потому что одна ошибка в маскировке (неправильный SNI, fingerprint и прочее) буквально сразу триггер для DPI и после VLESS серверов с условным махом на 8443 порту начинается naive proxy и прочая дичь.
Кроме того, не забываем, что VLESS априрори для обхода блокировок используется, чего не скажешь о древних openvpn/l2tp+ipsec, которые классика для корпоративных туннелей, которые после недавно сломанного эквайринга побаиваются трогать. Wireguard с трудом сюда еще проходит. В общем я о том, что небольшое количество понятного трафика классических L2-L3 туннелей могут стерпеть, чем кривую маскировку.
Так что все эти шаблонные настройки для VLESS ток упрощают работу по тому, чтобы найти и вычислить и не можешь нормально замаскироваться - просто не будь похожим не на что, hyseria2 + salamander/awg2.0 в помощь.
Iustinianus
30.05.2026 11:44Извините, не айтишник, инжинигер.
Это получается, на всех крупных сетевых узлах стоит некое (и полагаю очень большое) количество вычислительных процессоров (видимо, CPU или GPU) для онлайн-анализа гигабитных объемов трафика?
Oncenweek
30.05.2026 11:44Именно, зазовутся они официально ТСПУ. стоят великие миллиарды, и еще недавно выделили дополнительно великие миллиарды чтоб нарастить их мощность вдвое к 2030му году
Iustinianus
30.05.2026 11:44Господи Иисусе, тут хер пробьешь закупку лишнего вычислительного сервера, микросхемы рассчитывать, про перенос вычислений на GPU, как европейцы делают, я вообще молчу и не заикаюсь, а этим уродам вагон с баблом выделяют... Очень сильно демотивирует делать что-то новое.
dartraiden
30.05.2026 11:44Это вы ещё не интересовались, сколько триллионов в год выделяют министерству обороны на производство продукции, единственная задача которой куда-то долететь и там уничтожиться.
LiamBlue
30.05.2026 11:44Пишут, что пропускная способность одного блока ТСПУ - 100 ГБит/сек. Машинки явно крайне мощные, если способны на такой скорости исследовать трафик.
theult
30.05.2026 11:44Себестоимость есть, и она конечная. Условно миллион пакетов в секунду прогнать по тысяче правил = 1 млрд проверок. Кратно количество правил увеличить нельзя, нет кратного запаса производительности. Этим принципом конечности возможностей и пробивает zapret/byedpi, главное узел не был в списке блокировок по ip или ip всей подсети. Подсети проще, правил много меньше. Но и попутный ущерб гораздо больше, можно что-то нужное грохнуть.
Grigo52
30.05.2026 11:44Там не обычные десктопные процессоры стоят, а специализированные сборки на ПЛИС. Они аппаратно заточены чисто под разбор сетевых пакетов на лету, поэтому и тянут такие объемы
Stepashka20
30.05.2026 11:44А как ТСПУ анализирует поведение трафика? Ведь для этого надо неимоверные объёмы оперативки. Соединений миллионы в секунду и все их надо хранить, дополнять новыми запросами а после анализировать. Выглядит как что то нереальное
DerTosser
30.05.2026 11:44Это ведь специализированная железка, по типу как асики для майнинга, всё делается налету, зачем хранить? Хранить по закону Яровой обязали провайдеров, это другое направление. Естественно что метаданные и данные для статистического анализа пересылаются для обработки, и скорее всего уже не человеками, а нейросетью, но это тоже ответвление, сама коробка ТСПУ тупо исполняет приказы, быстро исполняет. Сетевая система у неё быстрая, если это на магистральных каналах, то боюсь представить, там же что-то порядка 400-800Gb/s должно быть, если не больше.
mrdandomi
30.05.2026 11:44А никто не хочет написать про то, что текст нейронкой написан? Читать противно
SukharevAndrey
30.05.2026 11:44Причём не какой-то нейронкой, а именно GPT 5.x, которая отвратительно пишет на русском языке.
Бросается в глаза по трём основным признакам:
1) Излишнее использование англицизмов. Большее, чем пишет реальный человек.
2) Постоянные "фразы в кавычках".
3) Много коротких односложных предложений, идущих подряд.
gorchaqw
30.05.2026 11:44О, Спасибо! Значит, нужно писать ботов которые будут показывать активность 24/7, похожую на человеков и пропускать пользовательский трафик по своим отпечаткам при необходимости.
hafewix
30.05.2026 11:44Помню, во времена Windows'95 пользователи грозились лично БГ на почту отправлять свап-файл. Не в курсе - сработало или нет. Но если всей страной начать гонять терабайты бесполезных данных - интересно было бы понаблюдать реакцию РКП =)
MountainGoat
30.05.2026 11:44Реакция будет одна: 15 Гб на рыло в месяц плюс список исключений. Чего там интересного наблюдать?
Grigo52
30.05.2026 11:44Генерировать мусорный трафик дорого в первую очередь для самого пользователя и провайдера аплинка. Ты быстрее свой домашний роутер или свич в подъезде положишь, чем магистральный узел
nixtonixto
30.05.2026 11:44генерировать фейковый «веб-подобный» трафик поверх реального — это огромный overhead, который убивает производительность и всё равно не идеален
Это overhead, но в этом и плюс. Особенно если до начала подключения надо "скачать" или "загрузить" десятки МБ, как на обычный файлообменник, и только потом в потоке этих псевдорандомных данных пойдут handshake и данные скрываемого приложения. Причём для того, чтобы всё это детектировать и отличить от обычной выгрузки файла - надо держать в ОЗУ все эти десятки МБ и для расшифровки нужно будет кратковременно нагрузить вычислениями процессор на 100%. Для пользователя в эпоху безлимитов такой трафик и подзависание аппарата будут некритичны, как и для инфраструктуры, уже давно гоняющей пользователям гигабайты потокового видео, но для системы фильтрации такая нагрузка будет приговором.
Grigo52
30.05.2026 11:44Забавно как попытка замаскироваться под хром выдает тебя с потрохами, потому что твой "хром" не качает баннеры и аналитику гигабайтами
Идеальный секьюрити-инцидент - юзер не смотрит рекламу, значит точно шпион
Lozman31
30.05.2026 11:44Так бы усердно боролись бы с БПЛА которые кошмарят города России. Вместо того чтобы вводить белые списки выявляли бы "аномальных" абонентов базовых станций по LBS технологии с анализом поведения абонента. Явно это не обычный абонент если он передвигается со скоростью 100км час по пересечённой местности через реки , леса, другие преграды.
yahooyaks
30.05.2026 11:44Может эти дроны - кого надо дроны. Оправдывают любые "вынужденные" меры по отношению к населению.
vector777
30.05.2026 11:44Все эти потуги с блокировками снизу, обывателям, зачастую выглядят как санкции против своего же населения. У нас по моему РКН не любят где-то на равне с НАТО, а то ещё и сильнее, ибо суют нос уже в личное и активно там шоркаются. НАТО плевать, где там Васян сидит, а вот РКН - нет, и он Васяну напрямую жизнь усложняет.
Опасные игры это, когда государство настраивает население против себя, да ещё и в условиях активных боевых действий.
Сверху-то понятно, что прикрываются ограничениями Емелек к опасному контенту и пытаются сделать информационное пространство более управляемым. Но только они борются не с реальными причинами, а с последствиями, в том числе и своих же ошибок на мировой арене (я про то, что в принципе сверхдержавно позволили устроить условный "бардель" у своей же калитки, а уж потом туда вынужденно с волыной пошли, когда "бардель" уже отстроен). Теперь из окон "барделя" через забор палки и *овно метают, а наши вместо сноса "барделя" строят стены по всему периметру, но те все в дырах. А дыры эти тупо баблом затыкают, лишь бы через них ничего не видно было)
Minuette
30.05.2026 11:44Статья - лишь размышление (ИИ?) без попыток доказательств тезисов. У меня тоже недавно отвалился прокси, а помогло банальное ограничение одновременных TLS соединений до 3. С 4 уже получал таймауты. Никакого анализа у них нет, лишь топорные методы.
LiamBlue
Про статистические характеристики трафика - всё верно. Но самое главное мы упускаем. Что РКН теперь блокирует произвольные соединения, произвольные ресурсы интернета уже даже не однозначно вредные по его мнению, а просто банально подозрительные, как ему показалось. И никакого отчёта о своих действиях РКН не предоставляет. Просто что хочет, то и делает. Наводит всяческий хаос и беспорядок в интернет-коммуникациях, и всё ему сходит с рук. Сейчас уже с новыми DPI подходами и софтом - они могут поломать всё что угодно, хаотичным образом.
Вот представьте себе, что так вели себя бы власти в отношении людей? Подозрителен? Шляпу носишь не того цвета, и наперекосяк? Осанка странная? В концлагерь его, по заветам гестапо!
opusmode
Власть практически так себя и вела. Или вы забыли, как людей с зелёными вещами задерживали в уентрк в марте 22го?
rzerda
Не знаю, кому и по какой причине удаётся упустить вот эту первую цель буквально в публичной декларации целей и задач РКН на сайте этого самого РКН. А ещё там сверху написано, что РКН не хаос наводит, как Вы тут изволили выразиться, а обеспечивает стабильность в обществе.
HardWrMan
А есть чёткое определение этих "социально значимых ресурсов"? Ато может, лично для меня, оранжевый ютуб вполне себе социально значимый.
Oncenweek
Нет, нельзя. “Четкое определение” это свойства заранее установленный и оговоренных правил, которые не могут произвольно меняться по желанию левой пятки. То есть ровно того, чего они делать совершенно не хотят, наоборот правила должны быть максимально размыты и запутаны, чтоб каждый под Дамокловым мечом ходил
rzerda
Целый список есть, и постановление Правительства РФ от 29.12.2021 №2531, определяющее правила попадания в него. Когда этот оранжевый ютуб переедет в Россию и там начнут появляться страницы местных органов самоуправления, тогда приходите.
Вот рядом комментатор говорит, мол, правила должны быть и не меняться по желанию левой пятки, и чёткие. Так вот они, и когда некоторые граждане говорят «у нас в стране всё по закону» - так и есть. Когда РКН и Минцифры говорят, что они исполняют существующие законы - так и есть. А если кто-то продолжает подменять у себя в голове законность собственными представлениями о справедливости или логичности или о чём угодно ещё - ну что ж, желаю всяческих удач.
Alexinthecold
Ну-ка расскажите мне о законности блокировок всех крупнейших постеров зарубежных и cdn??
rzerda
Рассказываю! Российские законы это не закон всемирного тяготения, и поэтому между отстыковкой яблока от яблони и началом падения его на землю может быть ощутимый временной лаг. Или, например, первые 16 грамм яблока могут падать на землю, а остальное яблоко - нет.
Владелец яблони может обратиться в суд, если считает, что его права нарушены. В суде ему напомнят про закон о приземлении, приоритет местного законодательства над международным и прочие увлекательные вещи. И может быть даже починят его яблоки года через три разбирательств. Зачем владельцу яблони тратить своё время и деньги на это ради какого-то небольшого количества странно ведущих себя яблок - непонятно.
Стоящий под яблоней гражданин России, ждущий, что на него упадёт всё яблоко, а не только 16 грамм, тоже может обратиться в суд для защиты своих прав, а если его не устроит решение суда - подать апелляцию, и так пока суды не кончатся. Как сделал, например, гражданин Ларионов (иск еле нашёл, ещё бы ходатайство РКН почитать). Процесс этот тоже небыстрый, закончится наверняка торжеством правосудия, если до ВС/КС дойдут (как в деле Долиной, например). Но если в процессе заявителю активно подставляться под административную ответственность, то шансы несколько уменьшаются.
В общем, решения суда о незаконности блокировок нет, поэтому лично Вы их можете считать незаконными, но более незаконными с точки зрения закона они от этого не становятся. И не то чтобы это чисто российское развлечение - посмотрите на цитадель демократии с её центром имени Трампа и Кеннеди, и как местное население этому всему радуется. Тред начался с того, что люди не замечают поведения, буквально написанного на лице у объекта.
d3d14
А если я, как гражданин РФ, считаю, что мои права нарушены блокировкой для меня ресурсов - к кому обращаться? В суд - уже обращались, бесполезно.
rzerda
Номер дела не подскажете? Если это про того же гражданина Ларионова, про которого я упомянул в следующем после цитируемого абзаце, то там всего два отказа в рассмотрении пока. Ну то есть, какие были ожидания от подачи иска, что Таганский суд скажет «а, да, точно, фигня какая-то; слышь, ты, министерство, ну-ко прекрати щасже блокировать телеграм»?
Вы идёте судиться с государством как на детский утренник, а потом удивляетесь результатам.
d3d14
Вот честно - никаких ожиданий от этого государства у меня давно уже нет. Кроме ожиданий дальнейшего ухудшения жизни.
В том числе от таких исков не было никаких ожиданий.
Alexinthecold
>В суде ему напомнят про закон о приземлении,
какое приземленеи вы о чем? бОЛьшая часть этих команий не оказывает услуги в РФ, а часть официально ушли...
rzerda
Если эти компании ушли или не оказывают услуги в России, то им нет ни резона, ни средств доказывать незаконность блокировки, и написанное мной в прошлом комментарии по существу не меняется.
Для признания на территории Российской Федерации чего-то незаконным одного жжения в тканях недостаточно, нужно обязательно в суд идти и/или жалобы писать. Вы не спрашивали меня о правильности или оправданности или справедливости блокировок. Вы спросили о законности. Я вижу, что Вы недовольны, но не понимаю, почему Вы недовольны мной, как будто это я Вам что-то блокирую или в суд не пускаю или в ответ на Ваш иск пощу мемы с котятами.
feyd12
А вот вопрос к эксперту по законности блокировок. У нас Хуавей под санкциями, и если нет магазина от Гугл, есть желание поставить приложение той же управляющей организации, которого нет в русторе. Есть Aurora Store, который позволяет это сделать. Его почему накрывают блокировки?
Alexinthecold
Извините на они уже всё поломали. Вы когда последний раз заходили в Интернет без прокси VPN или запрета? Я ради интереса открыл браузер на первые несколько страниц абсолютно нейтральные поиск у меня не работал 98% ресурсов. Что неудивительно при поголовном массовом замедлении всех крупных зарубежных остров иcdn . Абсолютно незаконных. Даже в рамках текущих так называемых законов.
peschex0d
Презумпция виновности.
Или, как вариант, бесполезности: если мне хватает цитат интернета бумажными распечатками на стол, то и другие без гитхаба обойдутся.