В рубрике «Разбор Теплицы» мы в режиме реального времени разбираемся в определенной проблеме, новостях интернет-цензуры и рассказываем:
Есть мысли по поводу темы? Поделитесь с нами! Заполните небольшую форму и расскажите, что вы думаете про устройство новых ограничений и как можно минимизировать ущерб для них операторам VPN и обычным пользователям
В конце мая 2026 года в рунете зафиксированы массовые отказы MTProto-прокси. Сервисы, через которые пользователи обходили ограничения Telegram, перестали работать практически одновременно у всех операторов. «Код Дурова» 27 мая сообщил о «беспрецедентном» числе жалоб; проблемы фиксировались по всей стране вне зависимости от оператора и региона.
Аналогичная ситуация наблюдалась в апреле, однако масштаб блокировок конца мая значительно шире. Принципиальное отличие: ТСПУ перешли к анализу характеристик трафика вместо проверки конкретных IP-адресов и портов.
Мы собрали данные о работоспособности 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 в Екатеринбурге и прошел в сети оператора «Электронный город» в Новосибирске. На федеральных сетях обновленные правила ТСПУ применялись быстрее, чем у региональных провайдеров.
Наша выборка невелика (n = 27, 6 сетей, 4 региона) и не претендует на строгую репрезентативность; это срез, а не замер по стране. Оценки других изданий расходятся. «Код Дурова» квалифицирует масштаб как рекордный; Meduza фиксирует, что большинство VPN на момент сбоя продолжали работать. Наши данные ближе к оценке «Кода Дурова» применительно к MTProxy: сбой затронул MTProxy, а не все инструменты обхода одновременно.
Воспроизвести измерения в своей сети можно через OONI Probe у него есть готовый тест Telegram, а результаты публикуются в открытой базе с привязкой к ASN оператора.
Базовый метод фильтрации: внесение серверов Telegram в реестр запрещённых IP-адресов. Этот подход применялся в период блокировки 2018–2020 годов.
MTProxy разрабатывался как инструмент обхода именно IP-блокировок: Telegram обновлял адреса быстрее, чем РКН успевал их добавлять в реестр.
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 апреля прокси «встали» по всей стране одновременно; об этой волне писал Хабр.
JA3-детекция имеет ограничение: отпечаток можно воспроизвести. Зная точный хеш свежей версии Chrome, можно сформировать идентичный ClientHello. Разработчики прокси применили этот подход в апреле.
Тогда ТСПУ перешли к статистическому анализу трафика, который сложнее имитировать. Анализируется поведение потока целиком, а не отдельные пакеты:
Возможно, РКН параллельно перешел от блокировки отдельных IP к блокировке целых ASN-подсетей и начал ограничивать TCP-трафик без характерных признаков стандартных протоколов; эта информация не получила прямого подтверждения в крупных изданиях. Как пишеот Meduza, блокировки затронули не только MTProto, но и VLESS, WireGuard, XTLS/XHTTP, gRPC и частично Hysteria. Степень воздействия варьировалась по протоколу, конфигурации и оператору: часть подключений на этих протоколах продолжала работать там, где MTProxy перестал полностью.
О систематическом характере эскалации свидетельствуют бюджетные данные. На автоматизированную систему обеспечения безопасности интернета (АСБИ), управляющую ТСПУ, в федеральном бюджете заложено около 40 млрд рублей: 20 млрд в 2026 году и столько же суммарно на 2027–2028 годы. Ещё 2,3 млрд выделено на ИИ-систему анализа трафика. Официальный целевой показатель: 92% эффективности блокировки средств обхода к концу 2030 года, по данным Forbes Russia.
Когда 1 апреля прокси встали, Telegram не выпустил официальных исправлений; анализом занялось сообщество. Хабр пишет, что энтузиасты перехватили TLS-хэндшейк настоящего Chrome и хэндшейк Telegram и поочередно меняли поля пакета на живой сети, пока не нашли детектируемую сигнатуру. За сутки обнаружились два конкретных бага:
Находки оформили в 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 деградировала структурно.
Последний коммит в репозитории (cafc338) датирован 4 ноября 2025 года: к маю 2026-го полгода без обновлений при 50 коммитах за восемь лет существования проекта. В 39 открытых pull request показательна история с крэш-багом при PID > 65535: его независимо исправили трое участников (PR #653, #669, #673), и ни один ответа не получил. Из 296 открытых issues без реакции остаются отчеты о вылетах и о полной неработоспособности; среди 39 открытых pull request ни один не получил ответа.
Docker-образы стали отдельным симптомом. Официальный репозиторий telegrammessenger/proxy держит теги в принципиально разном состоянии:
MTProxy строится на закрытой спецификации: что и в какие сроки менять, единолично решает одна компания. В отличие от VLESS/XTLS или sing-box, где правки вносит распределенное сообщество, изменения 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 — пример того, как закрытая спецификация с единственным вендором не выдерживает темпа, который задает регулярно обновляемая инфраструктура обнаружения. Инструмент с открытой спецификацией и распределенной поддержкой исправляется быстрее, чем регуляторы успевают обновлять правила. Это подтверждают примеры telemt, teleproxy и mtproto.zig.
С технической стороны данные мая 2026 года указывают на три приоритета.
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 и обычным пользователям