Список MTProto-прокси для Телеграм я впервые открыл года три назад. Скопировал двадцать строк, вставил, подключил. Через час работало две. Через сутки не работало ни одной. С тех пор я перестал верить в списки как в решение и начал разбираться, откуда эти строки берутся и почему умирают так быстро.
Ниже то, что выяснилось за это время: как устроена строка подключения, почему автообновление каждые 12 часов не гарантирует ничего, сколько реально стоит держать свой узел и в какой момент проще взять нормальный каталог вроде 3seller.com/proxy, чем собирать пазл из чужих ссылок.
Публичный список обновляют боты, и проверяют они только TCP-порт
Схема типичная. Кто-то пишет скрипт, который раз в 12 часов собирает адреса из открытых источников и проверяет их. Проверка выглядит так: открылось TCP-соединение на порт, значит живой. Всё. Дальше строка попадает в файл, файл разъезжается по сотням чатов, и все дружно ловят бесконечное «соединение» вместо сообщений.
Открытый порт ничего не говорит о том, примет ли узел ваш secret. И хватит ли ему канала на пять тысяч человек. И не стоит ли там лимит в три соединения с одного IP. Я видел узлы, которые отдавали TCP-хендшейк бодро и умирали на первом же медиафайле в 20 МБ.
Ещё деталь. Половина таких адресов это чужие VPS, поставленные на пробу. Человек заплатил за месяц, поигрался, забыл. Через две недели машина выключена, а строка всё ещё гуляет по интернету. Запрос «прокси для телеграмм мтпрото список» выдаёт сотни страниц, и почти все предлагают один и тот же набор полумёртвых ссылок. Из трёхсот строк реально работает десяток, и то недолго.
В secret зашито больше, чем кажется
Строка подключения это не просто адрес и пароль. Secret здесь это 16 байт в hex, и первые два символа меняют всю механику соединения.
Префикс ee означает fake TLS. Прокси оборачивает старт соединения в TLS-хендшейк, и для сетевого оборудования снаружи это выглядит как обычный HTTPS. Отсюда два практических следствия: узлу нужен домен и валидный сертификат, а само соединение получает лишний RTT на установку TLS. В корпоративных сетях такой вариант заметно устойчивее голого MTProto.
Префикс dd это random padding. Прокси добавляет случайные байты к пакетам, чтобы размеры не выдавали структуру переписки. Никакой дополнительной инфраструктуры не нужно, зато совместимость с агрессивными шлюзами чуть хуже.
Голый 16-байтовый secret без префикса работает, но мобильные операторы чаще обрывают такие соединения. И вот тут вылезает главное: владелец публичного узла редко держит домен и сертификат. Значит, половина списка это голые секреты, которые в метро или на рабочем Wi-Fi просто не поднимутся.
Сам прокси содержимое не расшифровывает. Ключей чата у него нет, он видит только шифрованные пакеты и объём. Но IP, время подключения и примерный трафик владелец узла видит отлично. Об этом почему-то забывают, когда берут бесплатный сервер из чужого файла.
MTProto и SOCKS5 решают разные задачи
MTProto это протокол самого Телеграма. Прокси на его основе понимает структуру соединения, умеет держать мультиплексирование и нормально переживает переключение с Wi-Fi на LTE. Для мессенджера это лучший вариант по задержке и стабильности.
SOCKS5 работает ниже, на уровне TCP и UDP, и про Телеграм ничего не знает. Ему всё равно, что через него идёт: мессенджер, браузер или клиент для парсинга. Шифрование в этом случае целиком на стороне приложения. Отсюда простое правило: для Телеграма берём MTProto, для браузера и рабочих задач SOCKS5. Если нужен один узел на всё, ищем провайдера, который даёт оба протокола на одном аккаунте.
Кстати про UDP. SOCKS5 с поддержкой UDP нужен для звонков и части игровых сценариев. Многие дешёвые прокси UDP не пропускают, и человек удивляется, почему сообщения летают, а звонок в Телеграме не соединяется. Проверять это надо до покупки, а не после.
Перегруженный узел выглядит рабочим ровно до первого файла
Публичные прокси живут по принципу общей квартиры. Один IP, сотни пользователей, канал на гигабит в лучшем случае. Пока вы листаете текстовые чаты, всё прекрасно. Как только включается канал на 50 тысяч подписчиков или загрузка видео, скорость падает до 200 Кбит/с и остаётся там.
Второй слой проблемы, лимиты. Администратор узла ставит ограничение на количество соединений с одного IP, потому что иначе машина ляжет. В мобильной сети вы сидите за NAT вместе с сотней других абонентов, и часть лимита уже съедена чужими людьми. В обсуждениях на Reddit владельцы каналов описывают ровно эту классику: дома работает, в метро нет.
Третий слой, сессии. MTProto-прокси держит длинные соединения. Если узел перезагрузился или порвал сессию, Телеграм какое-то время думает, что всё хорошо, и сообщения висят в статусе «отправляется». Лечится только переподключением, а на публичном списке это лотерея каждый раз.
Задержка важнее скорости
Люди смотрят на мегабиты, а чувствуют миллисекунды. Для текстовой переписки 100 Мбит/с это избыток, там всё упирается в RTT. Установка соединения это несколько круговых задержек подряд, плюс TLS на fake TLS, плюс мобильная сеть с её нестабильным uplink.
Ориентиры по пингу, которые я считаю нормой: 20-40 мс узел рядом, 80-120 мс терпимо, всё что выше 200 мс начинает раздражать при наборе сообщений и заметно тормозит голосовые. Плашка с задержкой внизу экрана Телеграма это самый быстрый способ сравнить два узла между собой, не читая никаких обзоров.
Практический вывод простой. Один узел в Европе на команду из Новосибирска и Берлина это компромисс, который чувствуют обе стороны. Локаций должно быть минимум две, и переключаться между ними надо уметь за десять секунд.
Свой VPS под MTProto: считаем на салфетке
Минимальная конфигурация выглядит смешно: один vCPU, 512 МБ памяти, 10 ГБ диска, Ubuntu 22.04. Официальная реализация на Python поднимается за полчаса, mtg на Go за десять минут и жрёт меньше памяти. Дальше systemd-юнит, порт 443, secret, при желании домен и сертификат для fake TLS.
Деньги: 3-6 долларов в месяц за машину плюс доллар за домен. Время: 40-60 минут на первый раз, потом десять. Звучит как отличная идея, пока не начинаешь считать невидимые расходы.
Первый расход, обновления. Ядро, пакеты, перезапуск сервиса. Раз в месяц надо зайти и посмотреть, что там. Второй, ротация секрета. Если прокси используют пять человек и один ушёл, секрет надо менять, а значит рассылать новую ссылку всем остальным. Третий, IP. Один адрес на всех означает, что при проблемах у любого пользователя вы разбираетесь с этим в одиночку, ночью, по скриншотам.
Свой узел оправдан, когда пользователей до десяти, задачи предсказуемые и есть кому дежурить. Для команды в 50 человек арифметика ломается: нужен уже не один VPS, а пул с мониторингом и заменой на лету. Ровно этим и отличается каталог 3seller.com/proxy от домашней сборки: узел меняется у провайдера, а не у вас в три часа ночи.
Корпоративный узел решает вопрос белого IP и учёта
Отдельная история, когда прокси нужен не «мне для Телеграма», а компании. Здесь на первом месте статический адрес: партнёры и внутренние сервисы добавляют его в allowlist, и адрес не должен меняться каждые две недели.
Дальше идут вещи, о которых публичные списки не думают вообще. Учёт трафика по сотрудникам. Отдельный секрет на отдел, чтобы увольнение одного человека не превращалось в рассылку новых ссылок на всех. Логи подключений на своей стороне, чтобы понять, откуда пришла аномалия. И мониторинг: если узел отвалился, вы узнаёте об этом из алерта, а не из сообщения «у меня Телеграм не грузит».
Для распределённых команд добавляется география. Узел во Франкфурте даёт 30 мс для Берлина и 90 мс для Новосибирска. Если половина команды в Азии, один узел это компромисс, который чувствуют все. Нормальный каталог даёт выбор локации под каждого, и это не роскошь, а разница между «работает» и «работает терпимо».
Публичный Wi-Fi и один прокси на всю команду
В кафе и аэропортах Телеграм шифрует переписку сам, тут вопросов нет. Вопрос в метаданных и в том, как местный шлюз относится к вашим пакетам. Прокси с fake TLS выглядит для такого шлюза как обычный HTTPS, и шанс, что соединение доживёт до конца сессии, выше.
Отдельно про общий прокси. Когда пять человек сидят через один узел и один secret, любая проблема у одного становится проблемой всех. Плюс невозможно понять, чей трафик съел канал. Для небольшой команды это приемлемо на день-два, для постоянной работы нужны отдельные учётки или отдельные узлы.
Настройка в приложении: куда нажимать
В Телеграме на Android и iOS путь такой: Настройки, Данные и память, Прокси, Добавить прокси, выбрать MTProto, вбить сервер, порт и secret, сохранить. Если вам прислали готовую ссылку, достаточно нажать на неё: приложение само предложит подключиться, останется подтвердить.
На десктопе: Настройки, Продвинутые настройки, Тип соединения, Прокси. Логика та же, три поля. После сохранения внизу появится плашка с задержкой в миллисекундах, по ней удобно сравнивать узлы между собой.
WhatsApp своих настроек прокси не имеет. Работает через системный уровень: Android, настройки Wi-Fi, долгое нажатие на сеть, Изменить сеть, Дополнительные параметры, Прокси, Вручную, тип SOCKS5, хост и порт. iOS: Настройки, Wi-Fi, кнопка с буквой i рядом с сетью, Настройка прокси, Вручную. В обоих случаях прокси применяется к текущей сети, при переключении на мобильные данные трафик пойдёт напрямую.
Браузеры на десктопе обычно берут системные настройки прокси из ОС, отдельно настраивать нужно только если вы используете профили или портативную сборку. На Android системный прокси ставится там же, в настройках Wi-Fi, и действует на все приложения, которые его уважают.
Парсинг и рабочие задачи требуют другого типа прокси
MTProto хорош для мессенджера и плохо подходит для сбора данных. Для парсинга нужны HTTP и SOCKS5 пулы с ротацией, потому что там логика другая: тысяча коротких запросов с одного адреса выглядит подозрительно, и вас просто перестают пускать.
Рабочая схема выглядит так: пул адресов, ротация по времени или по количеству запросов, sticky-сессии там, где нужна авторизация, и отдельная гео-привязка под каждую задачу. Плюс лимиты на частоту, иначе даже хороший пул сожжётся за час. Такой сценарий закрывается тем же каталогом, только выбирать надо не MTProto, а SOCKS5 или HTTP с нужной локацией.
Ещё момент, который редко пишут в гайдах. В обсуждениях на Reddit парсеры снова и снова возвращаются к репутации подсети, и не зря. Адреса из дешёвых пулов часто уже пересидели в чужих банлистах. Проверять репутацию перед запуском задачи обязательно, иначе половина запросов уйдёт в мусор.
Пять критериев вместо «побольше строк в списке»
Когда я смотрю на каталог прокси, меня интересует не количество, а предсказуемость. Порядок такой:
- Аптайм и история замен. Если узел падает раз в сутки и его меняют молча, это не сервис.
- Локации и реальный пинг до них, а не «50 стран» в описании.
- Оба протокола, MTProto и SOCKS5, чтобы не держать два аккаунта под разные задачи.
- Лимиты: сколько устройств, какой канал, есть ли ограничение на одновременные сессии.
- Условия замены и поддержка, которая отвечает в рабочее время, а не через двое суток.
По этим пяти пунктам публичный список проваливается сразу по всем. Каталог прокси 3seller.com/proxy выигрывает не тем, что там «много прокси», а тем, что адрес, взятый сегодня, будет работать и через месяц, и у него есть владелец, которому можно написать.
Что делать дальше
Если Телеграм нужен для работы и переписка с клиентами не должна зависеть от настроения чужого VPS, начните с одного приватного узла под MTProto и одного SOCKS5 под браузер. Дальше по мере роста команды добавляйте локации и отдельные секреты. Каталог 3seller.com/proxy как раз под этот сценарий: выбрали локацию, взяли реквизиты, вставили в приложение, забыли про тему на полгода.
Списки бесплатных прокси не исчезнут, и иногда их хватает, чтобы дочитать чат в аэропорту. Просто не стоит строить на них рабочий процесс. Разница между «подключилось» и «работает» измеряется месяцами аптайма, и вот её бесплатный файл не даёт.