🌐 WEB-прокси Telegram: трафик, который едет внутри обычного сайта

О чём заметка

В августе 2026 года в Telegram появился четвёртый тип прокси — WEB-прокси (tproxy, веб-прокси Телеграм). Он отличается от всего, что было раньше: приложение перестаёт выходить в сеть само и просит сделать это встроенный в него браузер, обращаясь к самому обычному сайту. Здесь — что это такое простыми словами, зачем понадобилось, чем отличается от привычного MTProxy и можно ли этим пользоваться по состоянию на 22 августа 2026 года. Технические подробности вынесены в отдельные заметки раздела, ссылки на них в конце.

Проект экспериментальный, и это важно понимать до чтения

Разбор сделан по исходному коду серверной части tproxy-server и клиента Telegram Desktop по состоянию на 22 августа 2026 года. Автор сам называет проект доказательством работоспособности (proof-of-concept) — то есть демонстрацией, что идея в принципе работает, а не готовым продуктом. Официальной документации Telegram по этому протоколу нет, гарантий совместимости между версиями никто не давал. Всё описанное ниже может измениться.

TL;DR

1. WEB-прокси — это способ доставки, а не новое шифрование. Внутри всё тот же MTProxy, который Telegram использует много лет. Меняется только то, как байты попадают на сервер.
2. Приложение больше не открывает сетевые соединения само. Оно просит встроенный браузерный движок (тот же, на котором работают мини-приложения Telegram) сходить на обычный сайт по вашему домену — и трафик едет внутри этих веб-запросов.
3. На сервере стоит настоящий сайт. Кто угодно может открыть ваш домен в браузере и увидеть нормальные страницы. По содержанию ответов сервера понять, что здесь же живёт прокси, нельзя.
4. Пользователю нужны два значения — имя домена и обычный 32-символьный секрет MTProxy. Никаких файлов конфигурации и ключей.
5. Работает пока только в собранном вручную клиенте. Код Telegram Desktop написан 9 августа 2026 года и опубликован 18 августа, но лежит в ветке разработки: в выпущенных версиях (последняя — 7.0.9 от 6 августа) его ещё нет. Android — экспериментальный прототип, iOS — только планы.
6. Звонки через него не пойдут — голос и видео ходят по другому сетевому протоколу, который внутрь веб-запросов не укладывается.

Что такое прокси для Telegram и почему их несколько типов

Чтобы понять новизну, нужно сначала вспомнить, что уже было. Telegram умеет работать через посредника — сервер, который принимает трафик от приложения и передаёт его дальше в сторону настоящих серверов мессенджера. Это и есть прокси. До августа 2026 года приложение знало три типа таких посредников: SOCKS5 и HTTP — общие стандарты, придуманные вообще не для Telegram, — и MTProxy, собственную разработку мессенджера.

MTProxy отличается от первых двух тем, что понимает внутренний протокол Telegram, который называется MTProto, и умеет прятать его от посторонних глаз. У MTProxy есть режим маскировки FakeTLS (ФейкТЛС, транспорт ee): соединение притворяется обычным защищённым визитом на какой-нибудь популярный сайт. Подробнее об устройстве самого MTProxy — в заметке MTProxy и mtproto.zig: что это и как пережить ТСПУ.

Проблема в том, что притворство здесь остаётся притворством. Соединение с MTProxy — это всё равно отдельное подключение, которое приложение открывает своими руками, своим сетевым кодом. А в России такие подключения разбирает ТСПУ (технические средства противодействия угрозам) — оборудование фильтрации, установленное прямо у операторов связи. Оно учится распознавать подключения по мелким деталям: по тому, как именно клиент начинает разговор, какие параметры шифрования предлагает, как выглядит первый пакет. Об этой стороне борьбы есть отдельная заметка SNI и почему обход — клиентский.

WEB-прокси решает задачу иначе. Вместо того чтобы всё лучше маскировать собственные соединения, приложение перестаёт их открывать вообще.

Почему WEB-прокси появился именно в 2026 году

1 апреля 2026 года в России началась волна отказов MTProxy: в журналах прокси массово появились ошибки «Telegram handshake timeout» и «obfuscated handshake is failed» — они зафиксированы в баг-трекерах серверных реализаций. По сообщениям пользователей, отказ зависел от оператора и способа подключения: у одних не работало вовсе, у других на том же операторе работало. В тот же день выросло число жалоб на Telegram на сервисах мониторинга сбоев: по подсчётам в разборе на Habr от 2 апреля — около четырёх тысяч обращений на Downdetector и более трёх тысяч на «Сбой.РФ». Эти числа приводятся по одному источнику и относятся к мессенджеру в целом, а не к прокси отдельно.

В конце мая 2026 года прошла вторая, более жёсткая волна. Издание te-st.org провело полевой тест с 27 по 31 мая в четырёх регионах и шести сетях: из 27 проверенных конфигураций рабочими оказались три, причём все — в сетях региональных провайдеров, а у двух федеральных операторов ни один из восьми проверенных прокси соединения не установил. Перенос на нестандартные порты не помогал — их блокировали наравне с обычным. Авторы теста специально оговариваются, что выборка невелика и это «срез, а не замер по стране».

Самая технически достоверная версия причины апрельской волны при этом не про всемогущий искусственный интеллект, а про обыкновенную небрежность реализации. Маскировка под защищённое соединение в коде Telegram использовала устаревший идентификатор одного из расширений протокола вместо действующего и объявляла криптографический ключ длиной 32 байта, генерируя при этом 20. Такое приветственное сообщение не мог бы отправить ни один настоящий браузер, и ловила его простейшая проверка по образцу. То есть распознавать научились не саму идею маскировки, а конкретную ошибку в конкретном коде.

Проще говоря: Telegram притворялся браузером, но в двух местах представился неправильно — назвал устаревший номер одной из служебных пометок и сам себе соврал про длину ключа. Достаточно было сверить эти два места с тем, как их заполняет настоящий браузер, и притворство становилось видно без всякого анализа поведения.

Ошибку закрыли быстро: в Telegram Desktop — 3 апреля, в мобильных клиентах — 7–8 апреля. Но майская волна пришла уже поверх исправленных клиентов, и te-st.org связывает её с переходом систем фильтрации к статистическому анализу трафика — а это как раз то, что подделкой отдельных байтов не лечится. Официальный репозиторий MTProxy при этом почти всё это время стоял без движения: между ноябрём 2025-го и началом августа 2026-го в него не внесли ни одной правки — как раз в те месяцы, когда блокировки и работали.

Отсюда и мысль вообще не эмулировать браузер, а использовать настоящий. У WEB-прокси отпечаток соединения не подделывается вручную: его формирует реальный браузерный движок, который обновляется вместе с системой. Догонять свежие версии браузеров в основном не приходится — правда, ровно настолько, насколько свеж сам движок: на старых системах встроенный браузер тоже отстаёт.

Отдельно стоит понимать, что именно на практике блокирует такие инструменты. Надёжно задокументированы измерительными проектами вещи прозаичные: белые списки доменов (с сентября 2025 года действует «реестр социально значимых сервисов»), блокировка по имени домена в запросе, блокировка по адресу и по его репутации. Про более тонкие механизмы известно почти исключительно из разборов сообщества: фильтр сам стучится на подозрительный сервер и смотрит, как тот отвечает; считает, сколько байт уже перекачано, и режет соединение при превышении порога; или просто «замораживает» соединение после первых полутора-двух десятков килобайт, не разбираясь в протоколе. Автор самого подробного такого разбора сам называет свою схему реконструкцией по единственному источнику, так что принимать эти пороги за установленные константы не стоит.

А вот распространённое «блокировки теперь делает искусственный интеллект» пока не подтверждается. Движение в эту сторону реальное и не отдалённое: в январе 2026 года Роскомнадзор законтрактовал механизм фильтрации трафика на машинном обучении с внедрением в том же году, а целевой показатель «эффективности» блокировок средств обхода в 92% поставлен на конец 2030 года (разбор этой дорожной карты — в заметке Планы РКН по блокировке VPN до 2030 года). Но публичных свидетельств того, что прокси в апреле и мае ловили именно поведенческие модели, нет: есть разбор конкретной ошибки в байтах приветственного сообщения и наблюдения о переходе к статистическому анализу размеров и объёмов.

Главная идея: пусть в сеть ходит браузер

Внутри Telegram Desktop, как и внутри мобильных приложений, есть встроенный браузерный движок. Он называется WebView — это полноценный браузер без собственного окна, встроенный в чужую программу. На Windows это WebView2 на движке Chromium, на Android — Android System WebView, на устройствах Apple — WKWebView. Именно он открывает мини-приложения внутри Telegram, страницы оплаты и встроенные веб-вставки. Для прокси при этом заводится отдельный, изолированный экземпляр движка со своим хранилищем — с мини-приложениями он ничего не делит.

Идея WEB-прокси в том, чтобы отдать этому браузеру всю сетевую работу. Выглядит это так: приложение открывает в скрытом WebView страницу вашего сайта, и дальше внутри этой страницы работает небольшой скрипт, который обменивается с сервером обычными веб-запросами. В этих запросах и едет трафик Telegram.

Проще говоря: раньше Telegram сам звонил на прокси-сервер, и этот звонок можно было опознать. Теперь Telegram просит браузер открыть обычный сайт, а всё нужное передаёт внутри посещения этого сайта. Наблюдателю в сети видно ровно одно — кто-то зашёл на сайт и активно им пользуется.

На схеме видно, что цепочка получается длиннее привычной. Приложение отдаёт свои соединения встроенному браузеру, тот обычными веб-запросами доносит их до вашего домена, программа-посредник на сервере раскладывает всё обратно по отдельным соединениям и передаёт обычному MTProxy, который стоит тут же и работает без изменений.

Выигрыш здесь не только в маскировке. Браузерный движок умеет всё то, чему годами учили браузеры: правильно проходить через корпоративные прокси, работать с нестандартными сертификатами, использовать современные версии протокола HTTP. В сетях, где наружу выпускают только веб-трафик, самодельное соединение мессенджера не пройдёт, а браузерный запрос пройдёт.

Что при этом происходит с шифрованием

Новый транспорт — то есть способ доставки байт до сервера — не добавляет и не убавляет шифрования переписки. Приложение сначала обрабатывает данные ровно так же, как для обычного MTProxy, и только потом отдаёт получившиеся байты браузеру. На сервере эти байты передаются настоящему MTProxy, который стоит рядом и работает без единого изменения.

Программа-посредник, которая всё это перекладывает, называется реле (relay, релей). Ключевое её свойство: она не может прочитать то, что перевозит. Для неё данные — просто непрозрачный набор байт. Более того, адрес получателя жёстко записан в настройках реле и указывает на локальный MTProxy, а клиент выбрать его не может. То есть даже злонамеренный клиент не заставит сервер сходить куда-то ещё, и открытым прокси для чужого трафика он не станет. Речь именно про клиента: тот, кто получил на сервере права администратора, конфигурацию, разумеется, перепишет.

Отдельно защищён и сам секрет. Пользователь вводит его в приложении, но в браузер этот секрет не передаётся: из него вычисляется производное значение — постоянный пропуск, привязанный к конкретной паре «домен плюс секрет». По этому пропуску сервер выдаёт уже одноразовое: страницу-мост и короткоживущий токен на одну сессию. Как именно это устроено — разобрано в заметке Как устроен WEB-прокси изнутри.

Со стороны пользователя: два поля и всё

Проще, чем всё, к чему привыкли пользователи VPN. Нужны два поля:

Hostname: proxy.example.com
Secret:   000102030405060708090a0b0c0d0e0f

Имя хоста — просто домен, без https://, без порта и без косой черты в конце: тип прокси WEB жёстко подразумевает защищённое соединение на стандартном порту 443. Секрет — те же 32 шестнадцатеричных символа, что и у обычного MTProxy.

Есть и ссылка для передачи одним сообщением:

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

Правда, на 22 августа 2026 года публичный сайт t.me этот адрес ещё не обслуживает — в документации проекта это сказано прямо. Пока ссылку приходится открывать напрямую в клиенте (в форме tg://webproxy?server=…&secret=…) либо вводить оба поля руками.

В самом приложении это выглядит как четвёртый переключатель в списке типов прокси, рядом с MTPROTO, SOCKS5 и HTTP. При его выборе поля адреса и порта исчезают — остаётся одно поле имени хоста и поле секрета, а порт всегда 443. Три особенности стоит знать заранее: проверка доступности для таких прокси отключена (строка всегда показывает «не проверено»), в автоматической ротации прокси такие записи не участвуют, а секреты с префиксом ee клиент прямо помечает как неподдерживаемые.

Отдельно предусмотрен запасной путь на случай, когда встроенный браузер недоступен. Клиент предлагает открыть страницу прокси в обычном браузере. Для этого Telegram запускает крошечный веб-сервер прямо на вашем компьютере, открывает его страницу по адресу 127.0.0.1 (это адрес «сам себя», наружу он не виден), и дальше эта вкладка работает переносчиком трафика — её придётся держать открытой всё время, пока нужен Telegram. Встроенный вариант при этом продолжает пытаться подключиться в фоне и, как только у него получится, вкладка становится не нужна.

Требования к встроенному браузеру различаются по системам: на Windows используется компонент Edge WebView2 (в Windows 10 и 11 он обычно уже установлен), на macOS — штатный WKWebView, на Linux нужна библиотека WebKitGTK. Если движок недоступен или скрытое окно не поднимается, клиент и предлагает тот самый запасной путь через системный браузер.

Чем это отличается от VPN и от обычного прокси

Первое и главное: это не VPN. Через WEB-прокси идёт только трафик Telegram и ничего больше. Браузер, почта, другие приложения им не пользуются. Если задача — открыть заблокированный сайт, нужен другой инструмент; здесь речь исключительно о том, чтобы работал мессенджер.

Второе: это не универсальный прокси. Настроить его в стороннем клиенте или в системе нельзя — нужна поддержка именно в приложении Telegram, потому что вся хитрость происходит внутри него.

Третье: голос и видео через такой транспорт не идут. Звонки в Telegram идут по протоколу UDP — это способ отправлять пакеты без установленного соединения и без гарантии доставки, зато быстро; для разговора так лучше, но внутрь веб-запросов такое не заворачивается. В списке того, что сознательно не поддерживается в первой версии, звонки названы прямо. Справедливости ради, обычный MTProxy их тоже не переносит: при любом прокси Telegram Desktop ведёт звонки мимо него, напрямую. То же касается веб-версии Telegram — она с этим протоколом не работает.

Сравнение с соседними решениями удобнее в таблице.

Что нужно, чтобы поднять такой прокси

Кратко: отдельный сервер, свой домен и настоящий сайт на нём. Развёрнутая инструкция — в заметке Установка tproxy-server, здесь только суть.

Домен обязателен, и заменить его голым IP-адресом нельзя: пропуск, по которому клиент опознаётся, вычисляется в том числе из имени домена. Сертификат для защищённого соединения выпускается автоматически, для этого нужен работающий доступ снаружи к портам 80 и 443.

А вот требование настоящего сайта — самое непривычное. Это не декоративная заглушка: реле отдаёт страницы этого сайта всем, кто пришёл без правильного пропуска, и делает это тем же самым кодом, что и обычный веб-сервер. В проекте намеренно не поставляется шаблон сайта — потому что если бы все операторы поставили один и тот же образец, его страницы стали бы отличным признаком для поиска таких серверов. Сайт должен быть ваш, с вашими текстами и вашим оформлением.

Насколько хорошо WEB-прокси прячется от анализа

Разработчики продумали неотличимость довольно дотошно, и это видно по коду. Запрос к служебным адресам без правильного пропуска — с чужим паролем, неверным методом или битыми заголовками — получает ровно тот же ответ, что и запрос несуществующей страницы: тот же код, тот же набор заголовков, то же содержимое. А главная страница с неправильным, лишним или повторённым параметром отдаёт обычную главную с кодом 200 — ровно как любой сайт, который просто не знает такого параметра. В проекте есть отдельный тест, который перебирает десятки комбинаций методов и заголовков и требует побайтового совпадения ответов.

Даже проверка пропуска устроена так, чтобы по времени ответа ничего нельзя было понять: сравнение всегда идёт по всем настроенным секретам до конца, без досрочного выхода, а если параметра в запросе вовсе не было, сервер всё равно проделывает ту же работу вхолостую.

Но об одном стоит сказать прямо: анализа устойчивости к более тонким методам обнаружения в проекте нет. Разбор всех способов блокировки — от списков доменов до анализа формы трафика — вынесен в отдельную заметку Можно ли заблокировать WEB-прокси и как именно. В архитектурном документе не разбирается ни распознавание по размерам и таймингам пакетов, ни характерный ритм долгих ожидающих запросов, ни отпечаток самого браузерного движка. Приём данных здесь устроен так: браузер отправляет запрос, а сервер держит его открытым до 25 секунд и, если данных не появилось, отвечает пустотой — и всё повторяется. Такая ровная пауза сама по себе выглядит характерно, и обсуждения этого риска в документации не найдено. Так что «неотличимо от сайта» здесь означает «неотличимо по содержанию ответов», а не «неотличимо при любом анализе».

Отдельная уязвимая точка — сам домен. Одно реле обслуживает ровно одно имя, и если это имя заблокируют целиком, прокси перестанет работать для всех сразу. Ставить перед сервером сеть доставки контента в первой версии прямо запрещено — в том числе потому, что такая сеть записывала бы адреса запросов в свои журналы, а в адресе едет пропуск. Так что домен смотрит в интернет напрямую своим адресом.

Насколько это быстро

Скорость упирается в устройство транспорта. В базовом режиме в каждую сторону одновременно едет один запрос размером до 2 мегабайт, поэтому потолок считается просто: два мегабайта, делённые на время оборота пакета до сервера и обратно. Разработчики приводят такую таблицу:

Это верхняя граница, реальная скорость ниже: своё забирают накладные расходы протокола, лишний участок пути от реле до MTProxy и работа самого браузерного движка. В качестве целевых показателей приёмки названы 20 Мбит/с при задержке 500 мс и 40 Мбит/с при 200 мс. Обратите внимание, что цели названы в мегабитах, а потолок в таблице — в мегабайтах: 20 Мбит/с — это примерно 2,5 МБ/с, то есть около двух третей теоретического потолка на той же задержке. Никаких измеренных результатов в документации нет — только цели.

Чтобы обойти этот потолок, предусмотрены четыре режима доставки, от самого консервативного до варианта с отдельным постоянным соединением на каждый поток данных. Выбираются они на сервере, клиент об этом даже не знает. Разбор всех четырёх — в заметке про устройство протокола.

Можно ли этим пользоваться прямо сейчас

Короткий ответ на 22 августа 2026 года: поднять сервер можно, а вот подключиться к нему обычным пользователям — ещё нет. Дальше — по частям, потому что ответ разный.

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

Клиентская часть — вот здесь стоп. Код Telegram Desktop написан 9 августа 2026 года и опубликован 18 августа, но лежит в ветке разработки. В выпущенных сборках его нет — последний релиз 7.0.9 вышел 6 августа, то есть ещё до появления этого кода. Значит, попробовать можно только собрав приложение из исходников самостоятельно. Для Android есть экспериментальный прототип с отдельной инструкцией по сборке, для устройств Apple — пока только описание будущей реализации.

Есть и юридическая деталь, которую легко пропустить. У репозитория нет файла лицензии. По умолчанию это значит «все права защищены»: формального разрешения использовать, изменять и распространять код никто не давал. Для личного эксперимента на это обычно закрывают глаза, но закладывать такое в платный сервис до появления лицензии — плохая идея.

Практический вывод. Возиться имеет смысл, если хочется разобраться заранее или если есть конкретная сеть, где не проходит вообще ничего, кроме веб-трафика, и есть возможность собрать клиент самостоятельно. Ждать, что этим в ближайшее время начнут пользоваться обычные люди, не стоит: их приложение просто не поймёт такую ссылку.

Заметки раздела

• Как устроен WEB-прокси изнутри: пропуск, кадры и четыре режима доставки — что происходит между приложением и сервером на самом деле, разобрано по шагам.
• Установка tproxy-server: свой WEB-прокси на своём домене — практическая инструкция, включая то, чем опасен автоматический установщик на сервере, где уже что-то работает.
• Можно ли заблокировать WEB-прокси и как именно — что видно наблюдателю в сети, какими способами блокируют на практике и сколько живёт домен.
• Выдача WEB-прокси из Telegram-бота — как раздавать доступ пользователям и почему автоматическая выдача упирается в неожиданное ограничение.

📚 См. также

• MTProxy и Telegram-транспорты — раздел — обычный MTProxy, из которого выросла эта конструкция и который продолжает работать внутри неё.
• WSS для Telegram: MTProto внутри WebSocket — другой способ спрятать тот же трафик, появившийся раньше: MTProto заворачивают в веб-сокет и отправляют на настоящие веб-адреса Telegram.
• SNI и почему обход — клиентский — почему борьба с распознаванием соединений в принципе ведётся на стороне клиента.
• 🔗 telegramdesktop/tproxy-server — исходники серверной части и вся официальная документация проекта.

🤖 Эти статьи открыты — можно обучать на них ИИ

При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: исходник этой заметки · скачать весь репозиторий одним zip-архивом.