Половина разговоров про прокси в Telegram начинается одинаково. Человек сидит в коворкинге или в кафе, Telegram висит на "Connecting...", а через минуту прилетает сообщение от коллеги, которое должно было прийти двадцать минут назад. Дальше беседа быстро съезжает на "а какой протокол вообще выбрать".
И вот тут выясняется, что девять из десяти не понимают разницы между MTProto и SOCKS5, ставят первое, что попалось в чате, а потом жалуются, что голосовые не отправляются, а телефон греется как утюг. Давайте по-честному разберём, как устроен протокол прокси для Telegram, что там внутри и в каких случаях вам вообще не про прокси надо думать.
MTProto-прокси - это ретранслятор, а не VPN
Первое, что надо выбить из головы: MTProto-прокси не даёт вам "интернет через другую страну". Он вообще не про это.
MTProto - собственный протокол Telegram, на котором клиент общается с серверами. Прокси в этой схеме - лёгкий ретранслятор. Приложение отправляет пакеты в своём обфусцированном формате, ретранслятор перекладывает их дальше, на дата-центры Telegram. Всё. Никакого HTTP, никаких сайтов, никакого YouTube через этот канал не пойдёт, и это нормально.
Ключевой момент для безопасников и для параноиков: ретранслятор не видит содержимое переписки. Шифрование end-to-end остаётся на стороне клиента и сервера Telegram, прокси работает с уже зашифрованным потоком. Он знает ваш IP, время подключения и объём трафика. Текст сообщений - нет.
Второй момент, который многие недооценивают: MTProto-прокси говорит на собственном wire format Telegram. Обычный SOCKS5 так не умеет, он просто гоняет TCP-поток и понятия не имеет, что внутри. Из-за этого MTProto-трафик сложнее отличить от обычного сетевого шума, и именно поэтому он ведёт себя стабильнее там, где за трафиком внимательно смотрят.
SOCKS5, MTProto и HTTP: три разных инструмента, а не три скорости
Самая частая путаница. Люди сравнивают их как "быстрее-медленнее", хотя сравнивать надо по назначению.
SOCKS5 работает на уровне TCP-соединений и не знает, что внутри. Он универсален: через него пойдёт и Telegram, и браузер, и что угодно ещё. Минус ровно в этом. Прокси-сервер видит, куда вы подключаетесь, а трафик несёт в себе полноценный TLS handshake к серверам Telegram, который распознаётся по характерным признакам без особого труда.
MTProto-прокси знает только Telegram и ничего кроме Telegram. Он не умеет в произвольные соединения, зато умеет ровно то, что нужно, и делает это с минимальным оверхедом. На практике разница в задержке между аккуратно настроенным MTProto и SOCKS5 в том же дата-центре - десятки миллисекунд. А вот в стабильности на плохом мобильном интернете MTProto выигрывает заметно, потому что клиент быстрее переустанавливает соединение и меньше теряет на хендшейках.
HTTP-прокси в этой истории вообще сбоку. Он для веба, для Telegram не годится и упоминается только потому, что кто-то однажды увидел слово "proxy" в настройках и попробовал.
Fake TLS: почему соединение выглядит как обычный HTTPS
Самая интересная часть архитектуры. Fake TLS - режим, при котором прокси на входе имитирует обычный TLS handshake к какому-нибудь безобидному домену. В конфигах mtg это выглядит как домен-заглушка, часто берут что-то вроде www.google.com или www.microsoft.com.
Система глубокой инспекции пакетов на стороне сети видит знакомую последовательность байт: ClientHello, версия TLS, SNI с популярным доменом, дальше шифрованный поток. Отличить это от похода на обычный сайт по внешним признакам крайне сложно, потому что с точки зрения формата это и есть TLS.
Практическая ценность не в скрытности ради скрытности. В корпоративных сетях и гостевых Wi-Fi часто стоит железка, которая режет всё, что не похоже на стандартный веб-трафик. Fake TLS позволяет вашему корпоративному узлу работать в такой сети без переписок с IT-отделом и без исключений в правилах файрвола. Плюс он реально снижает количество ложных срабатываний на стороне провайдера.
Оговорюсь сразу: Fake TLS не шифрует ничего дополнительно. Шифрование и так есть, на уровне MTProto. Разница чисто в форме пакета, а не в содержимом.
Секрет в ссылке - это не пароль
Когда вы добавляете прокси, Telegram просит четыре вещи: сервер, порт, секрет и тип протокола. Секрет - самый непонятный пункт, и вокруг него больше всего мифов.
Секрет не является логином с паролем. Это параметр транспорта: 16 или 17 байт в hex-формате, которые говорят клиенту, как именно обфусцировать поток и какой режим использовать. Префиксы в секрете как раз кодируют режим: обычный, secure, Fake TLS с доменом внутри. Если секрет не совпадает с тем, что настроено на сервере, соединение просто не установится. Никакого "пустит без пароля" там нет и быть не может.
Отсюда простое следствие: секрет - расходник. Он не даёт доступа к вашему аккаунту, его утечка не означает взлом. Но если секрет утёк в публичный чат и по нему сидят тысячи людей, ваш узел ляжет от нагрузки. Поэтому на команду из двадцати человек делают отдельный узел и отдельный секрет, а не раздают один на всех.
Свой узел на VPS: минимальный набор
Если Telegram нужен стабильно и для работы, а не "раз в день проверить чат", свой узел - самый предсказуемый вариант. Разворачивается за полчаса, стоит как чашка кофе в месяц.
Набор такой: VPS с внешним IP, Docker, открытый порт и сам mtg. Образ nineseconds/mtg:2 - современный, поддерживает Fake TLS, активно обновляется сообществом. Требования смешные: PowerShell 5.1+ на Windows Server или обычный bash на Linux, лишнего софта не надо. Есть и другие реализации, но эта обкатана и предсказуема.
Отдельный момент, на который почти все забивают: берите под прокси отдельный IP, а не тот же, на котором висит ваш основной сервис. Если узел когда-нибудь попадёт в чей-то фильтр, вы потеряете только прокси, а не почту, сайт и всё остальное разом. Стоит это копейки, экономит нервы капитально.
Проверка после запуска - одна команда: Test-NetConnection по вашему IP и порту. Если TcpTestSucceeded: True, порт открыт снаружи и всё работает. Если False, идите смотреть файрвол и security group у хостера, в восьми случаях из десяти проблема там, а не в конфиге прокси.
В клиенте Telegram всё сводится к четырём полям
Настройка одинаковая на всех платформах, отличается только путь к экрану.
В мобильном приложении: Настройки, дальше Данные и память, дальше Прокси, дальше Добавить прокси, выбираете тип MTProto. На десктопе: Настройки, Продвинутые настройки, Тип подключения, Прокси. Дальше заполняете сервер, порт, секрет. Поле секрета появляется только после того, как выбран тип MTProto, в SOCKS5 его просто нет, и это многих ставит в тупик.
Ссылка вида tg://proxy с параметрами сервера, порта и секрета делает то же самое в один тап: Telegram сам предложит добавить настройки. Удобно для команды, когда надо раскатать конфиг на десять человек без пересылки скриншотов и инструкций голосом.
И маленькая деталь, которая экономит время: после добавления прокси проверьте, что переключатель включён. Звучит смешно, но я видел это раз пять точно.
Скорость зависит не от спидтеста
Люди меряют скорость прокси спидтестом и удивляются, что он ничего не показывает. Логично: MTProto-прокси не пропускает веб-трафик, мерить нечего.
Реальная метрика - задержка до дата-центров Telegram и стабильность. Прокси в Германии с пингом 40 мс до серверов Telegram будет работать лучше, чем прокси в соседнем доме. У второго пинг 15 мс, но канал перегружен на пятьсот человек. География важнее близости, и это контринтуитивно почти для всех.
Второй фактор - сколько людей сидит на узле. Публичные бесплатные прокси живут ровно до момента, когда о них узнают. Один узел на десять тысяч человек - это гарантированные обрывы в вечерние часы, когда все одновременно решили проверить чаты.
Третий - тип сети. На мобильном интернете с постоянной сменой сот MTProto держится лучше SOCKS5 за счёт более быстрого переподключения. На стабильном домашнем Wi-Fi разница почти незаметна, и спорить о ней смысла нет.
Готовые узлы выбирают по четырём параметрам
Свой VPS - не для всех. Кому-то нужен просто рабочий канал на сегодня, без Docker и SSH. Тут на сцену выходит каталог прокси: узлы разложены по протоколам, странам и назначению, и не надо собирать конфиг из обрывков в чатах.
Смотреть надо на протокол (для Telegram нужен именно MTProto, а не SOCKS5 и не HTTP), на географию (близость к дата-центрам Telegram важнее близости к вам), на лимиты по трафику и числу устройств и на поддержку Fake TLS. Последнее критично, если вы работаете из корпоративной сети или из отелей, где фильтруют всё нестандартное.
Отдельно про бесплатные публичные списки. Они существуют, обновляются ботом каждые двенадцать часов, кто-то их сканирует и проверяет перед публикацией. В обсуждениях на Reddit эту тему поднимают регулярно: работает, но только иногда. Предсказуемо - нет. Публичный узел с открытым секретом живёт под нагрузкой в сотни раз выше расчётной. Он отваливается ровно в тот момент, когда вам нужно срочно отправить файл. Для "проверить чат раз в неделю" сойдёт. Для работы - нет. Разница в цене между случайным узлом и нормальным каналом измеряется сотнями рублей, а нервы стоят дороже.
Для корпоративного сценария удобнее брать в каталоге прокси сразу два узла в разных странах: основной и резервный. Переключение между ними занимает десять секунд прямо в клиенте, и когда основной ложится, вы даже не заметите.
Несколько узлов: как это делается на практике
Один узел - одна точка отказа. Если канал к нему просел или хостер решил провести профилактику в три часа дня, вы сидите без связи. Поэтому в схемах, где Telegram критичен, узлов держат минимум два.
Работает это просто. В клиенте Telegram можно хранить несколько профилей прокси и переключаться между ними вручную, а на десктопе ещё и назначать разные профили под разные задачи. Основной узел - ближе к дата-центрам, резервный - в другой стране и у другого хостера, чтобы авария у одного провайдера не положила оба.
Нагрузку между узлами в пределах команды распределяют по людям, а не автоматически. Автоматической балансировки в MTProto-прокси нет и не будет: это не то, что протокол умеет. Зато можно раскидать отделы по разным секретам и спокойно смотреть, кто сколько ест трафика.
Что видит владелец узла и чего он не видит
Полезно понимать, кому вы доверяете канал. Владелец MTProto-прокси видит IP-адреса подключившихся, время сессий и объёмы трафика. Этого достаточно, чтобы построить картину "кто когда онлайн", и недостаточно, чтобы прочитать переписку.
Содержимое сообщений остаётся зашифрованным между клиентом и серверами Telegram. Даже если владелец узла очень захочет посмотреть, у него на руках только поток обфусцированных байт. Именно поэтому корпоративные узлы спокойно ставят внутри компаний, не нарушая политик безопасности.
Хороший узел при этом не хранит логи подключений дольше, чем нужно для отладки. Нормальная практика - выключенное логирование или хранение в пределах нескольких часов. Если вам обещают "полную приватность" и при этом просят регистрацию с телефоном, это повод задуматься.
Ошибки, которые я видел чаще всего
Первая и главная: путать MTProto-прокси с VPN. Человек ставит прокси, открывает браузер, видит, что IP не поменялся, и делает вывод "прокси не работает". Работает. Просто он не для этого.
Вторая: один секрет на всю компанию. Через месяц узел лежит, потому что по нему ходит половина чата, а виноват назначен "плохой хостер".
Третья: брать VPS в стране, где до серверов Telegram двести миллисекунд, потому что там дешевле. Экономия сто рублей в месяц превращается в секундные задержки на каждое сообщение и раздражение всей команды.
Четвёртая: забыть про отдельный IP. Узел попадает в чей-то список, и вместе с ним перестаёт открываться основной сайт на том же адресе.
Пятая: не проверить порт после установки. Прокси запущен, в логах красиво, а снаружи порт закрыт файрволом хостера. Классика жанра, случается у всех хотя бы раз.
Шестая: гоняться за бесплатными списками ради экономии трёхсот рублей и терять по часу в неделю на переподключения. Я через это проходил, больше не хочу.
Что делать дальше
Если сводить к одному практическому шагу, начните с вопроса "что мне нужно". Разово проверить чат - берите живой узел из каталога прокси и не усложняйте. Работать каждый день - поднимите свой узел на отдельном IP с mtg и Fake TLS, потратьте полчаса один раз. Команда из десяти человек - один нормальный узел плюс запасной в другой стране.
Сам протокол тут вторичен. MTProto выигрывает у SOCKS5 не потому, что он новее, а потому что он ровно про Telegram и ничего лишнего не тащит. Всё остальное - вопрос того, насколько аккуратно вы этот узел настроили и не забыли ли проверить порт.