История confrontation между мессенджерами и системами глубинного анализа трафика (DPI) напоминает гонку вооружений: как только цензура учится распознавать сигнатуру протокола, разработчики придумывают, как его замаскировать.
В 2018 году Telegram ответил на блокировки в России запуском MTProxy — легковесного прокси, который долгое время оставался «золотым стандартом» обхода ограничений. Но DPI-системы эволюционировали: они научились выявлять специфические паттерны рукопожатия MTProxy и статистические аномалии в потоке данных, даже не расшифровывая содержимое.
К августу 2026 года команда Павла Дурова представила архитектурный ответ на этот вызов — транспорт WEB Proxy, который не просто шифрует трафик, а делает его неотличимым от обычного посещения веб-сайта.
Инкапсуляция вместо замены
Главное архитектурное решение WEB Proxy — отказ от создания нового криптографического протокола. Вместо этого разработчики выбрали стратегию инкапсуляции: клиент устанавливает классическое MTProxy-соединение с его проверенной шифровкой (AES-256-CTR и протокол FakeTLS), а уже готовый зашифрованный байтовый поток «упаковывается» в веб-транспорт. Веб-компонент (bridge-страница в WebView) не имеет доступа к ключам и не видит полезной нагрузки — он выполняет роль «трубы», доставляющей оперирующие кадрами данные между клиентом и сервером-посредником (tproxy-server).
Такой подход решает сразу две проблемы. Первая — криптографическая консерватизмность: не нужно доказывать надежность новой схемы шифрования, достаточно довериться аудированному MTProxy. Вторая — операционная безопасность: оператор WEB Proxy-сервера технически не может расшифровать пересылаемый трафик, а клиент не может использовать ретранслятор для подключения к произвольным адресам. Это исключает риск превращения узла в открытый прокси для третьих лиц.
Мультиплексирование и четыре режима доставки
Поскольку HTTP/1.1 и даже WebSocket по своей природе ориентированы на запрос-ответ или одиночный дуплексный канал, а Telegram требует множества параллельных логических потоков (обновление чатов, загрузка медиа, синхронизация контактов), команда реализовала собственный легковесный протокол мультиплексирования поверх веб-транспорта.
Он оперирует набором кадров: OPEN/CLOSE для управления жизненным циклом потока, DATA для полезной нагрузки, WINDOW для контроля потока (backpressure), PING/PONG для keep-alive и HELLO/WELCOME для рукопожатия сессии.
Серверная часть tproxy-server (пока в статусе proof-of-concept) принимает общий веб-поток на порту 443, демультиплексирует его на отдельные логические соединения и проксирует каждое локально к официальному MTProxy. Для самой доставки кадров предусмотрено четыре режима, выбор которых остается на стороне сервера:
- Последовательные HTTPS-запросы (long-polling стиль);
- Раздельные HTTPS-каналы для каждого логического потока;
- WebSocket с мультиплексированием в одном соединении;
- WebSocket с выделенным соединением на поток.
Все варианты используют стандартный порт 443 и TLS, что делает трафик неотличимым от работы с любым современным веб-приложением.
Стелс-вход
Ключевой элемент маскировки — механизм входа. Пользователю (клиенту) известны только домен и секрет MTProxy. На их основе клиент локально вычисляет служебный параметр, который добавляется к URL bridge-страницы. Секрет при этом никогда не попадает в JavaScript-код и не уходит в сеть в открытом виде. После успешной загрузки страницы параметр стирается из адресной строки, и сервер выдает временный 256-битный токен для авторизации сессии.
Если тот же URL открыть без правильного параметра — сервер отдаст обычную домашнюю страницу. Владелец домена может разместить там полноценный сайт с API, блогом или лендингом. Прокси-функционал активируется только для обладателя корректной пары «домен + секрет».
Это реализует принцип plausible deniability (правдоподобие отрицания): администратор сервера может честно заявлять, что это просто личный блог или корпоративный портал, а DPI-системе не удастся найти признаки прокси-инфраструктуры на корневом пути домена.
Песочница WebView: минимализм как защита
Поскольку bridge-страница загружается в WebView (на десктопе — через встроенный движок или резервно через системный браузер, на Android — через Android System WebView, на iOS — через WKWebView), поверхность атаки со стороны потенциально скомпрометированного сервера сводится к минимуму. В окружении намеренно отключены:
- Cookies, LocalStorage, IndexedDB, Service Workers — исключена персистентность и трекинг;
- Доступ к камере, микрофону, буферу обмена, файловой системе, геолокации;
- Загрузка внешних ресурсов (скриптов, шрифтов, картинок с других доменов);
- Всплывающие окна, формы, навигация по ссылкам.
Разрешены только: встроенный скрипт страницы, HTTPS/WebSocket-соединение строго с тем же доменом (Same-Origin Policy) и специальный интерфейс IPC для обмена кадрами с нативным клиентом Telegram. Даже если злоумышленник получит контроль над сервером и подсунет вредоносный JS, он не сможет выкрасть данные пользователя, заразить систему или деанонимизировать клиент — изоляция на уровне движка браузера это предотвращает.
Статус проекта
На момент августа 2026 года реализация в Telegram Desktop достигла стадии работающего прототипа: транспорт скрыт в коде, работает через WebView с фоллбэком на системный браузер. Параллельно ведутся работы над портами для Android и iOS. Однако пользовательский интерфейс настройки отсутствует: зарезервированные схема tg://webproxy и веб-ссылка t.me/webproxy неактивны, серверная часть tproxy-server распространяется как экспериментальный код без гарантий стабильности API. Сроки появления в стабильном релизе разработчики не анонсировали, что типично для инфраструктурных изменений, требующих длительного тестирования на реальных сетях с агрессивным DPI.
WEB Proxy демонстрирует зрелый подход к проблеме цензуры: вместо криптографического «танца с бубном» команда делает ставку на мимикрию под легитимный веб-трафик и жесткую изоляцию исполняемого кода. Если технология докажет свою живучесть в полевых условиях, она может стать новым стандартом для обхода блокировок не только в Telegram, но и в других проектах, сталкивающихся с необходимостью скрыть сам факт использования прокси.
