todo/tproxy/tproxy.md

---
date: 2026-08-22
tags:
  - tproxy
  - telegram
  - web-прокси
  - mtproxy
  - обход-блокировок
  - обзор-раздела
aliases:
  - WEB прокси Telegram что это
  - Новый тип прокси в Телеграме
  - tproxy-server что это такое
  - Телеграм прокси через сайт
  - t.me/webproxy что это
  - Четвёртый тип прокси Telegram
  - Прокси Телеграм внутри HTTPS
link: https://github.com/telegramdesktop/tproxy-server
---

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

![[tproxy-overview-header.webp|Обложка: WEB-прокси Telegram — новый тип прокси]]

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

> [!warning] Проект экспериментальный, и это важно понимать до чтения
> Разбор сделан по исходному коду серверной части `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 и mtproto.zig: что это и как пережить ТСПУ]].

Проблема в том, что притворство здесь остаётся притворством. Соединение с MTProxy — это всё равно отдельное подключение, которое приложение открывает своими руками, своим сетевым кодом. А в России такие подключения разбирает [[DPI/DPI|ТСПУ]] (технические средства противодействия угрозам) — оборудование фильтрации, установленное прямо у операторов связи. Оно учится распознавать подключения по мелким деталям: по тому, как именно клиент начинает разговор, какие параметры шифрования предлагает, как выглядит первый пакет. Об этой стороне борьбы есть отдельная заметка [[mtproxy/ja4-sni-client-side|Кто может менять JA4/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 года (разбор этой дорожной карты — в заметке [[DPI/rkn-vpn-2030-roadmap|Планы РКН по блокировке VPN до 2030 года]]). Но публичных свидетельств того, что прокси в апреле и мае ловили именно поведенческие модели, нет: есть разбор конкретной ошибки в байтах приветственного сообщения и наблюдения о переходе к статистическому анализу размеров и объёмов.

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

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

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

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

![[tproxy-chain-scheme.png|Схема: Telegram передаёт соединения встроенному браузеру, тот обычными веб-запросами доносит их до реле на вашем домене, а реле — до локального MTProxy]]

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

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

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

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

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

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

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

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

```text
Hostname: proxy.example.com
Secret:   000102030405060708090a0b0c0d0e0f
```

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

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

```text
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 — она с этим протоколом не работает.

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

| Что сравниваем | WEB-прокси | MTProxy с FakeTLS | [[VLESS/VLESS\|VLESS]], Hysteria и подобные |
|---|---|---|---|
| Что заворачивает | только Telegram | только Telegram | выбранный или весь трафик устройства |
| Как выглядит в сети | посещение настоящего сайта | соединение, похожее на визит на сайт | разные варианты, чаще свой протокол под видом защищённого соединения |
| Настройка у пользователя | домен и секрет | адрес, порт и секрет | файл конфигурации или ссылка-подписка |
| Нужен свой домен | да, обязательно | нет: в секрете указывается чужое популярное имя для маскировки | обычно да |
| Переносит звонки | нет | нет | да |
| Отключить одного пользователя | да, если каждому выдан свой секрет, но с правкой файла настроек и перезапуском | да, если каждому выдан свой секрет | да, по одному и без перезапуска |
| Готовность | эксперимент | много лет в работе | много лет в работе |

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

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

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

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

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

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

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

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

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

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

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

| Задержка до сервера | Теоретический потолок |
|---|---|
| 50 мс | около 40 МБ/с |
| 100 мс | около 20 МБ/с |
| 200 мс | около 10 МБ/с |
| 500 мс | около 4 МБ/с |

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

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

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

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

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

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

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

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

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

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

## 📚 См. также

- [[mtproxy/mtproxy|MTProxy и Telegram-транспорты — раздел]] — обычный MTProxy, из которого выросла эта конструкция и который продолжает работать внутри неё.
- [[mtproxy/telegram-wss-transport|WSS для Telegram: MTProto внутри WebSocket]] — другой способ спрятать тот же трафик, появившийся раньше: MTProto заворачивают в веб-сокет и отправляют на настоящие веб-адреса Telegram.
- [[mtproxy/ja4-sni-client-side|Кто может менять JA4/SNI и почему обход — клиентский]] — почему борьба с распознаванием соединений в принципе ведётся на стороне клиента.
- 🔗 [telegramdesktop/tproxy-server](https://github.com/telegramdesktop/tproxy-server) — исходники серверной части и вся официальная документация проекта.

---

> [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ
> При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/tproxy/tproxy.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip).