1 апреля пользователи MTProxy начали массово сообщать о проблемах с доступностью прокси-серверов, включая решения на базе telemt. Жалобы поступают из разных регионов и затрагивают как частные инсталляции, так и инфраструктуру, размещённую у крупных хостинг-провайдеров.
По наблюдениям пользователей, сбои проявляются по-разному: от увеличенного времени подключения до полной недоступности прокси. В ряде случаев соединение устанавливается, но работает нестабильно, медиа загружается медленно или не загружается вовсе.
Основная версия, обсуждаемая в сообществе - внедрение обновлённых механизмов DPI, способных выявлять трафик, маскируемый под TLS (в частности, Fake-TLS). Косвенно это подтверждается тем, что перенос серверов между провайдерами, включая облачные платформы, даёт лишь временный эффект или не помогает совсем.
Также отмечаются следующие особенности:
прокси с собственными доменами стали работать хуже или перестали подключаться;
поведение отличается в зависимости от клиента: десктопные приложения иногда продолжают работать, тогда как мобильные чаще сталкиваются с проблемами;
смена портов (443, 8443 и других) не даёт стабильного результата;
у части пользователей соединение временно восстанавливается после реконнекта или смены сети;
даже при успешном подключении наблюдаются задержки и деградация качества соединения.
Помимо сигнатур, DPI, вероятно, начал учитывать поведенческие характеристики трафика. Это может объяснять, почему изменения на стороне сервера (включая обновления telemt) не приводят к устойчивому результату.
На фоне происходящего в сообществе обсуждается альтернативный подход - использование DD вместо EE. Однако на текущий момент этот способ не демонстрирует стабильной эффективности и не может рассматриваться как полноценное решение.
Дополнительное внимание привлекло появление обновлённого Docker-образа официального MTProto-прокси (версия 2.0beta от 1 апреля 2026 года). Пользователи уже заметили изменения, связанные с многопоточностью и ограничениями на соединения, однако пока неясно, помогут ли эти доработки в условиях новых фильтров.
UPD: В комментариях уточнили возможную первопричину наблюдаемых сбоев. Речь может идти не столько о самих прокси, сколько о TLS-фингерпринте клиента Telegram, используемом при установлении соединения.
При таком сценарии DPI-фильтрация ориентируется не на адреса или сигнатуры прокси-серверов, а на характерные особенности TLS-рукопожатия клиента. Это объясняет большинство наблюдаемых эффектов. Также это согласуется с наблюдениями о недетерминированном поведении фильтрации: часть соединений может проходить до момента, пока IP-адрес не попадает под ограничения.
Если данная гипотеза верна, исправление ситуации, вероятно, потребует изменений на стороне клиента Telegram (например, модификации TLS-параметров), а не только обновлений прокси-решений.
