---
date: 2026-08-22
tags:
  - tproxy
  - telegram
  - блокировки
  - dpi
  - обход-блокировок
  - техническое
aliases:
  - Можно ли заблокировать WEB-прокси Telegram
  - Как блокируют tproxy
  - Забанят ли WEB-прокси
  - Сколько живёт домен WEB-прокси
  - WEB-прокси и ТСПУ
  - Как палится WEB-прокси Telegram
link: https://github.com/telegramdesktop/tproxy-server
---

# 🛡 Можно ли заблокировать WEB-прокси Telegram и как именно

![[tproxy-blocking-header.png|Обложка: что видно наблюдателю — имя домена, адрес, сертификат, форма трафика, и только ответы сервера неотличимы]]

> [!info] О чём заметка
> WEB-прокси — новый тип прокси в Telegram, где трафик мессенджера едет внутри обычных веб-запросов к вашему сайту; общее устройство разобрано в заметке [[tproxy/tproxy|WEB-прокси Telegram: трафик внутри обычного сайта]]. Здесь отдельный вопрос: можно ли такой прокси заблокировать, какими способами это делается на практике, что именно выдаёт сервер и сколько живёт домен. Разбор по частям — от самых дешёвых для цензора приёмов к самым дорогим.

> [!warning] Что здесь доказано, а что нет
> Устройство самого проекта проверено по исходному коду `tproxy-server` на 22 августа 2026 года. Утверждения о том, как работают реальные системы фильтрации, опираются на измерительные исследования и на сообщения сообщества — их надёжность разная, и в тексте она отмечена прямо. Никаких измерений именно WEB-прокси в живых сетях на момент написания не существует: технология слишком новая, работающих клиентов у пользователей нет, а значит, нет и статистики.

## TL;DR

1. **Конкретный сервер заблокировать легко и дёшево** — по имени домена в запросе или по адресу. Никакой маскировки от этого нет ни у WEB-прокси, ни у большинства соседних решений.
2. **Домен здесь — единая точка отказа.** Одно реле обслуживает ровно одно имя; заблокировали имя — отвалились все пользователи разом.
3. **Активные проверочные запросы бесполезны.** Сервер отвечает на них ровно так же, как обычный сайт, и это закреплено отдельными тестами в проекте — здесь он заметно сильнее типовых схем.
4. **Остаются признаки формы трафика:** многочасовые соединения, ровный ритм долгих ожидающих запросов раз в 25 секунд и почти симметричный обмен вместо привычной для сёрфинга картины «маленький запрос, большой ответ».
5. **Заблокировать технологию как класс пока нечем.** Все подтверждённые случаи блокировок туннелей — это списки доменов, адреса, пороги по объёму и проверочные запросы, а не распознавание поведения.
6. **Главный практический риск — не анализ трафика, а публикация ссылки.** Прокси для Telegram годами блокируют, собирая ссылки из открытых каналов; WEB-прокси в этом смысле ничем не защищён.

## Три разных вопроса под одним словом «заблокировать»

Прежде чем разбирать способы, стоит развести три вещи, которые постоянно смешивают.

**Заблокировать конкретный сервер.** Сделать так, чтобы вот этот домен и вот этот адрес перестали работать у абонентов сети. Это самая простая задача, и она решается без всякого анализа содержимого.

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

**Наказать пользователя или оператора.** Здесь речь уже не о технике, а о правилах: заблокирует ли Telegram аккаунт, будут ли последствия у владельца сервера. Об этом — в конце заметки.

Дальше — по порядку, от самого дешёвого приёма к самому дорогому.

## Что вообще видно наблюдателю

Начнём с того, что вообще доступно тому, кто смотрит на трафик между пользователем и вашим сервером.

**Имя домена.** Запрос к системе доменных имён виден целиком, а при установке защищённого соединения имя сервера передаётся открытым текстом в первом же пакете — это поле называется SNI, указание имени сервера. Технология, которая его прячет (шифрование этого поля, ECH), в России блокируется с ноября 2024 года: соединение с таким полем просто перестаёт пропускаться, так что спрятаться за ней не выйдет.

**Адрес сервера.** Виден всегда и по определению. Вместе с ним видна и его «репутация»: принадлежность известному хостингу, соседство с другими подозрительными адресами, история.

**Сертификат.** Публичные центры сертификации записывают каждую выдачу в открытые журналы прозрачности. Это значит, что сам факт «на таком-то поддомене выпущен сертификат» становится публично известен в течение секунд. Стандартная установка выпускает сертификат ровно на ваше имя, то есть отправляет его в эти журналы.

**Форма трафика.** Объёмы, длительность соединения, ритм запросов и соотношение отправленного к полученному.

А вот чего наблюдателю не видно: содержимого. Данные внутри зашифрованы дважды — обычным защищённым соединением браузера и собственным шифрованием MTProxy, и реле само не может их прочитать.

## Способ первый: по имени домена и адресу

Это то, чем в реальности блокируют почти всё, и WEB-прокси здесь ничем не выделяется.

Механика простая: имя вашего домена попадает в список, и оборудование фильтрации перестаёт пропускать соединения, в первом пакете которых оно встречается. Либо в список попадает адрес сервера — тогда не проходит вообще ничего. Обход по типу «сменить порт» не помогает: в мае 2026 года полевой тест издания te-st.org показал, что нестандартные порты у MTProxy блокировались наравне с обычным.

Отдельно стоит понимать про белые списки. С сентября 2025 года в России действует «реестр социально значимых сервисов», и в мобильных сетях наблюдались периоды, когда пропускались только соединения к именам из разрешённого списка, а всё остальное отбрасывалось. Против такого режима не помогает ни одна маскировка: ваш домен просто не входит в список, и обсуждать признаки трафика уже бессмысленно.

**Цена для цензора:** копеечная. **Защита:** её нет ни у одного решения со своим доменом.

## Способ второй: собрать ссылки, которые вы сами опубликовали

Самый недооценённый вектор — и при этом главный для прокси Telegram последние годы.

Ссылку вида `https://t.me/webproxy?server=…&secret=…` кто-то публикует в открытом канале или отдаёт боту. Дальше её собирает автоматика, извлекает домен, резолвит адрес и отправляет и то, и другое в списки. Технически это ровно то же самое, что и первый способ, но искать сервер не нужно — оператор сам его назвал.

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

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

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

## Способ третий: постучаться на сервер и посмотреть, что ответит

Это называется активным зондированием, и вот здесь проект действительно хорош — лучше типовых схем с обходным путём на отдельный веб-сервер.

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

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

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

**Цена для цензора:** средняя. **Защита:** высокая, если сайт-прикрытие действительно ваш и не собран по общему шаблону. Готового шаблона в проекте намеренно нет именно поэтому, но формулировка запроса для генератора сайта в репозитории лежит — и её прочитает не только оператор.

## Способ четвёртый: по форме трафика

Самый интересный и самый дорогой. Именно здесь остаются признаки, которые проект не скрывает.

**Длительность.** Соединение к «сайту-визитке» живёт часами. Обычные посетители так себя не ведут.

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

**Асимметрия.** Обычный сёрфинг устроен так: маленький запрос, большой ответ. Здесь тела запросов достигают двух мегабайт, а суммарно отправленное сопоставимо с полученным.

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

Теперь честно про то, работает ли это на практике. Академические работы 2024–2025 годов показывают, что туннели такого типа распознаются по размерам и порядку первых пакетов с точностью около 70–86% при доле ложных срабатываний порядка сотых долей процента. Звучит грозно, но авторы сами оговаривают главное: при национальных масштабах и редкости такого трафика даже одна ошибка на две тысячи соединений даёт больше ложных срабатываний, чем настоящих. Проще говоря, включив такой фильтр, оператор сломает больше обычных сайтов, чем поймает прокси.

Поэтому в реальности применяют более грубые, но дешёвые варианты той же идеи. В России с апреля 2024 года наблюдалась блокировка по числу и размерам первых пакетов, с июня 2025 — «заморозка» соединения после первых полутора-двух десятков килобайт независимо от протокола, с ноября 2025 — обрыв соединений вскоре после начала передачи данных. Все эти сообщения происходят из сообщества, а не из измерительных исследований, но их много и они согласуются между собой.

Что важно для WEB-прокси: **грубые пороги по объёму бьют по нему ровно так же, как по обычному HTTPS**, и никакая маскировка под сайт от них не спасает. Зато сложные поведенческие классификаторы, которых все боятся, пока нигде не подтверждены в работе — единственная система фильтрации, чей исходный код удалось изучить, распознаёт средства обхода сигнатурами и списками, а не машинным обучением.

**Цена для цензора:** высокая. **Защита:** частичная и не заявленная авторами. Анализа устойчивости к такому анализу в документации проекта нет — это прямо отмечено и в [[tproxy/tproxy|обзорной заметке]].

## Способ пятый: журналы выдачи сертификатов

Тихий и неочевидный вектор. Каждый выпущенный публичным центром сертификат попадает в открытый журнал прозрачности, где его видит кто угодно.

Практическое следствие: если вы выпустили сертификат на `proxy.example.com`, то само существование этого поддомена стало публичным фактом. Сопоставив свежие записи журналов с доменами, которые всплывают в каналах раздачи прокси, можно искать серверы, ещё до того как ими начнут пользоваться.

Обход существует, но в проекте не описан: выпускать не отдельный сертификат на говорящий поддомен, а групповой сертификат на весь домен через подтверждение по записи DNS. Тогда конкретное имя в журнале не светится.

## Чего заблокировать нельзя

Отдельно стоит сказать, чего цензор сделать не может, — чтобы картина не выглядела безнадёжной.

**Нельзя опознать содержимое.** Оно зашифровано дважды, и даже сам сервер-реле не может его прочитать.

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

**Нельзя заблокировать «все такие серверы разом».** Признака, который отличал бы их от обычных сайтов и при этом не ломал бы обычные сайты, на сегодня не предъявлено. Заблокировать класс можно только вместе со всем похожим трафиком — то есть фактически вместе с обычным вебом, а на это идут редко и ненадолго.

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

## А забанят ли за это самого пользователя или оператора

Технических механизмов «бана за прокси» со стороны Telegram не существует, и WEB-прокси здесь ничего не меняет: для серверов Telegram это обычное соединение через MTProxy. Аккаунт пользователя мессенджер по факту использования прокси не блокирует.

Что стоит держать в голове оператору. Во-первых, у проекта **нет лицензии** — по умолчанию это значит «все права защищены», то есть формального разрешения использовать код в коммерческом сервисе никто не давал. Во-вторых, чтобы пользователь вообще смог подключиться сегодня, ему нужна самостоятельно собранная сборка Telegram, а её распространение тянет за собой отдельные обязательства. В-третьих, у обычного MTProxy давно есть требование показывать спонсорский канал, и как эта практика будет выглядеть для нового типа прокси, пока неизвестно.

## Что делать оператору

- [ ] Не публиковать ссылку в открытых каналах: это главный способ, которым такие серверы находят.
- [ ] Держать несколько доменов на разных адресах, чтобы блокировка одного не выключала всех сразу.
- [ ] Сделать сайт-прикрытие своим: собственные тексты и оформление, а не общий шаблон и не результат одного и того же запроса к генератору.
- [ ] Рассмотреть групповой сертификат через подтверждение по записи DNS, чтобы говорящее имя не светилось в журналах прозрачности.
- [ ] Заранее написать процедуру переезда: новый домен требует не только новых записей, но и перевыдачи пары «домен плюс секрет» всем пользователям, и нового сайта-прикрытия.
- [ ] Не включать журнал доступа на веб-сервере: в адресе запроса едет пропуск, а в режимах веб-сокета — токен сессии.
- [ ] Следить за состоянием бэкенда: при упавшем MTProxy сайт продолжает выглядеть здоровым, а пользователи вечно «подключаются» (проверки описаны в [[tproxy/tproxy-server-setup|заметке про установку]]).

## Итог

Заблокировать **конкретный** сервер WEB-прокси просто, дёшево и делается теми же средствами, что и блокировка любого домена. Здесь у него нет никаких преимуществ перед MTProxy или [[VLESS/VLESS|VLESS]], а восстановление после блокировки даже дороже — из-за привязки пропуска к домену.

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

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

## 📚 См. также

- [[tproxy/tproxy|WEB-прокси Telegram: трафик внутри обычного сайта]] — что это такое, зачем появилось и можно ли пользоваться сейчас.
- [[tproxy/tproxy-protocol|Как устроен WEB-прокси изнутри]] — откуда берутся 25 секунд ожидания, привязка пропуска к домену и единообразие ответов.
- [[tproxy/tproxy-server-setup|Установка tproxy-server]] — сайт-прикрытие, сертификат, запрет журналов доступа.
- [[tproxy/tproxy-in-bot|Выдача WEB-прокси из Telegram-бота]] — почему перевыдача пары всем пользователям стоит дорого.
- [[DPI/DPI|Раздел про DPI и ТСПУ]] — как оборудование фильтрации разбирает соединения в принципе.
- [[mtproxy/mtproxy|MTProxy и Telegram-транспорты]] — как те же приёмы применялись к обычному MTProxy и чем это закончилось весной 2026 года.

---

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