Zapret Wiki

Недавно обновлено

время чтения ~12 мин.

.md

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

Обложка: что видно наблюдателю — имя домена, адрес, сертификат, форма трафика, и только ответы сервера неотличимы

О чём заметка

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

Что здесь доказано, а что нет

Устройство самого проекта проверено по исходному коду 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-прокси: восстановление после блокировки дороже, чем у соседей. Пропуск, по которому клиент опознаётся, вычисляется из пары «домен плюс секрет» (механика — в разборе протокола). Значит, переезд на новый домен требует не просто заменить адрес в конфигурации, а перевыдать всем пользователям новую пару. Плюс новому домену нужен свой сайт-прикрытие: переиспользовать старый нельзя, иначе одинаковые страницы снова свяжут площадки между собой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

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

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

📚 См. также

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

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

Вид графа

Обратные ссылки