Telegram Desktop получил WEB-прокси поверх HTTPS для защиты от блокировок

Telegram добавил в стабильную версию Telegram Desktop новый тип подключения — WEB Proxy. Он переносит уже зашифрованный трафик MTProxy через встроенный браузерный компонент WebView и обычное HTTPS-соединение. Для внешней сети такой прокси должен выглядеть значительно ближе к привычному веб-сайту, чем классический MTProxy с имитацией TLS.

Функция появилась в Telegram Desktop 7.1.0, выпущенном 22 августа. Новый тип WEB указан в официальном списке изменений Telegram Desktop 7.1.0. Позднее в тот же день вышла версия 7.1.1 с исправлением загрузки чатов и мелкими правками; изменений WEB Proxy в ее описании нет.

Настройка появилась в стабильном настольном клиенте. При этом серверная реализация tproxy-server все еще официально называется proof-of-concept — проверкой работоспособности концепции. Мобильные варианты пока находятся на экспериментальной стадии.

WEB Proxy не заменяет MTProxy новым протоколом. Telegram сначала выполняет обычное преобразование и шифрование, используемое при подключении через MTProxy. Уже после этого получившийся поток поступает в локальный адаптер WEB Proxy. Адаптер разделяет подключения Telegram на логические потоки и передаёт их через один управляемый приложением WebView.

Схема, описанная разработчиками в репозитории tproxy-server, выглядит так:

Telegram → MTProxy → локальный WEB-адаптер → WebView → HTTPS/WebSocket → tproxy-server → обычный MTProxy → дата-центры Telegram.

На серверной стороне tproxy-server разбирает транспорт WEB Proxy обратно на отдельные потоки и открывает для каждого соединение с обычным официальным MTProxy. Сам ретранслятор не получает открытый Telegram-трафик: поле с данными остаётся для него непрозрачным набором байтов. Он также не позволяет клиенту произвольно выбирать конечный сервер — потоки уходят на заранее настроенный MTProxy.

Получается двухслойная конструкция. MTProxy продолжает отвечать за привычное для Telegram преобразование трафика, а WEB Proxy меняет внешний транспорт между пользователем и промежуточным сервером.

Первая развертываемая версия может вообще работать на обычных HTTPS-запросах fetch. В базовом режиме данные отправляются POST-запросами, а обратный поток приходит через длительный запрос с ожиданием ответа. Сервер держит такой запрос до появления данных либо до истечения 25 секунд.

В техническом плане WEB Proxy перечислены четыре режима транспорта. Первый использует последовательные HTTPS-запросы, второй создает отдельные HTTPS-каналы для логических потоков, третий переносит все потоки через один WebSocket, четвертый создает отдельное WebSocket-соединение для каждого потока. Режим выбирается на стороне серверного профиля — пользователь отдельный транспорт в клиенте не настраивает.

Поэтому точнее говорить, что WEB Proxy использует WebView и обычный веб-транспорт поверх HTTPS, а WebSocket является одним из предусмотренных вариантов.

Главная техническая идея проекта — передать установление внешнего веб-соединения браузерному движку.

У классического MTProxy есть режим Fake TLS, который пытается сделать подключение похожим на обычный TLS-сеанс. Проблема такой имитации в том, что специально сформированный TLS-трафик всё равно способен оставлять отличительные признаки.

WEB Proxy идет другим путём. HTTPS-соединение создает настоящий WebView — браузерный компонент операционной системы или приложения. Telegram при этом не пытается вручную воспроизвести поведение браузерного сетевого стека. Приложение делегирует WebView публичные DNS-, TLS- и HTTPS-операции, а сервер использует обычный TLS-сертификат и стандартный HTTP/1.1 или HTTP/2.

Цель архитектуры: убрать часть специфических особенностей прямого MTProxy/Fake TLS-соединения и перенести внешний транспорт в настоящий веб-стек.

WEB Proxy маскируется не отдельной заглушкой, а полноценным HTTPS-сайтом. Владелец прокси поднимает домен, например proxy.example.com, и размещает на нём обычный веб-ресурс. Это может быть статическая страница с разделами, изображениями и стилями либо настоящее веб-приложение.

Telegram знает домен и секрет MTProxy. На их основе клиент локально вычисляет специальное значение HMAC-SHA256 и открывает адрес вида https://домен/?bridge=.... Сам исходный секрет в URL не помещается.

Правильное значение параметра bridge заставляет сервер вернуть скрытую страницу-мост для WebView. Любой обычный запрос, неправильный параметр, дополнительный параметр или попытка открыть главную страницу без секрета получают обычный сайт с HTTP 200.

Такое поведение подробно зафиксировано в спецификации серверной части WEB Proxy. Разработчики советуют операторам не копировать одну типовую страницу для всех серверов: одинаковый контент сам превратился бы в удобную сигнатуру для поиска прокси.

Эталонная схема размещения тоже построена вокруг привычного веб-сервера. Внешнему интернету доступны порты 80 и 443. HTTPS принимает Caddy, который получает обычный сертификат для домена и обрабатывает веб-трафик.

Сам tproxy-server в рекомендованной конфигурации слушает только локальный адрес на порту 8080. Обычный MTProxy работает локально на 2398. Эти порты не должны быть доступны из интернета.

В итоге внешний наблюдатель видит HTTPS-сервер на стандартном 443-м порту, а специализированная часть инфраструктуры спрятана за ним.

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

WebView не создается отдельно для каждого запроса Telegram. Протокол WEB Proxy использует собственные небольшие кадры. OPEN открывает логический поток, DATA переносит данные, WINDOW управляет объёмом данных, который разрешено отправить, CLOSE закрывает поток. Для управления самой сессией предусмотрены HELLO, WELCOME, PING, PONG и BYE. Полный формат опубликован в спецификации WEB Proxy v1.

Несколько TCP-соединений Telegram благодаря этому можно передавать в рамках одной логической WEB-сессии. В режиме с одним WebSocket они мультиплексируются в одно постоянное соединение. При использовании HTTPS сервер может создавать отдельные каналы для потоков.

Разработчики уточняют, что выражение «один WebView-транспорт» не обязательно означает один HTTP-запрос или одно TCP-соединение до сервера. Это одна логическая сессия, внутри которой конкретный профиль выбирает способ доставки.

Использование удаленной страницы внутри WebView создает очевидный вопрос безопасности: получает ли JavaScript секрет прокси? Архитектура первой версии сделана так, чтобы не получать.

Пользователь вводит домен и обычный секрет MTProxy. Telegram самостоятельно вычисляет производное значение bridge через HMAC-SHA256. Веб-страница получает именно его, а не исходный ключ.

Отдельный одноразовый токен создается уже после успешного открытия страницы-моста. Он действует две минуты и используется для запуска одной сессии. Затем WEB Proxy работает с отдельным токеном этой сессии.

Страница также удаляет bridge из видимого адреса через history.replaceState, а проект рекомендует не записывать исходные URL, заголовки авторизации и тела запросов в журналы сервера.

WEB Proxy при этом не делает владельца прокси невидимым или полностью доверенным участником. Сервер по определению принимает соединение пользователя и видит технические метаданные подключения. Telegram и для обычного MTProxy рекомендует использовать узлы, которым пользователь доверяет.

WebSocket сам по себе для Telegram не новый. В официальной документации транспортов MTProto Telegram уже описывает TCP, HTTP, HTTPS, WebSocket и WebSocket поверх TLS. Для браузерных клиентов WebSocket рекомендуется из-за постоянного двустороннего потока данных.

WEB Proxy решает другую задачу: он позволяет обычным MTProxy-соединениям настольного приложения ехать через WebView к стороннему HTTPS-домену, после чего сервер возвращает их в стандартный MTProxy.

У MTProxy уже есть штатные механизмы маскировки, но в 2026 году их устойчивость оказалась ограниченной. В конце мая независимое исследование проверило 27 конфигураций MTProxy в четырёх регионах и шести российских сетях. Рабочими оказались три. Авторы сразу обозначили небольшую выборку и не считали её общероссийской статистикой, однако отдельно отметили проблемы Fake TLS и отсутствие заметного преимущества у нестандартных портов. Результаты эксперимента опубликованы 2 июня.

В официальном трекере Telegram Desktop тоже появлялись жалобы на подключение через MTProto-прокси в сетях с фильтрацией. Например, обращение от 27 мая описывало ситуацию, когда один прокси работал на мобильных клиентах, но соединение Telegram Desktop не проходило. Такие отчёты нельзя считать самостоятельным исследованием, однако они показывают, с какими сценариями сталкивались пользователи.

Сам Telegram описывает MTProxy как технологию, которая скрывает прямое обращение к известным адресам Telegram и затрудняет распознавание пользовательского трафика провайдером.

WEB Proxy добавляет к этой схеме еще один уровень: внешним транспортом теперь может заниматься обычный браузерный компонент.

Первая версия максимально сокращает число настроек. Пользователь вводит только имя домена и секрет MTProxy. Схема https:// и порт 443 фиксированы самим типом WEB Proxy. IP-адрес вместо домена, произвольный порт, путь или параметры URL спецификация не предусматривает.

Разработчики уже определили формат ссылки:

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

и аналогичный вариант tg://webproxy.

Есть нюанс: публичная веб-версия t.me пока не зарегистрировала маршрут /webproxy. Репозиторий предупреждает, что при тестировании ссылку может потребоваться открывать непосредственно в совместимом клиенте Telegram.

То есть интерфейс WEB Proxy уже попал в стабильный Telegram Desktop, но распространение серверов и удобных ссылок подключения еще только формируется.

Десктопная версия сейчас ушла дальше остальных платформ. В документации проекта Android-вариант все еще называется proof of concept. Он использует закрытый Android System WebView и локальный адаптер, которому tgnet передаёт уже преобразованные MTProxy-данные. Реализация требует нескольких возможностей AndroidX WebKit и при их отсутствии не должна незаметно переключаться на прямое соединение с Telegram.

Для iOS описана аналогичная архитектура через WKWebView и Network.framework. Основной README проекта по-прежнему относит её к планируемой экспериментальной реализации. Публичный стабильный релиз WEB Proxy для мобильных клиентов на момент публикации не объявлен.

Поэтому переносить факт появления функции в Telegram Desktop автоматически на Android и iPhone пока нельзя.

WEB Proxy усложняет некоторые способы распознавания транспорта, но не устраняет базовые свойства сетевого соединения. У сервера остаются домен и IP-адрес. Их можно ограничить напрямую. При анализе трафика можно изучать объем данных, длительность соединений и статистическое поведение потоков. Сам браузерный TLS-сеанс также не гарантирует, что передаваемый внутри него шаблон данных никогда нельзя классифицировать.

Вопросы и ответы

Telegram уже выпустил WEB Proxy?

Да, новый тип WEB появился в настройках стабильного Telegram Desktop 7.1.0 от 22 августа 2026 года. Серверная часть проекта при этом пока имеет статус proof-of-concept.

WEB Proxy заменяет MTProxy?

Нет. Telegram сначала применяет стандартное преобразование MTProxy, а WEB Proxy переносит получившийся поток через WebView и веб-транспорт к серверу.

Он работает через WebSocket?

Может, но WebSocket необязателен. Спецификация предусматривает обычный HTTPS, отдельные HTTPS-каналы, один общий WebSocket или WebSocket для каждого логического потока.

Зачем нужен WebView?

WebView позволяет использовать настоящий браузерный HTTPS-стек вместо ручной имитации веб-соединения. Публичный TLS и HTTP при этом обрабатываются стандартными веб-компонентами.

Провайдер увидит обычный сайт?

Домен действительно способен работать как настоящий HTTPS-сайт. Без корректного производного секрета сервер возвращает обычную главную страницу. Это затрудняет простую активную проверку, но не гарантирует невозможность распознавания прокси другими методами.

Может ли владелец WEB Proxy прочитать сообщения Telegram?

Tproxy-server получает уже преобразованный MTProxy-поток и рассматривает его данные как непрозрачные байты. Telegram-сообщения не расшифровываются этим промежуточным слоем.

Какие данные нужны для подключения?

Домен WEB-прокси и секрет MTProxy. HTTPS и порт 443 выбираются автоматически.

WEB Proxy уже работает на Android и iPhone?

Стабильный публичный выпуск для мобильных приложений пока не подтверждён. Для Android описана экспериментальная реализация, для iOS — отдельная реализация и план интеграции через WKWebView.

Можно ли заблокировать WEB Proxy?

Да. Домен или IP-адрес сервера остаются доступными для адресной фильтрации. Новый механизм прежде всего меняет внешний вид транспортного соединения и усложняет часть способов определения MTProxy.