В Telegram Desktop 7.1 появился новый тип прокси WEB, использующий WebView и HTTPS/WebSocket-транспорт для передачи соединений Telegram. Технология делает прокси-трафик ближе по внешним признакам к обычному веб-доступу, однако серверная реализация пока имеет статус proof-of-concept, поэтому считать WEB-прокси полностью готовой заменой MTProxy рано.
WEB-прокси появился в Telegram Desktop 7.1
В Telegram Desktop 7.1, выпущенном 21 августа 2026 года, в настройках соединения появился новый тип прокси — WEB. Это не просто ещё один вариант адресации существующего MTProxy: клиент получает дополнительный веб-транспорт, через который MTProxy-соединения можно передавать внутри HTTPS или WebSocket.
На следующий день вышел Telegram Desktop 7.1.1. Это исправляющий релиз: в его списке изменений указаны исправление загрузки чатов у части пользователей и другие небольшие исправления, тогда как сам WEB-прокси был добавлен именно в ветке 7.1.
Новая схема особенно интересна на фоне фильтрации прокси по сетевым признакам. Классический MTProxy умеет использовать FakeTLS для имитации TLS-трафика, однако современные системы DPI могут анализировать не только номер порта, но и характер установления соединения и другие наблюдаемые признаки протокола.
Как устроен новый WEB Proxy
Опубликованный Telegram Desktop проект tproxy-server описывает серверную часть WEB-прокси как proof-of-concept. Telegram сохраняет привычное MTProxy-форматирование и шифрование, но TCP-соединения приложения проходят через транспорт, которым управляет встроенный WebView.
Упрощённо цепочка выглядит так:
Telegram → локальный WEB-адаптер → WebView → HTTPS/WebSocket → tproxy-server → MTProxy → Telegram
Клиенту достаточно двух основных параметров:
- доменного имени WEB-прокси;
- 16-байтового секрета MTProxy.
HTTPS и порт 443 для WEB-прокси фиксированы. В отличие от обычного прокси с открытым специализированным портом, сервер может одновременно выглядеть как обычный HTTPS-сайт.
WebView открывает специальную страницу на настроенном домене и создаёт аутентифицированную сессию с relay-сервером. Несколько логических соединений Telegram могут передаваться через общий веб-транспорт, после чего сервер разделяет потоки и направляет каждый из них в обычный официальный MTProxy.
При этом relay получает непрозрачные данные: согласно описанию проекта, он не расшифровывает MTProxy-поток и не выбирает произвольный адрес назначения.
Почему DPI сложнее распознать такое соединение
Основная идея WEB-прокси — перенести транспорт Telegram внутрь настоящего веб-стека вместо имитации HTTPS на уровне FakeTLS.
Для внешнего наблюдателя пользователь устанавливает HTTPS-соединение с обычным доменом на порту 443. Этот же домен способен обслуживать полноценный сайт: запрос без корректного служебного параметра получает обычную веб-страницу, а транспорт прокси активируется только после подтверждения знания соответствующего секрета.
Это усложняет активное обнаружение сервера. Простого обращения к IP-адресу или домену недостаточно, чтобы сервер автоматически выдал себя как Telegram-прокси.
Proof-of-concept предусматривает несколько вариантов транспорта:
| Режим | Передача данных | Особенность |
https | HTTPS POST и long polling | Наиболее консервативная схема |
https-lanes | Отдельные HTTPS-потоки | Лучше изолирует разные соединения |
websocket | Один WebSocket | Несколько потоков мультиплексируются в одном соединении |
websocket-lanes | Отдельный WebSocket на поток | Меньше взаимного влияния разных потоков |
Сам факт использования настоящего TLS не делает транспорт автоматически нераспознаваемым. Поведенческие характеристики соединений, размеры пакетов, частота запросов и особенности конкретной реализации потенциально могут использоваться для дальнейшей классификации трафика.
WEB Proxy и MTProxy — в чём разница
WEB-прокси не отменяет MTProxy. В текущей архитектуре он фактически добавляет новый внешний транспорт перед обычным MTProxy.
| Характеристика | MTProxy | WEB Proxy |
| Основной транспорт | Прямое TCP-соединение | HTTPS/WebSocket через WebView |
| Маскировка | FakeTLS доступен | Настоящий веб-транспорт |
| Публичный HTTPS-сайт | Не обязателен | Является частью архитектуры |
| Клиентские параметры | Сервер, порт, secret | Hostname и secret |
| Серверная зрелость | Давно используется | Proof-of-concept |
| Основная задача | Проксирование Telegram | Усложнение сетевого обнаружения прокси |
Это позволяет сохранить существующую логику MTProxy внутри инфраструктуры и изменить прежде всего способ доставки зашифрованного потока от приложения к прокси-серверу.
Что потребуется владельцу WEB-прокси
Текущая серверная реализация рассчитана не на запуск одного бинарного файла с открытым портом. Для типового развёртывания нужен отдельный домен, публичный IPv4, HTTPS и обычный веб-сайт.
В reference-схеме используются:
- Linux-сервер;
- доменное имя;
- TCP 80 и 443;
- Caddy как публичный HTTPS-сервер;
tproxy-server;- официальный MTProxy, доступный только локально.
В документации отдельно рекомендуется не выставлять наружу внутренние порты relay и MTProxy. Внешний трафик должен приходить через HTTPS-сайт на порт 443.
Для подключения предусмотрена ссылка вида:
https://t.me/webproxy?server=proxy.example.com&secret=<secret>
Документация proof-of-concept предупреждает, что публичный frontend t.me пока может не регистрировать этот маршрут. Поэтому возможность раздать такую ссылку ещё не означает полноценную поддержку WEB-прокси всеми стабильными клиентами Telegram.
Поддержка Android и iOS пока не равна Desktop
Наиболее готовая клиентская реализация сейчас относится к Telegram Desktop. В репозитории серверного proof-of-concept также описана экспериментальная Android-реализация на Android System WebView и план для iOS с использованием WKWebView.
Это принципиальное ограничение для практического применения. WEB-прокси станет массовым инструментом только после появления совместимой реализации в основных мобильных клиентах и стабилизации серверной части.
Поэтому наличие пункта WEB в Telegram Desktop не стоит трактовать как завершённый глобальный переход Telegram на новый прокси-протокол.
Резюме
WEB Proxy — заметное изменение архитектуры обходного транспорта Telegram: вместо попытки сделать специализированное прокси-соединение похожим на TLS клиент может использовать настоящий браузерный WebView, HTTPS-домен и WebSocket/HTTPS-передачу, сохраняя MTProxy внутри канала.
Для обычных пользователей Telegram Desktop 7.1 новый пункт пока скорее задел на дальнейшее развитие. Готовых публичных WEB-прокси значительно меньше, чем MTProxy, а серверная часть прямо обозначена разработчиками как proof-of-concept.
Для владельцев прокси технология интереснее: сервер получает обычный HTTPS-фасад, работает на стандартном 443-м порту и не обязан раскрывать прокси-функциональность обычному посетителю сайта. Эффективность против конкретных DPI-систем будет зависеть от дальнейшего развития транспорта и его сетевого поведения, поэтому WEB Proxy пока корректнее рассматривать как экспериментальный следующий слой маскировки, а не гарантированно неуязвимый способ подключения.
