MTProto-прокси, релей и VLESS+Reality: три грабли и вывод, что виноват был не DPI
28 августа 2026 года на Хабре опубликован разбор одного частного случая: автор под ником siestacloud поднимал MTProto-прокси для Telegram на сервере в России и получил картину «работает, но еле-еле». Ценность текста не в итоговой схеме, а в том, что автор довёл историю до конца и назвал настоящую причину — она оказалась не той, на которую он потратил основную часть работы.
Что не сработало и почему
Исходный симптом автор описывает так: прокси «работает, но еле-еле: то подключается, то нет, на мобильном интернете почти всегда фейл». Первой гипотезой была блокировка адресов Telegram, и первым решением — прозрачный TCP-релей на российском сервере: HAProxy либо перенаправление средствами iptables.
Результата это не дало, и объяснение в тексте звучит так: «если DPI-система провайдера умеет распознавать сигнатуру самого MTProto/fake-TLS протокола, то ей совершенно не важно, куда в итоге идёт этот трафик». Смысл претензии в том, что релей меняет маршрут, но не меняет то, как выглядит сам поток на проводе. Вторая попытка — обычный SOCKS5-туннель — по описанию автора оказалась «еще хуже, чем relay»: это тоже незашифрованный TCP-туннель без маскировки, и внутри него узнаваемая последовательность остаётся такой же узнаваемой.
Рабочей у автора оказалась схема с вложением: клиент идёт на mtg на российском сервере, оттуда через локальный SOCKS5 в клиент Xray с VLESS+Reality, дальше на зарубежный сервер Xray и уже оттуда в Telegram. Идея в том, что наружу в этом случае выходит настоящий TLS-хендшейк с настоящим сайтом, а не имитация.
Три грабли, на которых схема не заводится
Первая — параметр flow со значением xtls-rprx-vision, который в инструкциях по VLESS указывают почти всегда. С не-TLS нагрузкой он ломает соединение: по описанию автора, «Vision пытается распарсить эти байты как TLS-записи, не находит ожидаемой структуры — и обрывает соединение». Внутри туннеля идёт MTProto, то есть произвольный бинарный поток, и поле flow приходится убирать.
Вторая — задержка на установку соединения. Telegram открывает много коротких параллельных TCP-соединений, и каждому из них при такой схеме требуется полный хендшейк Reality; автор оценивает его в 700–900 мс, а клиент, по его наблюдению, отваливается по таймауту раньше. Лечится мультиплексированием: в исходящем VLESS включается mux с «concurrency»: 32, после чего новые соединения переиспользуют уже поднятый канал.
Третья — выбор семейства адресов: в конфигурации mtg автор выставляет prefer-ip = "only-ipv4". Все три пункта относятся к обвязке, а не к самой идее вложенного туннеля, и именно из-за них схема выглядит нерабочей у тех, кто собирает её по общим руководствам.
Виновником оказался не DPI, а хостер
Главное в этом разборе — концовка. Собранная конфигурация, по словам автора, заработала «идеально сразу, без единой ошибки в логах» только после переезда на сервер другого провайдера. Вывод он формулирует сам: «проблема была в сетевой политике конкретного хостинг-провайдера первого RU-сервера», а рекомендация звучит как «проверяйте гипотезу на РАЗНЫХ провайдерах».
Из этого следует осторожность в чтении первой части текста. Утверждение о том, что DPI узнаёт сигнатуру MTProto и fake-TLS на любом релее, автор выводит из симптомов, а не из перехваченного дампа с разбором сигнатуры; собственная же концовка эту гипотезу заметно ослабляет — если бы дело было в DPI на стороне оператора связи, смена хостера в той же стране помогла бы не так уверенно. Честнее читать текст как две отдельные вещи: подтверждённый набор граблей в настройке и неподтверждённое объяснение исходной поломки.
Практический остаток для читателя при этом не исчезает, а становится шире. Прежде чем перестраивать архитектуру доступа, стоит проверить простую и дешёвую версию: поведение того же самого конфига на другой площадке. Дальше проверяются параметры обвязки, и только потом — предположение о фильтрации на пути. Порядок обратный привычному, и в разобранном случае он сэкономил бы основную часть работы.
Источник: Хабр, «От HAProxy до VLESS+Reality: все грабли одного MTProto-прокси» (siestacloud, 28.08.2026)