Вчера приятель прислал скрин: три пустых поля в Telegram и красная плашка «не удалось подключиться». Сервер, порт, секрет. Сорок минут перебора вариантов из чата, десяток ключей - и ни одного рабочего. Проблема почти никогда не в приложении. Проблема в том, что человек не понимает, что именно вставляет в эти три поля.
Ниже - как устроен MTProto-прокси, откуда берутся сервер и ключ, почему один secret начинается с dd, а другой с ee, и как выбрать узел, который не умрёт через сутки. Плюс критерии, по которым я отсеиваю каталоги.
MTProto-прокси это не прокси в привычном смысле
Обычный SOCKS5 гоняет TCP-пакеты из точки А в точку Б. Ему всё равно, что внутри: Telegram, торрент, SSH. MTProto-прокси работает иначе: он разговаривает с клиентом на транспортном слое самого мессенджера и уже оттуда открывает соединение с дата-центром Telegram.
Из этого растут три практические вещи. Логин и пароль не нужны, авторизация зашита в сам секрет. На проводе трафик выглядит как поток байтов без явных сигнатур: обфускация MTProto добавляет случайное заполнение пакетов. И скорость выше, чем через SOCKS5, на том же канале. Проверял на одном VPS в Амстердаме: медиана отклика на отправку сообщения отличалась на 15-20%, загрузка медиа - до 30%.
Для мессенджера имеет смысл брать MTProto, а не универсальный SOCKS5. SOCKS5 держат запасным вариантом: когда MTProto-узел недоступен или конкретный клиент его не поддерживает.
Сервер, порт и ключ: что означает каждое поле
Сервер - адрес узла. Либо IP, либо доменное имя. Домен удобнее: владелец может переехать на другой IP, а запись останется прежней. Если в каталоге указан хост, а не цифры, это обычно хороший знак.
Второе поле - номер TCP-порта на узле. Диапазон 1-65535. Чаще всего в каталогах встречается 443: под ним обычно живёт HTTPS, и на входе в офисную сеть к такому соединению меньше вопросов.
Секрет (secret) - 16 байт в hex-записи, то есть 32 символа. Это ключ, которым клиент и сервер договариваются о параметрах соединения. Криптографически секретного в нём ничего нет, скорее метка и соль одновременно. Утёк секрет в публичный список - узел начал принимать чужих клиентов, и владелец его закрывает.
Почему один secret начинается с dd, а другой с ee
Голый секрет - 32 hex-символа. В каталогах вы постоянно видите 34 или больше: первые два символа это префикс режима.
- Без префикса: обычный режим, клиент отправляет заголовок с рандомным заполнением.
- dd: тот же режим с принудительным random padding на каждый пакет. Встречается чаще всего.
- ee: fake TLS. Клиент упаковывает соединение в TLS ClientHello и указывает домен, под который маскируется трафик. После префикса идёт hex-строка домена.
Fake TLS придумали не для красоты. В корпоративных сетях и публичных Wi-Fi на входе часто стоит DPI, который смотрит на структуру соединения: обычный MTProto-поток там выглядит подозрительно, а TLS-хендшейк к нормальному домену вопросов не вызывает. Для домашнего интернета разницы почти нет, для офисной сети она может быть решающей.
Практический вывод: если узел с ee-секретом, домен внутри секрета должен быть живым и отдавать валидный сертификат. Иначе часть клиентов отвалится на этапе хендшейка. Нормальные каталоги это проверяют, самодельные списки из чатов - почти никогда.
Куда нажимать в приложении
Мобильный Telegram, Android и iOS: три полоски слева вверху, дальше Настройки, Данные и память, листаем вниз до раздела Прокси. Включаем тумблер, жмём «Добавить прокси», выбираем MTProto. Три поля: сервер, порт, секрет. Заполнили, сохранили. Зелёный индикатор напротив записи означает, что соединение установлено.
Десктоп: Настройки, Продвинутые настройки, Тип подключения, Прокси. Те же три поля и кнопка сохранения.
Пара деталей, которые экономят время. Секрет вставляйте без пробелов по краям, буфер обмена любит их цеплять. Префикс не обрезайте. И не путайте формы: SOCKS5 просит адрес и порт, MTProto - все три поля. Половина «нерабочих» ключей из чатов это ключи, вставленные в SOCKS5-форму. На Reddit в ветках про MTProto эта же ошибка всплывает регулярно, и люди неделями ищут проблему в узле, а не в форме.
Некоторые каталоги отдают готовую кнопку, которая открывает приложение с уже заполненными полями. Удобно, но проверять всё равно стоит: живой ли узел прямо сейчас, за вас никто не посмотрит.
Свой узел или готовый: считаем на пальцах
Свой MTProto-прокси на VPS поднимается за 10-15 минут. Нужен сервер (от 2-3 долларов в месяц у нормальных хостеров), желательно домен для fake TLS и понимание, что за узлом надо следить. Плюс: вы контролируете, кто через него ходит, и он не попадёт в публичные списки.
Минусы конкретные. Один узел - одна точка отказа. У IP дешёвых хостеров часто испорченная репутация, и узел на нём может не открываться именно там, где нужнее всего. Плюс обновления, мониторинг, замена при переезде дата-центра. Для команды из 5-10 человек это оправдано, для одного человека с телефоном - обычно нет.
Готовый каталог снимает вопрос доступа к рабочим узлам, но добавляет вопрос доверия к оператору. Что именно смотреть - ниже.
Публичные списки умирают за сутки, и это норма
Любой узел, попавший в открытый список, живёт в среднем от нескольких часов до трёх дней. Причины механические. Перегрузка: один MTProto-процесс на слабом VPS не держит несколько тысяч одновременных соединений, канал упирается в полку, отклик растёт до секунд. Репутация адреса: IP, с которого идёт слишком много соединений, быстро попадает в фильтры. И владелец сам закрывает узел, когда видит чужие подключения.
Есть вторая проблема, менее очевидная. MTProto-прокси терминирует TCP-соединение на себе. Оператор узла видит ваш IP, время подключения, объём трафика и то, к какому дата-центру вы ходите. Содержимое сообщений он не видит: шифрование живёт между клиентом и дата-центром Telegram. Но метаданных хватает, чтобы построить паттерн активности. Отдавать их случайному человеку из чата, который собрал список за вечер, я бы не стал.
Что смотреть при выборе каталога прокси
Четыре вещи, строго в таком порядке.
Актуальность. Дата последней проверки должна быть свежей, в идеале список обновляется раз в сутки или чаще. Каталог, где висит «проверено 12 марта», а на дворе июнь, бесполезен по определению.
Оба протокола. MTProto для мессенджера, SOCKS5 как универсальный запасной вариант для браузера и парсеров. Если в каталоге только MTProto, при проблемах с одним узлом вы останетесь ни с чем.
География и выбор узла под задачу. Для звонков и медиа нужен низкий пинг до вашего города, для фоновой работы бота это не критично, зато критична стабильность. Каталог без выбора страны и города отметаю сразу.
Прозрачность. Понятно, кто держит узлы, есть ли ограничения по трафику, что с логами. Размытое «мы лучшие» без деталей - красный флаг.
Под эти критерии ложится каталог прокси 3seller: MTProto и SOCKS5, фильтры по стране, сервер, порт и ключ показаны в открытом виде, а не спрятаны в картинке. Для команд с несколькими задачами (мессенджер плюс сбор данных) удобно, что оба типа узлов в одном месте.
Латентность: почему один узел летает, а другой еле дышит
MTProto-прокси это релей. Данные он не хранит, он перекладывает пакеты между вами и дата-центром Telegram. Задержка складывается из двух плеч: ваш город до узла плюс узел до дата-центра. Дата-центры Telegram стоят в Амстердаме, Сингапуре, Майами и ещё нескольких локациях.
Отсюда правило: узел в Германии или Нидерландах для пользователя из Москвы даст 30-50 мс, узел в Сингапуре - 150-200 мс. На переписке разницу не почувствуете, на голосовых и кружках уже да. Комфортная граница около 100 мс, после 250 мс начинаются заметные задержки при наборе текста.
Второй фактор - настройка самого узла. Владельцы, которые просто запустили контейнер по инструкции, получают деградацию под нагрузкой: процесс упирается в лимит открытых файлов, TCP-буферы маленькие, нет TCP_NODELAY. Узел с правильным тюнингом на том же железе держит в 3-4 раза больше соединений. Снаружи это видно только по поведению, поэтому нормальный каталог не держит в списке узлы, которые отваливаются под нагрузкой.
Для парсинга и нескольких аккаунтов одного узла мало. Нужна ротация: несколько MTProto или SOCKS5 узлов в разных подсетях, переключение по таймауту или по количеству запросов. Один узел на десять параллельных сессий - гарантированные обрывы.
Как проверить узел за две минуты
Зелёный индикатор означает только то, что TCP-соединение установилось. Про качество он не говорит ничего. Проверяю так.
Отправляю сообщение себе в «Избранное» и смотрю на задержку. До 500 мс - норма, больше секунды - узел уже под нагрузкой. Дальше файл на 10-20 МБ: если скорость падает ниже 1 МБ/с при нормальном канале, узел перегружен или канал у него узкий. Потом короткий звонок на 30 секунд, здесь слышно всё: провалы, эхо, задержку ответа.
В настройках прокси Telegram показывает счётчик переданного трафика. Растёт рывками, а не ровно - у узла проблемы с буферами. Нулевой прирост при активной переписке означает, что клиент давно переподключился на резервный вариант или молча висит без соединения.
Корпоративный сценарий: один узел на команду
Когда прокси нужен отделу из 15-20 сотрудников, логика меняется. Имеет смысл поднять собственный узел на VPS в европейской локации и выдавать секрет через внутреннюю базу, а не рассылкой в чат. Свой узел на команду стоит те же 3-5 долларов в месяц и снимает вопрос доверия к оператору полностью.
Обязательный минимум: второй узел в другой подсети как резерв, мониторинг доступности раз в минуту и лимит соединений на сотрудника. Без лимита один человек с фоновой синхронизацией десяти каналов съест канал у всего отдела. По опыту, 15 человек с обычной перепиской и периодическими звонками укладываются в 200-300 ГБ трафика в месяц.
Если своего админа нет, проще взять готовые узлы из каталога и раздать команде два-три варианта на выбор. Ротация вручную, зато без DevOps.
Что видит прокси, а что нет
Разложу по слоям: содержимое, метаданные, DNS.
Содержимое сообщений, медиа и звонки шифруются на уровне MTProto между вашим клиентом и серверами Telegram. Прокси-узел в этой цепочке не участник, ключей у него нет. Даже если владелец захочет, переписку он не прочитает.
Метаданные видит полностью: ваш IP, время сессии, объём трафика в обе стороны, номер дата-центра. Этого достаточно, чтобы построить профиль активности, но недостаточно, чтобы прочитать текст.
DNS-запросы зависят от режима. При обычном MTProto домен резолвится на вашем устройстве. При fake TLS имя домена зашито в секрет, и резолв идёт иначе.
Расклад такой: для содержимого прокси безопасен, по метаданным - не анонимен. Если задача не светить домашний адрес перед конкретным сервисом, прокси её решает. Если задача полная анонимность, MTProto-прокси для неё не предназначен.
Пять ошибок, которые я вижу чаще всего
Пробел в секрете. Копируете из каталога, а там перенос строки. Telegram молча не подключается, никакой диагностики.
Обрезанный префикс. Секрет с ee начинается с двух символов режима. Без них клиент попытается работать в обычном режиме и упадёт на хендшейке. Копируйте строку целиком.
Чужой порт. В каталоге рядом с узлом указан конкретный порт. Порт от другого узла не заработает, даже если хост совпадает.
Перепутанный протокол. SOCKS5-узел вставлен в MTProto-форму. Поля похожи, смысл разный.
Мёртвый узел. Список обновили неделю назад, узел уже закрыт. Лечится только выбором каталога с частой проверкой, например через 3seller.
Короткий чек-лист перед тем, как вставлять ключ
Узел из свежего каталога, а не из чата. География совпадает с вашей задачей. Секрет скопирован целиком, с префиксом, без пробелов. Протокол выбран MTProto, не SOCKS5. После сохранения индикатор зелёный, и тестовое сообщение уходит меньше чем за секунду.
Если хотя бы один пункт не сходится, не тратьте время на повторные попытки. Меняйте узел.
Прокси это инфраструктура, а не волшебная кнопка. Один узел прослужит долго только в одном случае: если он ваш и вы за ним следите. В остальных сценариях держите под рукой каталог 3seller, где за минуту можно взять новый сервер с портом и ключом и не начинать поиск заново.