Половина людей, которым срочно понадобился прокси для Telegram, начинает с GitHub. Логика железная: открытый код, звёздочки, сотня форков, инструкция в README. Я через это проходил. Открывал лог автообновляемого списка: из тридцати узлов живыми остались четыре, сообщение уходило с третьей попытки.
Ниже - три разные вещи, которые называют одинаково: «прокси для телеграмм гит хаб». Они не взаимозаменяемы. Путать их дорого - по времени и по нервам.
На GitHub по теме Telegram живут три разные штуки
Первая - исходники серверной части MTProto-прокси, которые Telegram выложила сама. Это код сервера, а не список готовых узлов. Ставится на свой VPS, обычно через Docker, документация лежит рядом. Смысл - поднять собственный узел и не зависеть от чужого админа: тот в любой момент выключит сервер или начнёт вставлять рекламу в твой трафик.
Вторая - локальные обёртки. Небольшие приложения поднимают прокси на твоей машине и гонят трафик мессенджера через WebSocket. С Telegram Desktop работает из коробки, данные остаются в том же шифрованном виде, сторонние серверы не нужны. Выручает вечером, когда провайдер режет скорость к дата-центрам и сообщения ползут.
Третья - автообновляемые списки бесплатных узлов. Бот раз в 12 часов сканирует публичные прокси, проверяет и выкладывает текстовый файл, где каждая строка - ссылка стандартного формата. Открываешь на телефоне, Telegram сам предлагает подключиться. Удобно, быстро, и именно здесь начинаются проблемы.
Первые две категории - про архитектуру и контроль. Третья - про лотерею с неплохими шансами на проигрыш.
Что делает MTProto-прокси и почему его нельзя путать с SOCKS5
Внутри MTProto-прокси есть секрет - 16 байт, которые принято записывать hex-строкой. Клиент и сервер договариваются по этому секрету, дальше трафик идёт в зашифрованном виде. Сам прокси-сервер содержимое не читает: видит поток байтов и перекладывает его в нужный дата-центр. Дата-центров у Telegram пять, клиент сам выбирает, к какому идти.
Деталь, которую постоянно упускают: MTProto-прокси работает только внутри мессенджера. Браузер через него не пойдёт, парсер на Python не пойдёт, WhatsApp тоже. В официальной документации Telegram про это сказано прямо: это часть протокола мессенджера, а не универсальный сетевой шлюз. Люди покупают такой прокси, а потом удивляются, что «интернет не работает». Работает, просто не для того, что они хотели.
Отдельный слой - 443 порт и TLS. Снаружи соединение выглядит как обычный HTTPS, поэтому в сетях, где открыты только стандартные веб-порты, оно проходит без сюрпризов. Для корпоративных сетей и публичного Wi-Fi в кафе это критично.
SOCKS5 - другая история. Он проксирует TCP целиком, годится для ботов, парсеров, браузера, десктопных клиентов. Задержка у нормального SOCKS5 в Европе - 40-70 мс. У MTProto-узла из бесплатного списка легко 300 и выше. Это не одно и то же, и выбирать надо под задачу.
Локальный прокси на WebSocket: пошагово, куда нажимать
Сценарий простой: Windows или macOS, Telegram Desktop, хочется ускорить загрузку каналов. Ставишь локальное приложение, оно поднимается в трее.
- В Telegram открываешь Настройки, дальше Продвинутые настройки, дальше Тип подключения, дальше Прокси.
- Добавляешь новое подключение: тип MTProto.
- Сервер - локальный адрес из настроек приложения, порт - тот, что указан там же, секрет - из логов или окна настроек.
- Сохраняешь и подключаешься.
Если не подхватилось автоматически, в трее есть пункт «Скопировать ссылку». Кидаешь её себе в Избранное, открываешь в Telegram, жмёшь - клиент сам подставит параметры. Экономит минут десять, когда руки устали перебивать hex-строку вручную.
Что даёт на практике: трафик идёт по WebSocket, соединение стабильнее на слабых сетях, медиа грузится бодрее. Чего не даёт: если провайдер режет всю сеть целиком, локальный прокси не спасёт. Нужен внешний узел за пределами этой сети.
Свой узел на VPS: что понадобится и где узкое место
Нужен VPS с Docker и свободным 443 портом. Провайдер, у которого берёшь машину, не должен сам резать соединения к дата-центрам - иначе затея бессмысленна. Настройка занимает минут двадцать, если идти по инструкции из репозитория и не изобретать велосипед.
В админке видно статистику: сколько серверов готово, сколько активно, сколько пользователей и соединений, какой максимум вытягивает канал. Создатели узлов монетизируют это рекламным каналом - Telegram такую возможность предусмотрел официально.
Узкое место - не установка, а эксплуатация. Один сервер на 200-300 активных пользователей, и канал упирается. Дальше либо апгрейд железки, либо второй узел, либо балансировка. Плюс мониторинг: упавший в три ночи прокси сам себя не поднимет. Если через него сидит команда - это инцидент, а не мелочь.
Почему бесплатные списки с GitHub не годятся для работы
Главная проблема - время. Обновление раз в 12 часов означает, что половина строк мертва к моменту, когда ты открыл файл. Я прогнал такой список через простой скрипт: из ста строк откликнулись 34, из них с задержкой ниже 200 мс - семь. Семь из ста.
Вторая проблема - владелец узла. Он видит твой IP, время подключения, объём трафика и то, к каким дата-центрам ты ходишь. Содержимое не читает, шифрование на месте, но метаданные целиком его. У бесплатных узлов это обычно люди, которые собирают базу и потом что-то с ней делают. Иногда просто продают рекламу в канал, иногда интереснее.
Третья - предсказуемость. Нужен узел в Германии под конкретную задачу, а в списке есть Нидерланды и Финляндия, и то не факт. Нужна стабильность 24/7, а узел живёт три дня, потому что админ не оплатил хостинг. Нужен один IP на аккаунт, а он меняется каждые 12 часов вместе с файлом - через неделю аккаунт улетает в ограничения.
Четвёртая, самая обидная. Ты не знаешь, что там за машина. Может, VPS в нормальном дата-центре, а может - дешёвый сервер, с которого месяц идёт спам и весь диапазон лежит в чёрных списках. Telegram такие адреса прибивает быстро.
Где прокси для Telegram реально берут те, кто работает с ним каждый день
Прокси - это инфраструктура, а не строчка в текстовом файле. У неё есть цена, SLA и человек, который отвечает за то, что узел жив.
Я беру в каталоге прокси 3seller уже второй год, и там закрыты все три категории сразу. Резидентские - под аккаунты и парсинг каналов: каждый аккаунт сидит на своём стабильном IP и не пересекается с соседом. Мобильные - когда нужен адрес, которому доверяют больше всего: операторский пул, ротация, минимум подозрений. Серверные IPv4 и IPv6 - под корпоративные узлы, ботов и фоновые задачи, где важна скорость, а не максимальная анонимность.
Фильтр по странам и городам работает как надо: нужна Германия - берёшь Германию, а не «что-то европейское, авось прокатит». Сроки от суток, оплата обычная, без танцев с криптой, если не хочется. И главное - если узел лёг, ты пишешь в поддержку, а не ищешь новый файл в чужом репозитории.
Для тех, кто держит несколько Telegram-аккаунтов одновременно, это принципиальная разница. Один аккаунт на публичном Wi-Fi - хватит и бесплатного узла. Десять аккаунтов на парсинг - только пул с ротацией, иначе половина уйдёт в бан за неделю.
Сценарии, где важен тип прокси, а не сам факт наличия
Один аккаунт, ноутбук, публичный Wi-Fi в кафе. Хватит серверного MTProto-узла или локального прокси на WebSocket. Задача - чтобы трафик шёл стабильно и не приходилось перелогиниваться.
Парсинг каналов, сбор статистики, работа с большим числом чатов. Нужны резидентские прокси с ротацией и лимитом на каждый аккаунт. MTProto здесь не подойдёт вообще: парсер ходит по API, а не через клиент мессенджера, ему нужен SOCKS5 или HTTP.
Команда из пяти человек, корпоративная сеть с фильтрацией на уровне шлюза. Логичнее поднять свой узел на VPS и раздать сотрудникам один секрет. Плюс - админ один и это ты. Минус - дежурить по ночам тоже тебе.
WhatsApp и браузер. MTProto мимо, только SOCKS5 или HTTP. Для новичков неочевидно, но факт: протокол Telegram живёт внутри Telegram и никуда больше не пускает.
Чек-лист перед тем, как платить
- Задержка до узла. Норма для Европы - до 80 мс. Выше 150 будет заметно на медиа и звонках.
- Тип. MTProto - для мессенджера, SOCKS5 и HTTP - для ботов, парсеров и браузера. Не наоборот.
- Стабильность IP. Если адрес меняется каждые несколько часов, для аккаунтов это плохо.
- Гео. Смотри не «Европа», а конкретную страну и город: от этого зависит, к какому дата-центру пойдёт соединение.
- Лимит соединений и трафика. У дешёвых пулов он есть, и упираешься ты в него неожиданно.
- Поддержка. Проверяется одним вопросом до оплаты. Отвечают сутки - дальше будет хуже.
Где чаще всего спотыкаются при настройке
Первое - путают тип подключения. Выбирают SOCKS5, вставляют секрет от MTProto и получают тишину. Второе - секрет скопирован с пробелом или переносом строки в конце, и клиент молча не подключается. Третье - ссылку открывают в браузере вместо Telegram, а она предназначена только для мессенджера. Четвёртое - порт 443 на сервере уже занят веб-сервером, прокси не стартует, хотя все шаги выполнены.
Из личного: держите под рукой два узла, а не один. Переключение в настройках занимает секунды. Поиск нового прокси в момент, когда нужно срочно отправить файл, - отдельный вид боли.
GitHub полезен, чтобы понять, как всё устроено внутри. Для этого его и читают. Но когда нужен предсказуемый результат - соединение, которое не отвалится через час, - идите в каталог прокси 3seller, выбирайте страну и тип, платите и работайте. Инфраструктура стоит денег, и это самая дешёвая часть вашего проекта.