🦎 MTProxy и mtproto.zig: что это, как работает и как пережить ТСПУ

О чём статья

Простым языком: что такое MTProxy (прокси для Telegram), что такое FakeTLS, по каким признакам его ловит DPI/ТСПУ, и какими техниками с этим борется проект mtproto.zig — современная реализация прокси, которая ставит обход «под ключ». В конце — готовые настройки и чек-лист.

Материал исследовательский и образовательный: цель — понять механику, а не дать «волшебную галочку».

🛠️ Нужны конкретные команды и пошаговая настройка? → Runbook: настройка mtproto.zig.

---

TL;DR — если совсем коротко

• MTProxy — это «дверь» к Telegram в обход блокировки. Телега умеет ходить через него нативно, ставить ничего не надо — достаточно ссылки tg://.
• Современный режим — FakeTLS: прокси прикидывается обычным HTTPS-сайтом, чтобы DPI видел «человек зашёл на rutube.ru», а не «кто-то лезет в Telegram».
• FakeTLS — это камуфляж, а не невидимость. Продвинутый DPI (ТСПУ) умеет его распознавать по нескольким признакам.
• mtproto.zig наслаивает больше анти-DPI техник, чем другие прокси, и сам настраивает обход на уровне ОС (дробление пакетов + zapret). Почти всё включено по умолчанию.
• Но против поведенческого DPI (см. сибирскую схему) MTProxy слабее VLESS+REALITY. Держите оба: MTProxy — для Telegram «для своих», REALITY — основной канал.

---

Часть 1. Что такое MTProxy и зачем он

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

Прелесть в том, что поддержка прокси встроена в сам Telegram. Не нужен отдельный VPN-клиент, не нужно ничего устанавливать: человек жмёт на ссылку вида tg://proxy?..., Telegram спрашивает «Подключиться?», и всё снова работает.

MTProto vs MTProxy

MTProto — это родной протокол шифрования Telegram. MTProxy (MTProto Proxy) — прокси, говорящий на этом протоколе. Не путать с обычным SOCKS5/HTTP-прокси: MTProxy «понимает» именно Telegram.

Три режима — и почему важен только один

Исторически у MTProxy три способа замаскировать трафик:

Режим	Что делает	Безопасность
Classic	голый обфусцированный MTProto	🔴 ловится мгновенно по сигнатуре
Secure / dd	+ случайный паддинг, но без TLS	🟠 всё ещё опознаётся как MTProto
FakeTLS / ee	завёрнут в настоящий с виду TLS 1.3	🟢 выглядит как обычный HTTPS

На практике сегодня имеет смысл только FakeTLS (ссылки-секреты начинаются с ee). Остальные DPI видит насквозь.

---

Часть 2. Как работает FakeTLS — «на пальцах»

Когда вы заходите на любой https://-сайт, ваш браузер и сервер сначала здороваются по протоколу TLS. Первое сообщение браузера называется ClientHello — это открытая «визитка»: какие шифры поддерживаю, какие расширения, на какой сайт иду (поле SNI). Сервер отвечает ServerHello. Только потом начинается шифрование.

FakeTLS притворяется этим рукопожатием. Клиент Telegram шлёт на прокси пакет, который выглядит как обычный ClientHello (с SNI, например, rutube.ru), прокси отвечает правдоподобным ServerHello — и для DPI снаружи это «кто-то открыл rutube.ru по HTTPS». А внутри едет зашифрованный MTProto.

Аналогия

FakeTLS — это чемодан с идеальной наклейкой «турист едет в Сочи». Снаружи не отличить от настоящего. Но, как мы увидим, таможня (DPI) научилась смотреть не только на наклейку.

---

Часть 3. Как ТСПУ ловит FakeTLS

ТСПУ — «Технические Средства Противодействия Угрозам», DPI-оборудование, установленное у российских операторов. Полный каскад его проверок — в 05-censorship и воронке проверок. Здесь — то, что бьёт именно по FakeTLS.

Признак 1. Фингерпринт ClientHello (JA3/JA4) — главный

Каждая программа собирает ClientHello по-своему: свой порядок шифров, свой набор расширений. Этот «почерк» сворачивают в хеш — JA3 или JA4. По нему DPI понимает: «это Chrome 131» или «это клиент Telegram».

Проблема: почерк FakeTLS-клиента Telegram фиксированный и узнаваемый. В нём нет тех мелочей, что есть у настоящего браузера (GREASE, ECH, post-quantum ключи — подробнее в разборе про uTLS). DPI просто сверяет хеш со списком — и опознаёт прокси.

Ключевой момент

Этот почерк генерирует приложение Telegram на телефоне, а не ваш сервер. Значит, вы как владелец прокси не можете его поменять. Нет аналога uTLS из REALITY, который умеет рядиться под Chrome.

Признак 2. Активное зондирование (active probing)

ТСПУ не только пассивно смотрит — он сам стучится на подозрительный сервер: «А ну-ка покажи, что ты за HTTPS». Если сервер на это отвечает как-то странно (молчит, рвёт соединение) вместо нормального TLS — значит, это не сайт, а прокси. Блок.

Признак 3. Подсеть и ASN

DPI смотрит, откуда соединение. Если SNI говорит «rutube.ru», а IP принадлежит дешёвому хостингу (Hetzner, Selectel) — это аномалия. В сибирской схеме это вообще Сигнал №1.

Признак 4. Поведение — частота и тайминги

Самый современный слой. DPI смотрит не в пакет, а на манеру: сколько соединений, как часто, какие размеры пакетов. Прокси открывает залп коннектов к одному «домену» — живой человек так не делает.

Итог раздела

FakeTLS пробивается через простой DPI («это TLS или нет?»), но против ТСПУ имеет четыре уязвимых места: почерк, зонды, подсеть, поведение. Дальше — чем mtproto.zig закрывает каждое.

---

Часть 4. Чем mtproto.zig отвечает на каждый признак

mtproto.zig — пятая независимая реализация MTProxy (после telemt/mtg/mtprotoproxy/mtproto_proxy, см. 02-implementations), на языке Zig, с CLI-менеджером mtbuddy. Главное отличие: она сама ставит обход на уровне ОС, а не только проксирует.

Признак ТСПУ	Техника-ответ	Где включается
Фингерпринт ClientHello	TCPMSS=88 — дробит ClientHello на куски	mtbuddy install (OS)
Stateful DPI	nfqws desync (fake + split)	mtbuddy install (OS)
Сигнатуры в потоке	Split-TLS / desync ServerHello	config.toml (дефолт on)
Активное зондирование	Масштировка (mask) + anti-replay	config.toml (дефолт on)
Статистика трафика	DRS — мимикрия размеров записей	config.toml
Подсеть/бан IP	IPv6-hopping	флаг --ipv6-hop

🔑 Хитрость №1: TCPMSS=88 — обойти «нельзя поменять ClientHello»

Мы выяснили, что содержимое почерка изменить нельзя. Но можно сделать так, чтобы DPI физически не увидел его целиком.

При установке соединения сервер сообщает клиенту максимальный размер пакета — MSS. Если выставить MSS = 88 байт, то клиентский телефон будет вынужден резать всё, что шлёт (включая ClientHello ~517 байт), на ~6 крошечных кусочков.

DPI, который не собирает поток целиком (а это дорого, и многие не собирают), видит обрывки и не может приложить сигнатуру к разорванному почерку.

Что это значит

Содержимое визитки то же — но она разрезана на 6 частей и приходит по очереди. Таможенник, который читает только первую часть, не может опознать «турист — это прокси».

• Включено по умолчанию. Отключить: --no-tcpmss. Поменять: --tcpmss <n>.

🔑 Хитрость №2: nfqws TCP desync (zapret) — обмануть stateful DPI

mtproto.zig встраивает движок zapret/nfqws — тот же, что в Discord. Он манипулирует исходящими пакетами, чтобы у DPI «поехала» картина соединения:

• fake-пакет — перед настоящим шлётся фальшивый «валидный» TLS, чтобы запутать машину состояний DPI;
• TTL-limited split — у фейка специально занижен TTL (время жизни): он долетает до ТСПУ, но умирает до настоящего клиента (ТСПУ ближе). ТСПУ видит фейк и сбивается, клиент — нет;
• md5sig fooling — к фейку добавляется «битая» TCP-опция: настоящие участники её отбрасывают, а простой парсер ТСПУ принимает в свой учёт.

Важная настройка — TTL

По умолчанию TTL = 6, но это надо тюнить под вашего провайдера (подсказка из проекта: «4–8 для большинства росс. ISP»). TTL должен быть больше расстояния до ТСПУ, но меньше расстояния до клиента. Прикинуть можно через traceroute. Поменять: mtbuddy nfqws --ttl <n>.

🔑 Хитрость №3: Mask — защита от зондов

Когда на прокси стучится неаутентифицированный клиент (нет правильного секрета — а значит, это либо ошибка, либо зонд ТСПУ), mtproto.zig с mask=true молча перенаправляет его на настоящий tls_domain. Зонд получает реальный TLS-ответ настоящего сайта и «верит», что перед ним обычный HTTPS-сервер.

Дополнительно есть anti-replay и детект зондов Revisor (специфичных для ТСПУ).

🔑 Хитрость №4: правильный домен (tls_domain)

Прокси в ServerHello притворяется конкретным сайтом. Важно выбрать домен, чьё поведение прокси реально может повторить:

• ✅ Берите популярные домены с одним раундом x25519: rutube.ru, ozon.ru, vk.com, yandex.ru.
• ❌ Избегайте доменов с HRR/secp521r1 (например wb.ru) — упрощённый FakeTLS их не повторит, и получится аномалия.
• ⚠️ Домен вшивается в ссылку tg:// и его нельзя менять после раздачи.

---

Часть 5. Настройки — что куда ставить

Главное про конфиг

Почти вся защита включена по умолчанию. В config.toml осознанно трогаете три вещи (tls_domain, mask, fake_tls_only). А TCPMSS и nfqws — это уровень ОС, они ставятся флагами mtbuddy install, а не в config.toml.

Установка «под ключ»

# Всё включено: FakeTLS + TCPMSS=88 + nginx-masking + nfqws desync
sudo mtbuddy install --port 443 --domain rutube.ru --yes
 
# Со своим секретом и юзером
sudo mtbuddy install --port 443 --domain rutube.ru --secret <32hex> --user alice --yes

Полезные DPI-флаги: --tcpmss <n> (дефолт 88), --no-tcpmss, --no-nfqws, --no-masking, --ipv6-hop, --no-dpi (выключить всё).

Рекомендуемый config.toml

Большинство строк — уже дефолты; фиксируем ключевые явно.

[general]
use_middle_proxy = true        # нужно для медиа на не-Premium и promo-тегов
 
[server]
port = 443                     # любой другой порт подозрителен
# rate_limit_per_subnet = 0    # ОСТАВЬ 0 для мобильных юзеров РФ (carrier-NAT):
                               # иначе зарубишь реальных людей на одной подсети
 
[censorship]
tls_domain = "rutube.ru"       # single-round x25519, НЕ wb.ru; неизменен после раздачи
mask = true                    # форвард зондов на домен (анти-probing)
fake_tls_only = true           # реджектить палевный dd-транспорт
# desync = true                # дефолт on — дробит ServerHello
drs = true                     # мимикрия размеров TLS-записей под браузер
fast_mode = true
 
[access.users]
# секрет на юзера: openssl rand -hex 16
user1 = "00112233445566778899aabbccddeeff"

Осознанные решения:

• tls_domain — единственный критичный выбор (см. Хитрость №4).
• mask = true + fake_tls_only = true — анти-зонд и отказ от dd.
• drs = true — дефолт false; включить стоит, скорость не падает.
• rate_limit_per_subnet = 0 — оставить для мобильных юзеров РФ за carrier-NAT, иначе ложные баны реальных людей.

---

Часть 6. Чего НЕ делать

Лимит SYN-ACK (1/сек) — спорный приём, но может работать

Гуляет приём — дропать исходящие SYN-ACK сверх 1/сек правилом nft (tcp sport <port> ... limit rate over 1/second burst 1 packets drop). Его часто называют вредным — но это слишком категорично.

На пальцах: SYN-ACK — это ответ сервера «да, можем общаться» во время установки соединения. Если сервер иногда «теряет» этот ответ, клиент переспрашивает через секунду. От этого (а) DPI сбивается со счёта на «кривом» рукопожатии и не опознаёт почерк клиента, и (б) почерк выходит не пачкой, а по одному в секунду — не срабатывает триггер «залпа соединений».

Честная картина:

• Цена: медленная установка новых соединений (каждое сверх лимита ждёт ~1с). Для Telegram с долгоживущими коннектами — терпимая разовая задержка; для веб-сёрфинга было бы больно.
• Глобальный вариант калечит всех юзеров сразу → правильнее per-port лимит (каждому юзеру свой порт = свой бюджет 1/сек).
• Не лечит корень (фингерпринт) — обходной костыль, может перестать работать при адаптации ТСПУ.

Вывод: тестируй per-port вариант на своём маршруте. Встроенный mask+anti-replay это не заменяет, а дополняет. Подробный разбор с аналогией «на пальцах» и обоими nft-вариантами — в 10-telemt-logs-dpi.

• Не раздавайте dd-ссылки при активном DPI — это plain MTProto, палится сразу.
• Не меняйте tls_domain после раздачи — он вшит в ссылки.
• Не дёргайте настройки под блокировкой — в сибирской схеме сам паттерн «поймал блок → тут же поменял» провоцирует расширенный блок. Лучше переждать или сменить узел.

---

Часть 7. Честный потолок: почему MTProxy слабее REALITY

Три структурных причины (подробно — разбор DPI июнь-2026):

1. Почерк клиента не контролируешь — нет uTLS, JA3/JA4 Telegram фиксирован (Признак 1).
2. CDN-фронтинг почти невозможен — клиент идёт прямо на ваш IP:port, подсеть не спрятать (Признак 3). Частичный рычаг — IPv6-hopping и «чистый» провайдер (VPS).
3. Нет mux — залп коннектов сгладить нечем (Признак 4).

Сам проект в THREAT_MODEL.md честно пишет: «hardened transport tool, not a universal censorship-proof channel» — закалённый инструмент, а не универсальная неуязвимость.

Почерк и SNI меняются только на клиенте

Новая детекция (июнь 2026) бьёт по связке «JA4 Telegram + один SNI + залп на один ip:port». Сменить JA4 или ротировать SNI серверный прокси не может — их задаёт клиент Telegram, и цензор видит их ещё до сервера. Почему так и что тогда может сервер — в SNI.

Правильная стратегия

Держите оба: MTProxy — удобная «дверь» в Telegram для близких (ноль установки), VLESS+REALITY/XHTTP — основной обход для всего. Когда VLESS «болеет», MTProxy на росс. VPS часто даёт полную скорость, и наоборот.

---

✅ Чек-лист для запуска

• Режим только FakeTLS (ee-ссылки), порт 443, раздача приватная
• tls_domain — single-round x25519, приличный ASN, выбран один раз
• mask = true, fake_tls_only = true, drs = true
• TCPMSS=88 активен (iptables -t mangle -S показывает TCPMSS-правило)
• nfqws запущен и TTL подтюнен под маршрут (systemctl status nfqws-mtproto)
• rate_limit_per_subnet = 0, если юзеры за мобильным NAT РФ
• Готов запасной VLESS/XHTTP
• Перестал работать → меняй IP/узел, не крути настройки на лету

---

📚 См. также

• 🔗 Репозиторий: sleep3r/mtproto.zig
• ТСПУ и обход цензуры для MTProto — полный каскад детекции
• 4 реализации MTProxy — telemt / mtg / … (без zig)
• MTProxy vs VLESS
• Best practices: домен и ASN
• Сибирская схема: подсеть + фингерпринт + частота
• Воронка проверок DPI: от SYN до ML
• Выбор VPS и подсети
• Звонки Telegram — через MTProxy не работают