Механизм обхода блокировок Telegram в России работает все хуже. Разбор #9

Как устроен этот текст

Кратко — что случилось
Как устроена блокировка
Что говорил Роскомнадзор, а что — Telegram?
Что делать?
Источники

Что это за рубрика?

В рубрике «Разбор Теплицы» мы в режиме реального времени разбираемся в определенной проблеме, новостях интернет-цензуры и рассказываем:

что происходит;
как это устроено;
как с этим можно бороться

Есть мысли по поводу темы? Поделитесь с нами! Заполните небольшую форму и расскажите, что вы думаете про устройство новых ограничений и как можно минимизировать ущерб для них операторам VPN и обычным пользователям

Подсказать решение

Кратко

В конце мая 2026 года в рунете зафиксированы массовые отказы MTProto-прокси. Сервисы, через которые пользователи обходили ограничения Telegram, перестали работать практически одновременно у всех операторов. «Код Дурова» 27 мая сообщил о «беспрецедентном» числе жалоб; проблемы фиксировались по всей стране вне зависимости от оператора и региона.

Аналогичная ситуация наблюдалась в апреле, однако масштаб блокировок конца мая значительно шире. Принципиальное отличие: ТСПУ перешли к анализу характеристик трафика вместо проверки конкретных IP-адресов и портов.

Механизм

Исследование редакции: работоспособность MTProxy, май 2026

Мы собрали данные о работоспособности MTProxy в 4 регионах и 6 сетях в период с 27 по 31 мая. Из 27 проверенных конфигураций рабочими оказались три.

Регион	Оператор	Тип подключения	Проверено	Работает
Ростов-на-Дону	ДОМ.РУ	Домашний	11	1
Ростов-на-Дону	Мегафон	Мобильный	11	1
Московская обл.	МТС	Мобильный (4G)	4	0
Московская обл.	Инфолинк	Домашний	4	0
Екатеринбург	YOTA	Мобильный (4G VoLTE)	4	0
Новосибирск	Электронный город	Домашний	4	2

Что мы заметили

Рабочие прокси были только в сетях региональных провайдеров. На федеральных операторах (МТС, YOTA) ни один из восьми протестированных прокси не установил соединение. Один и тот же прокси trump.chunkycorp.shop:443 из канала @ProxyMTProto (11,7 млн подписчиков) не прошёл на YOTA в Екатеринбурге и прошел в сети оператора «Электронный город» в Новосибирске. На федеральных сетях обновленные правила ТСПУ применялись быстрее, чем у региональных провайдеров.

Еще три наблюдения

Нестандартные порты (853, 8443, 7980, 44300) не давали преимущества: их блокировали наравне с 443.
Fake-TLS (ee-секреты) не спасал на федеральных сетях.
Пинг 778 мс у одного из рабочих прокси косвенно указывает на то, что сервер расположен, вероятно, в Европе: российскую хостинговую инфраструктуру все чаще «режут» по ASN целиком.ё

Наша выборка невелика (n = 27, 6 сетей, 4 региона) и не претендует на строгую репрезентативность; это срез, а не замер по стране. Оценки других изданий расходятся. «Код Дурова» квалифицирует масштаб как рекордный; Meduza фиксирует, что большинство VPN на момент сбоя продолжали работать. Наши данные ближе к оценке «Кода Дурова» применительно к MTProxy: сбой затронул MTProxy, а не все инструменты обхода одновременно.

Воспроизвести измерения в своей сети можно через OONI Probe у него есть готовый тест Telegram, а результаты публикуются в открытой базе с привязкой к ASN оператора.

История ограничений

Уровень 1. Блокировка по IP-адресам и портам (до 2025 года)

Базовый метод фильтрации: внесение серверов Telegram в реестр запрещённых IP-адресов. Этот подход применялся в период блокировки 2018–2020 годов.

MTProxy разрабатывался как инструмент обхода именно IP-блокировок: Telegram обновлял адреса быстрее, чем РКН успевал их добавлять в реестр.

Уровень 2. Детекция по TLS fingerprint (март–апрель 2026)

MTProxy использует механизм Fake-TLS: трафик оборачивается так, чтобы начало соединения выглядело как TLS 1.3-хэндшейк к легитимному домену. ТСПУ идентифицировали такой трафик как HTTPS и пропускали соединение.

В марте 2026 года, по данным Digital Report, ТСПУ получили обновленные правила, основанные на анализе JA3/JA4-отпечатков (хешей от параметров TLS ClientHello). Реальный Chrome формирует ClientHello с конкретным набором cipher suites, расширений и эллиптических кривых в определённом порядке. Реализация Fake-TLS в Telegram этому набору не соответствовала: система начала помечать соединения, где ClientHello заявляет Chrome, но JA3-хеш не совпадает ни с одной реальной версией браузера. 1 апреля прокси «встали» по всей стране одновременно; об этой волне писал Хабр.

Уровень 3. Статистический анализ сигнатур (май 2026)

JA3-детекция имеет ограничение: отпечаток можно воспроизвести. Зная точный хеш свежей версии Chrome, можно сформировать идентичный ClientHello. Разработчики прокси применили этот подход в апреле.

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

распределение размеров пакетов (MTProto передает данные в блоках предсказуемого размера);
тайминги между пакетами (равномерные интервалы без вариаций нетипичны для реального HTTP/2);
концентрация соединений к одному узлу.

Возможно, РКН параллельно перешел от блокировки отдельных IP к блокировке целых ASN-подсетей и начал ограничивать TCP-трафик без характерных признаков стандартных протоколов; эта информация не получила прямого подтверждения в крупных изданиях. Как пишеот Meduza, блокировки затронули не только MTProto, но и VLESS, WireGuard, XTLS/XHTTP, gRPC и частично Hysteria. Степень воздействия варьировалась по протоколу, конфигурации и оператору: часть подключений на этих протоколах продолжала работать там, где MTProxy перестал полностью.

О систематическом характере эскалации свидетельствуют бюджетные данные. На автоматизированную систему обеспечения безопасности интернета (АСБИ), управляющую ТСПУ, в федеральном бюджете заложено около 40 млрд рублей: 20 млрд в 2026 году и столько же суммарно на 2027–2028 годы. Ещё 2,3 млрд выделено на ИИ-систему анализа трафика. Официальный целевой показатель: 92% эффективности блокировки средств обхода к концу 2030 года, по данным Forbes Russia.

У нас есть разбор идеи РКН побороть VPN на 92%

Клиентское приложение: ошибки Fake-TLS в Telegram Desktop

Когда 1 апреля прокси встали, Telegram не выпустил официальных исправлений; анализом занялось сообщество. Хабр пишет, что энтузиасты перехватили TLS-хэндшейк настоящего Chrome и хэндшейк Telegram и поочередно меняли поля пакета на живой сети, пока не нашли детектируемую сигнатуру. За сутки обнаружились два конкретных бага:

Первый: код использовал идентификатор расширения 0xFE02, которого нет в спецификациях, вместо корректного codepoint 0xFE0D (ECH).
Второй: публичный ключ X25519 объявлялся размером 32 байта, а генерировался длиной 20, хотя по спецификации он всегда занимает ровно 32. Оба факта подтверждаются аналогичными исправлениями в мобильных клиентах.

Находки оформили в Pull Request #30513 к tdesktop, однако этот запрос админ с ником john-preston перевел в статус in this form. Конкретные изменения в итоге вышли отдельным коммитом без публичного объяснения от команды.

При этом проблема исправлена только в Desktop-клиенте. iOS-клиент, Android-клиент и все приложения на tdlib по-прежнему детектируются по тем же сигнатурам; PR для мобильных платформ на момент написания оставались в работе. За двумя исправленными багами тянется список незакрытых поведенческих сигнатур, которые правкой JA3/JA4-параметров не устранить.

Тезис «Telegram бездействовал, а сообщество все починило» оспаривает в треде PR #30513 мейнтейнер ilya-fedin: основную работу по ClientHello Telegram проделал еще в прошлом году, допустив ошибку в двух строках; исследование сообщества помогло найти баг, но предложенные правки были сырыми. В целом крупный фикс Telegram сделал до блокировки, исследование провело сообщество после, PR отклонен, коммит с правкой появился без официального сопровождения.

Более подробно о выявленных проблемах
(кликните, чтобы открыть таблицу)

Проблема	Серьёзность
Фиксированная длина всего ClientHello (padding ровно до 513 байт)	Критическая
ECH-payload с фиксированной длиной на весь жизненный цикл приложения	Критическая
После handshake декларируется h2, но MTProto идёт без HTTP-фрейминга	Критическая
Устаревший codepoint ALPS эпохи Chrome 115	Высокая
Darwin-ветка: cipher suites, удалённые Apple ещё в 2021 году	Высокая
Ровные inter-packet timings без джиттера	Высокая

Серверное приложение: состояние официального репозитория MTProxy

Помимо клиентских ошибок, официальная серверная часть MTProxy деградировала структурно.

Последний коммит в репозитории (cafc338) датирован 4 ноября 2025 года: к маю 2026-го полгода без обновлений при 50 коммитах за восемь лет существования проекта. В 39 открытых pull request показательна история с крэш-багом при PID > 65535: его независимо исправили трое участников (PR #653, #669, #673), и ни один ответа не получил. Из 296 открытых issues без реакции остаются отчеты о вылетах и о полной неработоспособности; среди 39 открытых pull request ни один не получил ответа.

Docker-образы стали отдельным симптомом. Официальный репозиторий telegrammessenger/proxy держит теги в принципиально разном состоянии:

Тег latest не обновлялся около шести лет и содержит бинарник без поддержки Fake-TLS: он запускается, но полностью детектируется современными DPI.
Тег 2.0beta, выпущенный в апреле 2026-го, наоборот, не запускается вовсе: стартовый скрипт обращается к команде ip из пакета iproute2, которого нет в базовом образе; заведенная по этому поводу заявка от пользователей осталась без ответа. Итог буквальный: запускается лишь то, что детектируется, а то, что не детектируется, не запускается.

MTProxy строится на закрытой спецификации: что и в какие сроки менять, единолично решает одна компания. В отличие от VLESS/XTLS или sing-box, где правки вносит распределенное сообщество, изменения MTProxy проходят через внутренний процесс одного вендора.

Что говорил Роскомнадзор, а что — Telegram?

Роскомнадзор сообщил, что нужным организациям доступ к VPN-протоколам открывается по заявкам и что в перечень исключений уже включены более 57 тыс. адресов и подсетей 1 730 организаций, включая компании-разработчиков. Ведомство не оспаривает масштаб ограничений, но описывает механизм «белых списков»: фильтрация работает по умолчанию, доступ открывается по заявке.
Telegram публично эту тему не комментировал; вся видимая реакция свелась к правкам в репозиториях, причём неполным. Павел Дуров 4 апреля 2026 года написал, что команда мессенджера продолжит адаптировать трафик, делая его сложнее для обнаружения и блокировки. Каких-то подробностей Дуров не сообщил.

Что делать?

Альтернативные реализации MTProxy

На фоне нерабочих официальных образов сообщество поддерживает не меньше девяти независимых реализаций MTProxy (на Go, Rust, Zig, Python). Полное сравнение и рекомендации по выбору: telemt, mtproto.zig, teleproxy, 9seconds/mtg, alexbers/mtprotoproxy, Flowseal/tg-ws-proxy.

Официальный проект отстает на порядок. Там, где MTProxy за восемь лет набрал 50 коммитов и полгода стоит без обновлений, активные альтернативы выпускают релизы за дни до того, как о них пишут. Особенно показателен telemt (Rust): он не только поддерживает все режимы MTProto, но и сопровождается форком официальной библиотеки tdlib-obf, который закрывает ровно те сигнатуры в клиенте, что официально в tdlib так и не исправлены (профили ClientHello под разные браузеры, Dynamic Record Sizing, обфускация межпакетных интервалов). Это единственная альтернатива, охватывающая сервер и клиент одновременно.

Отдельно стоит teleproxy: это единственная из реализаций, где каждое заявление о DPI-устойчивости подкреплено автоматическим тестом в CI, от вычисления JA3-хеша до энтропии Шеннона в зашифрованных пакетах. Параллельно существуют автоматические сборщики прокси с обновлением каждые 12 часов и каналы с десятками миллионов подписчиков; они компенсируют нестабильность отдельных адресов, но не решают проблему детекции самого протокола.

Отдельно сообщество выпустило форк десктопного клиента Telegram для Windows, в котором при каждом подключении к прокси-серверу генерируется уникальное ClientHello вместо почти идентичного; это затрудняет детекцию через DPI. Инструмент доступен только для Windows и не вошел в официальный клиент. Работоспособность форка независимо не верифицирована. Редакция не проводила аудит и не может его рекомендовать.

Смена транспорта: универсальные прокси-протоколы

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

Все варианты требуют собственного VPS за пределами России. Перечисленные протоколы также испытывали давление со стороны ТСПУ в мае 2026 года, однако степень и распространенность блокировок у них ниже, чем у MTProxy.

VLESS+Reality до конца мая 2026 года показывал наименьший задокументированный уровень детекции: ТСПУ получают корректный ClientHello с реальным SNI и не могут отличить соединение от легитимного HTTPS при сигнатурном анализе. Однако с конца мая именно конфигурации на базе Reality фиксируют сбои в ряде сетей, что указывает на переход к статистическим или ASN-уровневым методам детекции.

AmneziaWG рандомизирует заголовки и первые байты WireGuard-соединения, делая трафик неотличимым от случайного UDP. Актуален сейчас потому, что стандартный WireGuard уже блокируется по сигнатуре, а форк лишает фильтр надежной точки детекции на уровне пакетов.

Hysteria2 поверх QUIC переводит трафик на UDP, переводя анализ в транспортный слой, для которого у ТСПУ накоплено меньше эвристик. Протокол документировано обновлял алгоритмы обфускации в ответ на методы детекции GFW, что подтверждает активность поддержки.

NaiveProxy использует HTTP/2-стек самого браузера Chromium: трафик формирует не прокси-клиент, а реальный движок браузера, поэтому поведенческие характеристики (тайминги, размеры пакетов, порядок фреймов) совпадают с легитимным Chrome. Заблокировать его без блокировки самого Chrome принципиально затруднено.

TUIC работает поверх QUIC и ориентирован на минимальную задержку при установке соединения; мультиплексирование запросов в одном QUIC-потоке усложняет корреляционный анализ трафика. Хорошо подходит для сред, где Hysteria2 уже попала в фокус блокировок.

Trojan имитирует TLS-соединение к настоящему веб-серверу: при активном зондировании со стороны ТСПУ сервер отдает реальную веб-страницу. Это затрудняет детекцию через активные пробы, которые всё чаще применяются вместе с пассивным анализом трафика.

Mieru проектировался специально для сред с жесткой фильтрацией: не несет фиксированных заголовков, размеры и тайминги пакетов рандомизированы, нет идентифицируемого рукопожатия. Уступает остальным по пропускной способности, но устойчив к статистическому анализу при небольших объемах трафика.

Все три уровня детекции MTProxy накладывались последовательно. При этом обнаружение второго и третьего уровней разделяют всего два месяца (март–май 2026).

У MTProxy есть проблемы с исправлением детекций. На клиенте исправление дошло лишь до Desktop, мобильные платформы несут те же сигнатуры; на сервере официальный бинарник нефункционален, а единственный вендор не реагирует на правки сообщества. Ограничения носят не технический, а организационный характер: закрытая спецификация, единственная точка поддержки, медленный релизный цикл.

Давление на инструменты обхода не ограничилось MTProxy. В мае под блокировки частично попали VLESS, WireGuard, XTLS/XHTTP, gRPC и Hysteria; конфигурации VLESS+Reality, до этого считавшиеся наиболее устойчивыми, фиксируют сбои с конца мая. Сообщество выпустило форк десктопного клиента Telegram с заявленным обходом детекции, однако его работоспособность не верифицирована.

Ни один из рассмотренных протоколов не застрахован от блокировки: степень воздействия варьируется по конфигурации, оператору и региону. Наибольшую устойчивость на момент написания показывают инструменты с открытой спецификацией, распределенной поддержкрй и автоматизированным тестированием DPI-устойчивости: telemt, teleproxy, mtproto.zig в рамках MTProto; AmneziaWG, Hysteria2, NaiveProxy, TUIC, Mieru и Trojan за его пределами. Общий признак: темп обновлений выше, чем периодичность изменений правил детекции.

Источники

Медиа

«В России усилили блокировку VPN и прокси». «Код Дурова»
«В мае власти РФ перешли к более хитрым методам борьбы с VPN и прокси». Meduza
«Роскомнадзор изменил алгоритмы блокировки Telegram». Digital Report
«Не соглашаясь с Большим Братом. Telegram и MTProxy». Habr
«Как DPI вычисляет MTProto-прокси». Habr
«Алгоритмические упражнения: РКН будет фильтровать трафик с помощью машинного обучения». Forbes
«Telegram обошел блокировку РКН (нет, не Telegram)». Habr
«РКН открыл 1730 российским компаниям доступ через VPN к зарубежным ресурсам». «Интерфакс»
«How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic». USENIX Security 2025
«Сообщество нашло способ вернуть работу MTProto-прокси в Telegram на ПК». «Код Дурова»
OONI Proobe

Разборы Теплицы

«Роскомнадзор хочет заблокировать почти все VPN. Или нет? И как быть?» Разбор #6.

Данные из GitHub и публикации Telegram

telegramdesktop/tdesktop: Pull Request #30513
DrKLO/Telegram: Pull Request #1949
TelegramMessenger/MTProxy
TelegramMessenger/MTProxy: Pull Requests
telegrammessenger/proxy: Docker Hub
Павел Дуров (@durov), пост №477, 4 апреля 2026. https://t.me/durov/477

Материал обновляется!