В коде Telegram Desktop появилась довольно необычная конструкция. Клиент сможет передавать трафик MTProxy не напрямую к прокси, а внутри обычного HTTPS-соединения, которое создаёт встроенный браузерный движок WebView. Поверх HTTPS открывается WebSocket, внутри WebSocket работает отдельный транспорт, а уже внутри транспорта едут зашифрованные данные Telegram.
На первый взгляд получается матрёшка из протоколов. На практике идея вполне рациональная. Telegram пытается отделить внешний вид сетевого соединения от внутренней транспортной схемы. Снаружи сервер выглядит как HTTPS-сайт, внутри работает канал до специального ретранслятора, а уже ретранслятор передаёт данные обычному MTProxy. По находкам в исходном коде рассказали исследователи изменений Telegram, в частности канал teleLakel. Публичной документации Telegram по WEB Proxy пока нет, поэтому часть деталей приходится восстанавливать по реализации клиента.
Дисклеймер. Разбор предназначен для изучения сетевых технологий и легальной настройки собственной инфраструктуры. При работе с прокси нужно учитывать законодательство своей страны, включая требования законодательства России, правила операторов и сервисов. Инструкции нельзя применять для несанкционированного доступа, слежки, взлома чужих систем или других незаконных действий.
Что именно меняется по сравнению с обычным MTProxy
Сначала разберём существующую схему. MTProxy создавался специально для Telegram. Пользователь указывает сервер, порт и секрет, после чего Telegram Desktop устанавливает соединение с прокси. MTProxy принимает зашифрованный поток Telegram и передаёт данные дальше инфраструктуре мессенджера.
Telegram Desktop
|
| MTProxy transport
|
v
MTProxy
|
v
Telegram
Прокси не получает открытый текст обычных сообщений. Шифрование MTProto сохраняется независимо от промежуточного узла. Но у прямой схемы есть другой недостаток. Сетевое соединение должно дойти до конкретного сервера MTProxy, а характер обмена можно анализировать по адресу, TLS-параметрам, последовательности пакетов, размерам данных и другим признакам.
Telegram уже много лет меняет транспорт MTProxy. Например, официальный прокси поддерживает случайное дополнение пакетов, а клиенты умеют работать с вариантами транспорта, которые делают соединение менее характерным. В конце 2025 года разработчик Telegram Desktop прямо объяснял в GitHub, что старый алгоритм MTProxy заменили более современным из-за простоты сетевого обнаружения.
WEB Proxy идёт дальше. Между Telegram Desktop и MTProxy появляется дополнительный уровень.
Telegram Desktop
|
v
WebView
|
| HTTPS
| WebSocket
v
WEB Proxy / relay
|
| несколько восстановленных потоков
v
MTProxy
|
v
Telegram
Сам Telegram при такой схеме продолжает работать через MTProxy. WEB Proxy не заменяет MTProxy новым протоколом. Новый компонент скорее становится веб-транспортом для доставки MTProxy-трафика.
Такое различие принципиально. В публикациях новую функцию иногда описывают как «новый прокси Telegram», из-за чего можно подумать, будто разработчики придумали замену SOCKS5 или MTProxy. Судя по коду, архитектура другая. Telegram добавляет ещё один слой перед MTProxy.
Зачем здесь WebView и WebSocket
Самая интересная часть конструкции связана с WebView. Telegram Desktop давно содержит встроенный браузерный компонент. WebView нужен для мини-приложений, Instant View и других функций, которым требуется веб-среда. Теперь разработчики используют ту же возможность для сетевого транспорта.
Клиент обращается к HTTPS-домену WEB Proxy через WebView. После начальной проверки страница создаёт WebSocket-соединение. WebSocket удобен по простой причине. После установки соединения обе стороны могут непрерывно отправлять бинарные данные через один двунаправленный канал.
Telegram давно поддерживает WebSocket в собственной транспортной архитектуре. В официальной документации MTProto прямо описан WebSocket over HTTPS. Для Telegram WEB Proxy разработчики строят дополнительный транспорт поверх той же хорошо известной веб-механики.
Дальше появляется мультиплексирование. Telegram Desktop обычно держит несколько логических соединений. Открывать отдельный WebSocket для каждого не обязательно. WEB Proxy объединяет несколько потоков в один канал.
WebSocket | +-- connection 1 | +-- connection 2 | +-- connection 3 | +-- connection 4
Чтобы ретранслятор понял, к какому виртуальному соединению относится очередной кусок данных, разработчики ввели небольшой протокол кадров. В найденной реализации фигурируют четыре основных типа.
| Кадр | Назначение |
|---|---|
OPEN |
создать новое логическое соединение внутри общего канала |
DATA |
передать данные конкретного соединения |
WINDOW |
управлять объёмом данных, которые можно отправлять без переполнения буферов |
CLOSE |
закрыть логическое соединение |
По сути Telegram реализует внутри WebSocket маленький диспетчер потоков. Один WebSocket становится виртуальным кабелем, внутри которого одновременно работают несколько независимых соединений.
WINDOW особенно показателен. Если один участник отправляет данные быстрее, чем другая сторона успевает обрабатывать, буфер начнёт расти. Механизм окна позволяет временно ограничивать отправителя. Аналогичная идея используется в TCP, HTTP/2 и многих других транспортных протоколах.
Получается примерно такой обмен.
OPEN stream=1 OPEN stream=2 DATA stream=1 [...] DATA stream=2 [...] DATA stream=1 [...] WINDOW stream=1 [...] CLOSE stream=2
Формат значительно сложнее простого «Telegram отправляет MTProxy через WebSocket». Клиенту и серверному relay приходится поддерживать состояние всех виртуальных соединений, следить за окнами передачи, корректно закрывать потоки и переживать разрыв общего WebSocket.
Что делает relay и почему WEB Proxy не равен обычному веб-прокси
На серверной стороне WebSocket принимает специальный relay. Русское «ретранслятор» здесь точнее слова «прокси», поскольку компонент выполняет довольно ограниченную задачу.
Relay получает общий поток, читает служебные кадры WEB Proxy, создаёт соответствующие соединения и передаёт содержимое дальше MTProxy. При обратном движении данных relay выполняет тот же процесс в противоположную сторону.
+--> MTProxy connection 1
|
WebSocket --> relay --> MTProxy connection 2
|
+--> MTProxy connection 3
Есть интересное ограничение. Судя по найденной реализации, клиент не передаёт relay произвольный адрес назначения как в классическом SOCKS5. Поэтому превращать такой сервер в универсальный прокси для браузера не предполагается.
Relay также не должен расшифровывать внутренний MTProxy-трафик. Для ретранслятора содержимое остаётся потоком байтов. Служебный слой понимает, к какому виртуальному каналу принадлежат байты, но не обязан понимать MTProto внутри.
WEB Proxy поэтому не даёт дополнительного сквозного шифрования сообщений. За криптографическую защиту Telegram по-прежнему отвечают протоколы самого Telegram. HTTPS защищает внешний участок между WebView и WEB Proxy и одновременно формирует привычную для веба структуру соединения.
Не стоит делать и обратный вывод, будто владелец WEB Proxy «ничего не видит». Сервер в любом случае получает сетевые метаданные. В частности, оператор сервера знает IP-адрес подключившегося клиента, время подключения и объём переданного трафика. Поэтому рекомендация пользоваться прокси из доверенного источника никуда не исчезает.
Обычный сайт и специальная мостовая страница
Самая необычная часть проекта находится не внутри MTProto, а на веб-сервере.
WEB Proxy можно разместить на HTTPS-домене, который одновременно обслуживает обычный сайт. Если посетитель откроет домен браузером, сервер способен показать нормальную веб-страницу. Специальная «мостовая» страница WEB Proxy должна отдаваться только после проверки параметров, связанных с настройкой прокси.
Получается двухрежимный сервер.
Обычный запрос
|
v
https://example.com/
|
+--> обычный сайт
Запрос Telegram
|
v
https://example.com/[специальный запрос]
|
+--> bridge
|
v
WebSocket
|
v
relay
Подобная схема полезна не только из-за HTTPS. Голый специализированный прокси легко выдаёт себя уже тем, что на сервере больше ничего нет. WEB Proxy позволяет обслуживать стандартный веб-контент и прокси-транспорт на одном HTTPS-узле.
Но популярное описание «трафик становится неотличим от обычного сайта» слишком категорично. HTTPS шифрует содержимое соединения, однако сетевой наблюдатель всё равно видит домен или IP в зависимости от конкретной TLS-схемы, длительность сессии, объём и направление передачи данных, интервалы между пакетами и другие метаданные. Продвинутые системы анализа могут классифицировать даже зашифрованный трафик по поведению.
Правильнее говорить, что WEB Proxy переносит Telegram в гораздо более распространённый транспортный контекст. Насколько хорошо такая схема выдерживает конкретные методы анализа сети, покажут только реальные развёртывания.
Чем WEB Proxy отличается от SOCKS5, HTTP Proxy и MTProxy
| Технология | Что передаёт | Специализация под Telegram | Основной внешний транспорт |
|---|---|---|---|
| SOCKS5 | произвольные TCP-соединения | нет | TCP |
| HTTP Proxy | HTTP или туннель через CONNECT | нет | HTTP/HTTPS |
| MTProxy | трафик Telegram | да | специализированный транспорт MTProxy |
| WEB Proxy | потоки для MTProxy | да | HTTPS + WebSocket через WebView |
Особенно легко перепутать WEB Proxy с HTTP Proxy. Разница большая. Обычный HTTP-прокси получает запрос от клиента и работает как универсальный посредник. WEB Proxy использует веб-протоколы как транспортную оболочку для специализированного канала Telegram.
Не стоит путать новую схему и с Telegram Web. WEB Proxy относится к настольному клиенту Telegram Desktop. WebView здесь выступает внутренним сетевым компонентом, а не заменяет программу браузерной версией Telegram.
Что уже известно, а чего пока нет
На момент появления первых разборов код WEB Proxy уже присутствовал в ветке разработки Telegram Desktop. В истории изменений также появлялись исправления, прямо относящиеся к «restricted WEB proxy», включая отдельную правку для Windows. Значит, речь идёт не о концепте из обсуждения GitHub, а о реальной разработке внутри клиента.
Но отсюда нельзя делать вывод, что любой пользователь Telegram Desktop уже может открыть настройки и включить WEB Proxy. В официальном журнале стабильного Telegram Desktop 7.1.1 функция отдельно не объявлена, пользовательского релиза и инструкции по развёртыванию серверной части Telegram также пока не представил.
Поэтому я бы разделил факты на три уровня.
- Подтверждено кодом. В Telegram Desktop разрабатывается WEB Proxy, использующий WebView, HTTPS/WebSocket, мультиплексированный транспорт и relay.
- Следует из архитектуры. Relay служит промежуточным транспортным узлом перед MTProxy, а один WebSocket способен нести несколько логических соединений.
- Пока неизвестно. Когда функция станет публичной, какие клиенты её получат, как Telegram оформит конфигурацию серверов и насколько хорошо технология покажет себя в реальных сетях.
Есть и технические риски. WebView добавляет зависимость от браузерного движка и поведения платформы. Общий WebSocket превращается в единую точку отказа для нескольких внутренних потоков. При обрыве внешнего канала клиенту придётся восстанавливать сразу несколько логических соединений. Мультиплексирование требует контроля очередей, чтобы крупная передача не мешала коротким запросам. Наконец, серверная инфраструктура становится сложнее обычного MTProxy.
WEB Proxy интересен именно архитектурой. Telegram не выбрасывает MTProxy и не изобретает очередной универсальный прокси. Разработчики помещают существующий транспорт внутрь веб-канала, который создаётся через WebView, защищается HTTPS и передаёт несколько соединений через один WebSocket.
Если функция выйдет в публичный доступ в нынешнем виде, схема подключения Telegram Desktop станет примерно такой: WebView устанавливает HTTPS/WebSocket-соединение с веб-доменом, клиент упаковывает несколько потоков в кадры OPEN, DATA, WINDOW и CLOSE, relay разбирает общий поток и передаёт данные MTProxy, а MTProxy уже связывается с Telegram.
Главная мысль здесь проще всей протокольной матрёшки. Telegram превращает специализированное соединение с прокси в веб-сессию и при этом старается не менять внутреннюю модель MTProxy. Идея технически сильная, но пока рано объявлять WEB Proxy готовым решением. Код есть, архитектура просматривается довольно хорошо, публичного запуска и полноценной серверной документации пока нет.
