Август 2026: разбор новой прокси-технологии
Telegram WEB-Proxy

21 августа 2026 года Telegram официально представил новую экспериментальную технологию обхода блокировок под названием WEB-Proxy, а затем добавил её поддержку в Telegram Desktop 7.1.0. В отличие от традиционного MTProxy, WEB-Proxy больше не пытается «маскироваться» под веб-трафик. Вместо этого прокси-трафик Telegram действительно работает внутри WebView, устанавливая стандартные HTTPS- или WebSocket-соединения через браузерный движок, что делает его неотличимым от обычного веб-сёрфинга для систем цензуры.

В этой статье мы разберём технологию по четырём направлениям: философия дизайна, текущая ситуация с DPI, техническая архитектура и реальные результаты.

1. Философия дизайна: растворяться, а не маскироваться

Основную философию WEB-Proxy можно сформулировать в четырёх словах: растворяться, а не маскироваться.

1.1 От «маскировки» к «растворению»

Стратегия традиционного MTProxy — «маскировка»: он пытается сделать свой трафик похожим на обычный HTTPS. Но как бы хорошо он ни маскировался, само поведение соединения MTProto-прокси всё равно имеет распознаваемые признаки. Старый MTProxy пытался «выглядеть как» обычный веб-трафик, тогда как WEB-Proxy использует настоящий веб-стек. Сетевые фильтры сталкиваются со стандартным TLS- и HTTPS-трафиком, генерируемым браузерным движком.

Суть этого перехода: вместо того чтобы обманывать DPI («я выгляжу как веб-страница»), трафик по своей природе и есть веб-трафик.

1.2 Только для Telegram, а не глобальный прокси

Telegram продолжает углублять линию MTProxy, а не выпускает универсальный VPN или глобальный прокси. За этим стоит чёткий стратегический расчёт: в первую очередь решить проблему доступности самого Telegram и намеренно не предоставлять возможности глобального прокси. Если бы WEB-Proxy стал универсальной инфраструктурой обхода блокировок, он мгновенно привлёк бы адресные блокировки со стороны систем цензуры, вплоть до «сопутствующего» блокирования обычных сайтов, используемых как прикрытие. Обслуживая только трафик Telegram, заблокировать его — это как заблокировать мессенджер, а не универсальный сервис обхода, что снижает риск «избыточного таргетинга».

1.3 Zero-knowledge ретранслятор: relay ничего не видит

Ещё один ключевой принцип дизайна WEB-Proxy — zero-knowledge ретранслятор. Серверная часть tproxy-server рассматривает кадры DATA как непрозрачные байты: она не может выбрать пункт назначения Telegram и не может расшифровать поток MTProxy. Клиент выводит bridge-возможность локально, и сырой секрет никогда не попадает в JavaScript. Это значит, что даже оператор прокси не может подсмотреть содержимое переписки.

2. Текущая ситуация с DPI: эскалация 2026 года

2.1 Хронология волны блокировок 2026 года

2026 год стал годом самых жёстких блокировок Telegram в России и других регионах. Блокировки развивались в несколько этапов:

• Март 2026: РКН развернул на системе ТСПУ новые алгоритмы обнаружения прокси-соединений. Эти алгоритмы умели распознавать различия между клиентами Telegram и браузерами при установке шифрованных соединений.
• Апрель 2026: Telegram выпустил обновление клиента, сделавшее установку шифрованного соединения более похожей на браузерную, что временно решило проблему.
• Конец мая 2026: ТСПУ начал тестировать новые алгоритмы, анализирующие не только способ установки соединения, но и сигнатуры протокола для различения MTProto-клиентов и настоящих браузеров. С конца мая — июня началась новая волна блокировок.
• С 5 июня 2026: Telegram стал практически недоступен в России. Официальные MTProto-прокси (включая встроенный Fake TLS) были полностью заблокированы DPI, что затронуло всех клиентов (Desktop, Android, iOS) и всех крупных провайдеров (Ростелеком, МТС, Билайн).

2.2 Технические средства: отпечатки JA4

Ключевой метод обнаружения современных DPI-систем — анализ TLS-отпечатков JA4. Официальный клиент Telegram использует статический отпечаток JA4 в ClientHello; DPI-система, распознав его, немедленно вставляет пакеты RST и обрывает соединение. Даже при использовании Fake TLS стек TLS клиента всё ещё отличается от настоящего браузера, поэтому он также обнаруживается.

Сообщество подтвердило, что это проблема на стороне клиента: форки с динамической ротацией JA4 работают мгновенно на том же прокси и в той же сети.

2.3 Анализ поведенческих характеристик

Помимо TLS-отпечатков, DPI-системы 2026 года анализируют и поведенческие характеристики трафика. Анализаторы проверяют размеры пакетов, интервалы между ними, структуру TLS-соединения и другие косвенные признаки. Если трафик ведёт себя как прокси, одной маскировки под HTTPS уже недостаточно. Типичный сценарий — «проблема 16 КБ»: соединение успешно устанавливается и передаёт начальные данные, а затем внезапно ограничивается по скорости или обрывается.

3. Технические особенности: базовая архитектура WEB-Proxy

3.1 Общая архитектура

Архитектуру WEB-Proxy можно описать следующей схемой:

Telegram App
  → MTProto-соединение (сохраняется стандартная инкапсуляция и шифрование MTProxy)
  → локальный WEB-прокси-адаптер (один логический поток на каждое соединение приложения)
  → один транспорт WebView + аутентифицированная relay-сессия
  → мультиплексированные кадры (HTTPS- или WebSocket-носитель)
  → tproxy-server
  → одно локальное TCP-соединение на поток → официальный MTProxy

Клиент настраивает всего два значения: hostname и секрет MTProxy. Он выводит bridge-возможность локально, и сырой секрет никогда не попадает в JavaScript. WebView открывает bridge-страницу, обменивает короткоживущий bootstrap-токен на relay-сессию, а затем работает в режиме носителя, выбранном соответствующим профилем сервера. Кадры OPEN, DATA, WINDOW и CLOSE мультиплексируют все соединения Telegram.

3.2 Четыре режима носителя

WEB-Proxy поддерживает четыре режима транспортного носителя, выбираемых секретом/профилем, без дополнительных настроек на клиенте:

3.3 Особенности безопасности

В дизайне безопасности WEB-Proxy есть несколько ключевых моментов:

• Маскировка домена: настроенный hostname одновременно является обычным HTTPS-сайтом. Запросы без аутентификационных данных видят публичный сайт; только GET /?bridge=<валидная capability> раскрывает bridge.
• Постоянный ключ подписи: сервер использует постоянный ключ подписи (token.key). Отсутствие или неправильные права на ключ блокируют запуск; временный ключ молча не создаётся.
• Строгая политика на фронтенде: bridge-страница не использует cookie, браузерное хранилище, внешние ресурсы, workers, frames, медиа, попапы, загрузки, формы, разрешения устройств, API буфера обмена или кросс-доменные запросы.
• Контроль ёмкости: общепроцессные лимиты — это обязательная граница безопасности. По умолчанию max_sessions_global = 128, max_streams_global = 4096, max_backend_dials_in_flight = 256.

3.4 Архитектура развёртывания

Референсная архитектура развёртывания:

Internet :80/:443 → Caddy → 127.0.0.1:8080 tproxy-server → Сайт оператора
                                                   → 127.0.0.1:2398 официальный MTProxy

Только Caddy слушает внешние интерфейсы. Relay, административные эндпоинты, клиентский порт MTProxy и статистика остаются локальными. Relay никогда не получает выбранный клиентом backend-адрес и никогда не расшифровывает поток MTProxy. Caddy проксирует все пути к relay; отдельного публичного пути для неаутентифицированных зондов, с которым можно было бы сравнить, не существует.

4. Реальные результаты: текущий статус и отзывы

4.1 Статус поддержки на клиентах

По состоянию на август 2026 года поддержка на клиентах следующая:

• Telegram Desktop: официально поддерживает WEB-Proxy начиная с 7.1.0, в 7.1.1 исправлены некоторые ошибки, в 7.1.2 дополнительно улучшено соединение на Windows.
• Android: поддержка в бета-клиентах.
• iOS: пока на стадии планирования.

В клиенте пользователю достаточно ввести hostname и секрет; никаких портов и протоколов настраивать не нужно. Формат ссылки для обмена:

https://t.me/webproxy?server=proxy.example.com&secret=000102030405060708090a0b0c0d0e0f

4.2 Порог и стоимость развёртывания заметно выше

По сравнению с традиционным MTProxy или обычным прокси порог развёртывания, техническая сложность и стоимость WEB-Proxy заметно выше. Это уже не лёгкое решение «ввёл IP и порт — и работает», а требование полной серверной экспертизы: нужен собственный домен и публичный сервер, настройка DNS, обратный прокси Caddy, сервисы systemd, правила nftables и понимание основ WebView-носителей и кадрового протокола. Официальный установщик даёт определённую автоматизацию, но по-прежнему рассчитан на «чистый сервер, где Caddy владеет портами 80/443»; серверы, уже размещающие другие сайты, требуют ручной интеграции. Для обычного пользователя это означает переход от «использования публичного прокси» к «эксплуатации небольшого веб-сервиса», что существенно увеличивает временные, технические и постоянные затраты на поддержку. Именно поэтому в краткосрочной перспективе WEB-Proxy скорее будет применяться техническими сообществами, организациями и продвинутыми пользователями, готовыми разбираться, а не станет массовым, как публичный MTProxy.

4.3 Оценка эффективности

Преимущества:

• С точки зрения систем сетевой цензуры трафик WEB-Proxy почти неотличим от обычного посещения обычного сайта. Внешний наблюдатель видит только TLS-трафик к вашему домену; без расшифровки HTTPS его нельзя отличить от визита на обычный сайт.
• Поскольку трафик исходит от настоящего браузерного движка, его TLS-отпечаток совпадает с настоящим браузером, что решает проблему раскрытия отпечатка JA4, присущую традиционному Fake TLS.
• Четыре режима носителя можно гибко выбирать под сетевую среду, повышая устойчивость к разным стратегиям блокировок.

Ограничения:

• Серверная часть tproxy-server до сих пор помечена официально как proof-of-concept, стабильного релиза нет.
• Нужны собственный домен и сервер, а техническая сложность и стоимость развёртывания выше; пользователь не может получить сервис так же просто, как публичный MTProxy.
• Во время работы WebView в фоне загружает страницу провайдера прокси; провайдер может вставлять спонсированные каналы — потенциальный риск. Telegram официально предупредил об этом.
• Перезапуск relay инвалидирует активные carrier-сессии, и клиентам приходится переподключаться.
• На macOS WebKit WebSocket-рукопожатия могут сериализоваться, что замедляет установку соединения в режиме websocket-lanes; в этом случае нужно переключиться на режим websocket.

4.4 Сравнение с другими решениями

5. Выводы

WEB-Proxy — это значительная эволюция технологий обхода блокировок Telegram. За счёт того что прокси-трафик действительно работает внутри WebView, он переходит от «маскировки под веб» к «быть веб-трафиком», открывая новый путь выживания в условиях ужесточающегося DPI 2026 года. Философия дизайна — только для Telegram, zero-knowledge relay, никакого глобального прокси — отражает тонкий баланс официальных разработчиков между «доступностью» и «непривлеканием избыточного таргетинга».

Важно подчеркнуть, что порог развёртывания, техническая сложность и стоимость WEB-Proxy выше, чем у традиционного MTProxy. Это не одноклик-решение для обычных пользователей, а требование к оператору владеть доменом, сервером и навыками эксплуатации веб-сервиса. Сейчас WEB-Proxy всё ещё на стадии proof-of-concept, но с официальной поддержкой в Telegram Desktop и Android-клиентах, а также активным участием сообщества, эта технология может стать одним из ключевых решений для доступа к Telegram в условиях ограниченных сетей в будущем.

🎁 Хотите сами опробовать решение для обхода блокировок?