# 🦎 MTProxy и mtproto.zig: что это, как работает и как пережить ТСПУ > [!info] О чём статья > Простым языком: что такое **MTProxy** (прокси для Telegram), что такое **FakeTLS**, по каким признакам его ловит DPI/ТСПУ, и какими техниками с этим борется проект **`mtproto.zig`** — современная реализация прокси, которая ставит обход «под ключ». В конце — готовые настройки и чек-лист. > > Материал **исследовательский и образовательный**: цель — понять механику, а не дать «волшебную галочку». > > 🛠️ Нужны конкретные команды и пошаговая настройка? → [[mtproxy/mtproto-zig-setup|Runbook: настройка mtproto.zig]]. --- ## TL;DR — если совсем коротко - **MTProxy** — это «дверь» к Telegram в обход блокировки. Телега умеет ходить через него нативно, ставить ничего не надо — достаточно ссылки `tg://`. - Современный режим — **FakeTLS**: прокси прикидывается обычным HTTPS-сайтом, чтобы DPI видел «человек зашёл на rutube.ru», а не «кто-то лезет в Telegram». - **FakeTLS — это камуфляж, а не невидимость.** Продвинутый DPI (ТСПУ) умеет его распознавать по нескольким признакам. - **`mtproto.zig`** наслаивает больше анти-DPI техник, чем другие прокси, и **сам** настраивает обход на уровне ОС (дробление пакетов + zapret). Почти всё включено по умолчанию. - Но против **поведенческого** DPI (см. [[VLESS/dpi-tls-june-2026|сибирскую схему]]) MTProxy слабее [[Zapret/mtproto/06-vs-vless|VLESS+REALITY]]. Держите оба: MTProxy — для Telegram «для своих», REALITY — основной канал. --- ## Часть 1. Что такое MTProxy и зачем он Представьте, что Telegram заблокирован: ваш интернет-провайдер не пускает трафик на серверы Telegram (их называют **DC** — дата-центры). MTProxy — это ваш личный сервер-посредник где-то в другом месте (на VPS). Телефон шлёт всё в Telegram **через него**, а уже он — в настоящие DC. Прелесть в том, что **поддержка прокси встроена в сам Telegram**. Не нужен отдельный VPN-клиент, не нужно ничего устанавливать: человек жмёт на ссылку вида `tg://proxy?...`, Telegram спрашивает «Подключиться?», и всё снова работает. > [!note] 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. > [!example] Аналогия > FakeTLS — это чемодан с идеальной наклейкой «турист едет в Сочи». Снаружи не отличить от настоящего. Но, как мы увидим, таможня (DPI) научилась смотреть не только на наклейку. --- ## Часть 3. Как ТСПУ ловит FakeTLS > ТСПУ — «Технические Средства Противодействия Угрозам», DPI-оборудование, установленное у российских операторов. Полный каскад его проверок — в [[Zapret/mtproto/05-censorship|05-censorship]] и [[DPI/dpi-analysis-pipeline|воронке проверок]]. Здесь — то, что бьёт именно по FakeTLS. ### Признак 1. Фингерпринт ClientHello (JA3/JA4) — главный Каждая программа собирает `ClientHello` по-своему: свой порядок шифров, свой набор расширений. Этот «почерк» сворачивают в хеш — **JA3** или **JA4**. По нему DPI понимает: «это Chrome 131» или «это клиент Telegram». Проблема: почерк FakeTLS-клиента Telegram **фиксированный и узнаваемый**. В нём нет тех мелочей, что есть у настоящего браузера (GREASE, ECH, post-quantum ключи — подробнее в [[VLESS/dpi-tls-june-2026|разборе про uTLS]]). DPI просто сверяет хеш со списком — и опознаёт прокси. > [!warning] Ключевой момент > Этот почерк генерирует **приложение Telegram на телефоне**, а не ваш сервер. Значит, **вы как владелец прокси не можете его поменять.** Нет аналога uTLS из REALITY, который умеет рядиться под Chrome. ### Признак 2. Активное зондирование (active probing) ТСПУ не только пассивно смотрит — он сам **стучится** на подозрительный сервер: «А ну-ка покажи, что ты за HTTPS». Если сервер на это отвечает как-то странно (молчит, рвёт соединение) вместо нормального TLS — значит, это не сайт, а прокси. Блок. ### Признак 3. Подсеть и ASN DPI смотрит, **откуда** соединение. Если SNI говорит «rutube.ru», а IP принадлежит дешёвому хостингу (Hetzner, Selectel) — это аномалия. В [[VLESS/dpi-tls-june-2026|сибирской схеме]] это вообще Сигнал №1. ### Признак 4. Поведение — частота и тайминги Самый современный слой. DPI смотрит не в пакет, а на **манеру**: сколько соединений, как часто, какие размеры пакетов. Прокси открывает залп коннектов к одному «домену» — живой человек так не делает. > [!summary] Итог раздела > FakeTLS пробивается через простой DPI («это TLS или нет?»), но против ТСПУ имеет **четыре уязвимых места**: почерк, зонды, подсеть, поведение. Дальше — чем `mtproto.zig` закрывает каждое. --- ## Часть 4. Чем `mtproto.zig` отвечает на каждый признак `mtproto.zig` — пятая независимая реализация MTProxy (после telemt/mtg/mtprotoproxy/mtproto_proxy, см. [[Zapret/mtproto/02-implementations|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, который не собирает поток целиком (а это дорого, и многие не собирают), видит обрывки и **не может приложить сигнатуру** к разорванному почерку. > [!tip] Что это значит > Содержимое визитки то же — но она разрезана на 6 частей и приходит по очереди. Таможенник, который читает только первую часть, не может опознать «турист — это прокси». - Включено по умолчанию. Отключить: `--no-tcpmss`. Поменять: `--tcpmss <n>`. ### 🔑 Хитрость №2: nfqws TCP desync (zapret) — обмануть stateful DPI `mtproto.zig` встраивает движок **zapret/nfqws** — тот же, что в [[Zapret/about|обходе для YouTube/Discord]]. Он манипулирует исходящими пакетами, чтобы у DPI «поехала» картина соединения: - **fake-пакет** — перед настоящим шлётся фальшивый «валидный» TLS, чтобы запутать машину состояний DPI; - **TTL-limited split** — у фейка специально занижен TTL (время жизни): он **долетает до ТСПУ, но умирает до настоящего клиента** (ТСПУ ближе). ТСПУ видит фейк и сбивается, клиент — нет; - **md5sig fooling** — к фейку добавляется «битая» TCP-опция: настоящие участники её отбрасывают, а простой парсер ТСПУ принимает в свой учёт. > [!warning] Важная настройка — 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. Настройки — что куда ставить > [!important] Главное про конфиг > Почти вся защита включена **по умолчанию**. В `config.toml` осознанно трогаете три вещи (`tls_domain`, `mask`, `fake_tls_only`). А **TCPMSS и nfqws — это уровень ОС**, они ставятся флагами `mtbuddy install`, а не в `config.toml`. ### Установка «под ключ» ```bash # Всё включено: 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` Большинство строк — уже дефолты; фиксируем ключевые явно. ```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. Чего НЕ делать > [!warning] Лимит 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-вариантами — в [[Zapret/mtproto/10-telemt-logs-dpi#Лимит SYN-ACK — помогает или нет|10-telemt-logs-dpi]]. - **Не раздавайте `dd`-ссылки** при активном DPI — это plain MTProto, палится сразу. - **Не меняйте `tls_domain`** после раздачи — он вшит в ссылки. - **Не дёргайте настройки под блокировкой** — в [[VLESS/dpi-tls-june-2026|сибирской схеме]] сам паттерн «поймал блок → тут же поменял» провоцирует расширенный блок. Лучше переждать или сменить узел. --- ## Часть 7. Честный потолок: почему MTProxy слабее REALITY Три структурных причины (подробно — [[VLESS/dpi-tls-june-2026|разбор DPI июнь-2026]]): 1. **Почерк клиента не контролируешь** — нет uTLS, JA3/JA4 Telegram фиксирован (Признак 1). 2. **CDN-фронтинг почти невозможен** — клиент идёт прямо на ваш `IP:port`, подсеть не спрятать (Признак 3). Частичный рычаг — IPv6-hopping и «чистый» провайдер ([[VPS/VPS|VPS]]). 3. **Нет mux** — залп коннектов сгладить нечем (Признак 4). Сам проект в `THREAT_MODEL.md` честно пишет: *«hardened transport tool, not a universal censorship-proof channel»* — закалённый инструмент, а не универсальная неуязвимость. > [!important] Почерк и SNI меняются только на клиенте > Новая детекция (июнь 2026) бьёт по связке «JA4 Telegram + один SNI + залп на > один ip:port». Сменить JA4 или ротировать SNI **серверный прокси не может** — их > задаёт клиент Telegram, и цензор видит их ещё до сервера. Почему так и что > тогда может сервер — в [[mtproxy/ja4-sni-client-side|Кто может менять JA4/SNI]]. > [!tip] Правильная стратегия > Держите **оба**: MTProxy — удобная «дверь» в Telegram для близких (ноль установки), VLESS+REALITY/XHTTP — основной обход для всего. Когда [[VLESS/dpi-tls-june-2026|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](https://github.com/sleep3r/mtproto.zig) - [[Zapret/mtproto/05-censorship|ТСПУ и обход цензуры для MTProto]] — полный каскад детекции - [[Zapret/mtproto/02-implementations|4 реализации MTProxy]] — telemt / mtg / … (без zig) - [[Zapret/mtproto/06-vs-vless|MTProxy vs VLESS]] - [[Zapret/mtproto/08-best-practices|Best practices: домен и ASN]] - [[VLESS/dpi-tls-june-2026|Сибирская схема: подсеть + фингерпринт + частота]] - [[DPI/dpi-analysis-pipeline|Воронка проверок DPI: от SYN до ML]] - [[VPS/VPS|Выбор VPS и подсети]] - [[Zapret/telegram calls|Звонки Telegram]] — через MTProxy не работают