Web Proxy в Telegram: новый тип прокси, который маскирует трафик под обычный сайт
21 августа 2026 года в коде Telegram Desktop обнаружили нечто новое — экспериментальный транспорт под названием WEB Proxy. Уже 22 августа он появился в десктопной версии 7.1.0 и фиксе 7.1.1 как опция «Add new WEB proxy type to connection settings». Речь идёт не про очередной MTProxy-сервер, а про принципиально другой подход к обходу блокировок: трафик мессенджера прячется внутри обычного HTTPS-соединения так, что провайдер видит просто открытие сайта.
Разберём, что это за технология, чем она отличается от привычного MTProto, как её подключить и какие у неё реальные перспективы.
Проблема, которую решает Web Proxy
Чтобы понять, зачем понадобился новый транспорт, стоит вспомнить, как устроен классический MTProxy. Он передаёт данные в собственном протоколе MTProto — и хотя современные секреты формата ee (FakeTLS) неплохо маскируются под TLS-рукопожатие, системы глубокого анализа трафика (DPI) со временем научились распознавать характерные паттерны такого соединения: длину сессии, интервалы между пакетами, объём передаваемых данных.
Web Proxy заходит с другой стороны. Вместо того чтобы имитировать TLS на уровне отдельных пакетов, он заворачивает весь трафик MTProxy в самое обычное HTTPS или WebSocket-соединение, которое использует настоящий браузерный движок внутри приложения — WebView. С точки зрения провайдера пользователь просто открыл сайт и работает с ним через защищённое соединение. Под капотом в этот момент бодро работает MTProxy, но снаружи это неотличимо от обычного веб-сёрфинга.
Как это устроено технически
Важная деталь: Web Proxy не заменяет MTProxy, а добавляет ему новый транспортный слой. Шифрование самого MTProto-трафика он никак не трогает — просто упаковывает уже зашифрованные данные в веб-обёртку.
Схема работы выглядит так:
- Клиент Telegram знает только хост сервера и MTProxy-секрет
- На основе этих данных локально вычисляется специальный параметр («capability»), который никогда не передаётся напрямую в JavaScript внутри WebView
- Встроенный WebView открывает так называемую мостовую страницу (bridge page) на сервере
- Происходит обмен коротким одноразовым токеном (bootstrap token) на сессию ретранслятора
- Дальше запускается выбранный режим передачи — HTTPS или WebSocket, в зависимости от профиля сервера
- Внутри одного логического соединения мультиплексируются кадры четырёх типов: OPEN, DATA, WINDOW и CLOSE — это позволяет пропускать через один общий канал сразу несколько параллельных подключений приложения
Серверная часть называется tproxy-server. Команда Telegram опубликовала её в открытом доступе на GitHub со статусом proof-of-concept — то есть это пока экспериментальное подтверждение концепции, а не готовое к массовому продакшену решение.
Отдельного внимания заслуживает механизм маскировки. У мостовой страницы есть особенность: она открывается только клиенту Telegram, который прошёл проверку и знает нужный параметр. Любой другой запрос к этому же домену — просто со стороны обычного браузера или инструмента для сканирования сайтов — получает в ответ настоящий, легитимный сайт. То есть прокси-сервер и обычный сайт физически могут жить на одном домене, а отличить одно от другого извне становится заметно сложнее.
Что видит и чего не видит владелец сервера
Здесь у Telegram заложена важная гарантия приватности. Содержимое кадров DATA для сервера tproxy-server остаётся непрозрачным набором байтов — расшифровать сам трафик MTProxy сервер технически не может.
Второй момент касается безопасности самого механизма: клиент не может использовать этот ретранслятор для подключения к произвольному стороннему адресу. То есть оператор Web Proxy не превращается в открытый прокси общего назначения, через который можно было бы гонять произвольный трафик, — канал жёстко привязан именно к передаче MTProxy-данных.
Чем Web Proxy отличается от привычного MTProxy
Чтобы было понятнее, сравним оба подхода по ключевым параметрам.
| Параметр | Классический MTProxy | Web Proxy |
|---|---|---|
| Протокол передачи | Собственный MTProto | HTTPS / WebSocket поверх WebView |
| Формат ссылки | tg://proxy?server=...&port=...&secret=... |
https://t.me/webproxy?server=...&secret=... или tg://webproxy |
| Порт | Обычно 443, но может быть другим | Строго 443 (зафиксировано спецификацией) |
| Маскировка под сайт | Частичная (через FakeTLS-секреты типа ee) | Полная — реальный HTTPS/WebSocket через браузерный движок |
| Мультиплексирование соединений | Нет | Да, несколько подключений через один канал |
| Статус на август 2026 | Стабильная технология, используется массово | Экспериментальная, proof-of-concept |
Главное отличие в философии: MTProto с FakeTLS имитирует рукопожатие, но остаётся узнаваемым по поведению трафика на более глубоком уровне. Web Proxy использует реальный браузерный стек для реального HTTPS-соединения — распознать его сложнее просто потому, что технически это и есть настоящий защищённый веб-трафик, а не его имитация.
Как подключить Web Proxy
Учитывая, что технология экспериментальная, доступна она пока только в десктопной версии Telegram, начиная со сборки 7.1.0 (актуальный фикс — 7.1.1).
Через ссылку. Ссылка для подключения имеет вид:
https://t.me/webproxy?server=proxy.example.com&secret=...
или через внутреннюю схему приложения:
tg://webproxy
При переходе по такой ссылке Telegram Desktop должен сам предложить подключение к прокси — аналогично тому, как это работает с обычными MTProxy-ссылками.
Вручную через настройки. Путь такой: Settings → Advanced → Connection type (или Proxy settings). В списке типов подключения должна появиться новая опция WEB proxy, добавленная как раз в 7.1.1. Дальше вводятся параметры сервера — хост и секрет.
Важный нюанс: поскольку речь о новой и ещё не до конца обкатанной функции, найти публичные рабочие серверы с поддержкой именно этого типа подключения на данный момент сложно — большинство существующих прокси-листов и ботов пока раздают ссылки для классического MTProxy. Технология находится на стадии, когда её тестируют разработчики и энтузиасты, поднимающие tproxy-server самостоятельно на основе опубликованного на GitHub кода.
Останется ли Web Proxy устойчивым к блокировкам надолго
Здесь стоит сохранять трезвый взгляд. История противостояния Telegram и систем блокировки — это постоянная гонка: каждое новое решение мессенджера через какое-то время встречает ответ со стороны DPI-систем.
У Web Proxy есть сильная сторона — он не имитирует HTTPS, а фактически им является, поэтому сигнатурный анализ здесь малоэффективен. Но остаётся открытым вопрос устойчивости к более тонкому анализу: изучению временных характеристик пакетов и объёма сессии. Мультиплексированный поток с несколькими логическими соединениями внутри одного канала всё равно создаёт статистический паттерн, который в теории можно попытаться выявить, даже не расшифровывая содержимое.
Аналогия с историей 2018 года напрашивается сама собой: тогда Роскомнадзор пытался заблокировать Telegram, ограничивая доступ к миллионам IP-адресов, включая инфраструктуру Amazon и Google, но мессенджер продолжал работать за счёт постоянной смены обходных путей. Web Proxy — это следующий виток той же логики, только на уровне транспортного протокола, а не смены IP-адресов.
Что это значит для обычного пользователя
На практике для рядового человека в России Web Proxy пока не готовое к ежедневному использованию решение — скорее сигнал того, куда движется технология. Несколько практических выводов:
- Функция доступна только в Telegram Desktop, мобильные клиенты пока её не получили
- Публичных серверов с поддержкой Web Proxy почти нет, найти рабочий вариант сложнее, чем классический MTProxy
- Статус proof-of-concept означает, что стабильность и сроки появления в основной, немодифицированной версии для всех пользователей пока не определены
- Классический MTProxy и VPN-решения на данный момент остаются более практичным выбором для повседневного обхода ограничений
Тем не менее, за развитием технологии стоит следить: если Web Proxy пройдёт стадию тестирования и получит официальную поддержку в мобильных версиях, это может стать заметным шагом вперёд в устойчивости Telegram к блокировкам — просто потому, что отличить настоящий HTTPS-трафик к сайту от точно такого же настоящего HTTPS-трафика к прокси-серверу принципиально сложнее, чем ловить особенности проприетарного протокола.