Перейти к содержанию

Устойчивость к DPI

Teleproxy включает несколько уровней защиты от систем глубокого анализа пакетов (DPI), которые пытаются обнаружить и заблокировать трафик MTProxy.

Текущая ситуация с угрозами

Российские DPI-системы (ТСПУ/АСБИ) классифицируют MTProxy fake-TLS как отдельный протокол («TELEGRAM_TLS»). Обнаружение основано на отпечатке TLS на стороне клиента: ClientHello приложения Telegram несёт один фиксированный JA4-отпечаток, который DPI сопоставляет с сигнатурой. Прокси не может это изменить — байты формирует клиент Telegram, а не сервер.

В 2026 году было две различимые волны блокировок:

Апрель 2026 (статичный отпечаток). ТСПУ сопоставлял статичный JA4/JA3 ClientHello fake-TLS, опираясь на признаки, которые не отправляет ни один настоящий браузер (некорректный код расширения 0xfe02 и 20-байтовое случайное поле). Telegram исправил эти артефакты на стороне клиента (tdesktop PR #30513, DrKLO Android PR #1949), что восстановило связь до конца мая.

Конец мая – июнь 2026 (пересборка + корреляция потоков). Апрельское исправление лишь заменило один статичный отпечаток другим — клиент по-прежнему отправляет единственный фиксированный JA4. Эта волна сложнее:

  • Теперь ТСПУ пересобирает TCP-потоки перед снятием отпечатка, поэтому разбиение ClientHello на сегменты больше не скрывает его. Полевые тесты с агрессивным занижением серверного MSS (256, затем 88 байт), проверенные на проводе, всё равно блокировались на узлах с пересборкой.
  • Активная корреляция потоков. Несколько ClientHello с одинаковым SNI + JA4 Telegram на один и тот же ip:port приводят к временному обрыву соединения. IP прокси также сверяется с A-записью домена-прикрытия — случайный SNI, который не резолвится в IP прокси, не проходит. Ротация SNI по реальным доменам-прикрытиям или распределение по IP/портам нейтрализует эту корреляцию.
  • Тихие потери пакетов, без RST. TLS-рукопожатие завершается; как только начинается передача данных приложения MTProto, пакеты отбрасываются без сброса соединения, и клиент засыпает ретрансмиссиями (симптом «подключается, потом отваливается через ~30 секунд»).

Ключевые наблюдения:

  • Мобайл vs дом — это неравномерность, а не политика. Один и тот же прокси часто работает в мобильной сети оператора, но не работает в его же проводной/домашней сети (и наоборот, и iOS vs Android могут различаться). Это неравномерное развёртывание пересборки на узлах ТСПУ — прокси один и тот же, отличается DPI-узел на пути, — а не решение оператора. Билайн, МТС, Мегафон, Ростелеком сообщались и так, и так.
  • VPN / туннели Reality полностью обходят отпечаток MTProto (см. плейбук оператора ниже).
  • Инструменты фрагментации на стороне клиента (zapret, GoodbyeDPI) всё ещё помогают на путях без пересборки, но теперь зависят от пути, поскольку часть узлов пересобирает поток.
  • Рандомизация отпечатка клиента Telegram (надёжное исправление) пока обсуждается в апстриме и ещё не выпущена.

Что делает Teleproxy (серверная сторона)

Камуфляж Fake-TLS

Весь трафик оборачивается в записи TLS 1.3 с ClientHello профиля Chrome. Подробнее см. Fake-TLS.

Собственный TLS-бэкенд (защита от активного зондирования)

DPI-системы активно зондируют подозрительные прокси. При работе с реальным TLS-бэкендом (nginx с валидным сертификатом) каждое невалидное подключение — неверный секрет, истекшая метка времени, DPI-зонд — перенаправляется на настоящий веб-сайт. Зонд видит легитимный HTTPS-сервер.

Это наиболее эффективная серверная мера. Подробнее см. Fake-TLS: Собственный TLS-бэкенд.

Динамическое изменение размера записей (DRS)

Размеры TLS-записей следуют градуированному шаблону, соответствующему реальным веб-серверам (Cloudflare, Caddy): размер MTU во время медленного старта, нарастание до максимума. К каждой записи добавляется случайный шум. Это нейтрализует статистический анализ, который определяет прокси-трафик по однородным размерам записей.

Вариативность ответа ServerHello

Размер зашифрованной части ServerHello варьируется до ±32 байт между подключениями, имитируя естественное разнообразие размеров цепочки сертификатов и сессионных тикетов реальных TLS-серверов. ServerHello и ChangeCipherSpec отправляются как отдельные TCP-сегменты, чтобы DPI не мог сопоставить полный ответ рукопожатия в одном пакете.

Принудительная фрагментация ClientHello (автоматически)

Teleproxy объявляет малый TCP MSS (256 байт) в SYN-ACK на публичном порту прокси. Ядро клиента подчиняется ограничению и режет исходящий ClientHello (~500-700 байт) на 2-3 TCP-сегмента, так что нужные для JA4 данные (ALPN, signature_algorithms) попадают в более поздние сегменты.

Честная оценка (обновлено в июне 2026). Это нейтрализует только тот DPI, который снимает отпечаток с одного пакета. Текущая волна ТСПУ пересобирает TCP-поток перед хешированием, поэтому на таких узлах фрагментация ничего не даёт — полевые тесты с занижением MSS вплоть до 88 байт, проверенные на проводе, всё равно блокировались. Приём остаётся полезен против узлов без пересборки (часть мобильных путей) и сочетается с уже имеющейся сегментацией ServerHello, поэтому по умолчанию остаётся включённым. Но сам по себе он не решает июньскую волну — см. плейбук оператора ниже, что реально помогает сейчас.

Работает автоматически, не требует настройки, действует против немодифицированных клиентов Telegram на любой платформе. HTTP-листенер /stats / /metrics использует системный MSS по умолчанию и не затрагивается.

Компромисс: Linux применяет MSS слушающего сокета к обоим направлениям каждого принятого соединения, поэтому сегменты сервер→клиент также ограничены 256 байтами. Количество пакетов вырастает примерно в 5 раз, а накладные расходы TCP/IP-заголовков растут с ~3% до ~15%. На современном оборудовании с TSO/GSO нагрузка на CPU остаётся управляемой, но прокси, упирающиеся в пропускную способность, увидят заметное ограничение.

Как отключить. Операторы, которые предпочтут риск JA4-детектирования снижению пропускной способности, могут отключить ограничение:

  • TOML: mss_clamp = false (ключ верхнего уровня)
  • CLI: --no-mss-clamp
  • Docker / start.sh: MSS_CLAMP=false (или MSS_CLAMP=0)

Любой из этих способов возвращает объявление MSS в SYN-ACK к системному значению по умолчанию — каждое принятое соединение получает нормальный MSS в обоих направлениях, и прокси несёт массовый MTProto-трафик на полной скорости. По умолчанию фрагментация остаётся включённой, поскольку для большинства пользователей работающий, но чуть более медленный прокси предпочтительнее быстрого, но заблокированного.

Рандомизация GREASE

Каждый ClientHello (для зондирования upstream-домена) использует свежие значения GREASE согласно RFC 8701, предотвращая статическое сопоставление отпечатков.

Что можно сделать (настройка сервера)

Используйте порт 443

TLS-трафик на нестандартных портах (8443, 6443) вызывает подозрения. Всегда запускайте Teleproxy на порту 443:

./teleproxy -H 443 -S <secret> -D example.com ...

Выберите популярный домен

Выберите популярный домен за CDN для SNI (например, www.google.com, cloudflare.com). Домен должен поддерживать TLS 1.3. Teleproxy зондирует домен при запуске, чтобы изучить характеристики его ServerHello и имитировать их.

Настройте собственный TLS-бэкенд

Если вы контролируете домен сервера, настройте nginx с валидным TLS-сертификатом за Teleproxy. Это делает сервер неотличимым от обычного HTTPS-сайта при активном зондировании. Подробнее см. Fake-TLS: Собственный TLS-бэкенд.

Используйте случайное дополнение (режим DD)

Для провайдеров, определяющих MTProto по размерам пакетов, включите случайное дополнение, добавив префикс dd к клиентскому секрету. Честное замечание: это помогает против эвристик по размеру пакетов у части провайдеров, но никак не влияет на детектирование по JA4, которое движет июньской волной 2026 года — не полагайтесь на него в одиночку.

Как пережить июньскую волну 2026 (плейбук оператора)

Текущая волна опирается на JA4 клиента плюс корреляцию (SNI + ip:port) и пересобирает TCP. Серверные трюки с отпечатком не могут изменить JA4 клиента, поэтому в поле держатся те меры, которые размывают корреляцию и уводят исходящий трафик с MTProto. Примерно в порядке приоритета:

1. Ротируйте SNI по нескольким реальным доменам-прикрытиям

Корреляция срабатывает, когда много соединений с одинаковым SNI + JA4 Telegram приходят на один ip:port. Зарегистрируйте несколько доменов-прикрытий и раздавайте разным пользователям ссылки с разными SNI:

./teleproxy -H 443 -S <secret> \
  -D www.cloudflare.com:127.0.0.1:8443 \
  -D www.microsoft.com:127.0.0.1:8443 \
  -D www.apple.com:127.0.0.1:8443

У каждого домена SNI отделён от бэкенда (EE_DOMAIN/EE_BACKEND или форма -D sni:backend:port), поэтому все они могут использовать один локальный TLS-бэкенд. Wildcard-сертификаты (-D '*.example.com:backend:443') тоже работают.

A-запись домена-прикрытия должна резолвиться в IP прокси. Случайный SNI, указывающий в другое место, не проходит июньскую сверку с A-записью. Используйте домены, которыми владеете (или хост wildcard-сертификата), реально указывающие на прокси.

2. Распределяйте по IP и портам и держите IP чистыми

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

3. Каскадируйте исходящий трафик через VLESS + Reality (самый надёжный вариант)

Самый надёжный из проверенных в поле способов — вообще перестать выпускать MTProto-образный трафик за пределы цензурируемой сети: запустите teleproxy в прямом режиме и направьте его исходящие подключения к DC через локальный клиент Xray VLESS + Reality по SOCKS5:

# teleproxy на машине внутри страны, трафик к DC выходит через локальный Xray Reality
DIRECT_MODE=true
SOCKS5_PROXY=socks5://127.0.0.1:1080   # локальный исходящий Xray Reality

Клиент Telegram по-прежнему достигает teleproxy локально по fake-TLS, но границу ТСПУ пересекает Reality, который текущая волна не блокирует. Учитывайте компромиссы прямого режима (медиа на не-Premium аккаунтах, спонсируемые каналы). Это больше настройки, но именно это продолжает работать, когда обычный fake-TLS перестаёт.

Что могут сделать пользователи (клиентская сторона)

Основной вектор обнаружения — TLS-отпечаток клиента Telegram, который невозможно исправить на стороне сервера. Пользователям в затронутых сетях следует использовать инструменты обхода DPI на стороне клиента, которые фрагментируют TCP-сегменты:

Инструмент Платформа Метод
zapret Linux, Android (root) Фрагментация TCP, фейковые пакеты
zapret2 Linux, Android (root) Обновленный форк
GoodbyeDPI Windows Фрагментация TCP, трюки с TTL
NoDPI Android (без root) Локальный VPN с фрагментацией
SpoofDPI macOS, Linux HTTP/TLS splitting прокси

Эти инструменты фрагментируют ClientHello на несколько TCP-сегментов. На путях без пересборки это по-прежнему помогает, но июньская волна на части узлов пересобирает поток, поэтому результат зависит от пути — пробуйте, но это больше не гарантированное решение.

Обновляйте Telegram и следите за работой над рандомизацией

Надёжное исправление — это рандомизация TLS-отпечатка самим клиентом вместо единственного фиксированного JA4. Эта работа идёт в апстриме, но ещё не выпущена: tdesktop #30733 отслеживает запрос на ротацию/рандомизацию JA4, есть открытые PR (#30528, #30738) и более основательный проект telemt/tdlib-obf (маскировка ClientHello под реальные профили браузеров на основе захваченных pcap). Апрельское исправление отпечатка (tdesktop #30513) уже в текущих релизах — всегда используйте последний клиент, но помните, что до выхода рандомизации он по-прежнему отправляет единственный фиксированный JA4.

Что нельзя полностью исправить на серверной стороне

  • Содержимое TLS-отпечатка клиента: приложение Telegram контролирует побайтовое содержимое ClientHello, а ТСПУ находится между клиентом и прокси. Серверный код не может изменить то, что клиент кладёт в провод. MSS-ограничение может распределить эти байты по TCP-сегментам, но узлы DPI, которые пересобирают поток — как делает июньская волна 2026 года, — всё равно вычисляют правильный JA4. Единственное реальное исправление отпечатка — на стороне клиента (см. выше).
  • Блокировка IP/L3 и баны IP: когда DPI блокирует IP на сетевом уровне — включая баны после детектирования, перетекающие на соседние IP того же диапазона, — помочь может только VPN, каскад Reality или переход на чистый IP.
  • Различия в развёртывании ТСПУ: обнаружит ли конкретный путь трафик — зависит от версии аппаратного/программного обеспечения узла ТСПУ и от того, пересобирает ли он TCP. Это варьируется от оператора к оператору, от региона к региону и даже между мобильной и проводной сетью одного оператора.