Открываете GitHub, вбиваете в поиск «telegram proxy list», находите репозиторий с тремя тысячами звёзд, копируете пару строк, вставляете в Telegram. Работает. Через два дня половина узлов молчит, через неделю не отвечает ни один. Я проходил этот путь трижды, пока не сел разбираться, как эта кухня устроена внутри.
Дальше без магии. Разберу, что реально лежит в гитовых списках, чем MTProto отличается от SOCKS5 на уровне архитектуры, куда нажимать в приложении. И в какой момент дешевле взять нормальный узел, чем третий вечер подряд искать живой.
Почему все идут на GitHub за прокси
Причина банальная: там лежит бесплатно и выглядит солидно. README на английском, бейджи со статусом, автообновление раз в час, звёзды. Психологически это воспринимается как инфраструктура, хотя по факту это свалка.
Второй мотив - привычка. Разработчик ищет решение проблемы там, где привык искать код. А прокси для Telegram это не код, это сервис. Разница примерно как между рецептом в интернете и походом в ресторан: рецепт бесплатный, но продукты, плита и время всё равно ваши.
Третий мотив, о котором редко говорят вслух: бесплатное не жалко ломать. Список упал - взял следующий. Пока однажды не выясняется, что рабочий аккаунт с клиентами висел именно на том узле, который вчера сменил хозяина.
Что на самом деле лежит в репозиториях со звёздами
В девяти случаях из десяти это парсер. Бот или скрипт раз в N минут обходит публичные источники, собирает узлы, проверяет TCP-коннект и коммитит результат в файл. Проверка обычно ограничивается тем, что порт открылся. Работает ли через этот узел сам Telegram, никто не смотрит.
Отсюда цифры с моих замеров: из списка в тысячу строк за сутки остаётся живых 200-300, из них с приемлемой задержкой меньше сотни. Средний срок жизни публичного MTProto-узла - от трёх дней до двух недель. Дальше владелец VPS получает счёт за трафик, либо его сервер попадает в чёрные списки хостинга, либо ему просто надоедает возиться.
На Reddit в тредах про самодельные списки всплывает неочевидная деталь: авторы популярных репозиториев редко сидят на собранных узлах сами. У них в клиенте настроен платный узел, а репозиторий живёт на трафике и звёздах.
Отдельная категория - репозитории, которые сами себя называют лучшим списком. В README там обычно три ссылки на телеграм-каналы и один донат-кошелёк. Сам список обновлялся последний раз восемь месяцев назад, а в issues висят двадцать сообщений «всё умерло» без единого ответа.
Проверить такой репозиторий можно за минуту: дата последнего коммита, количество открытых issues, есть ли CI с реальной проверкой соединения. Если из трёх пунктов совпал только первый - идите дальше.
Публичный узел видит больше, чем вам кажется
Вот тут начинается неприятное. Владелец прокси-сервера видит IP, с которого вы подключаетесь, время сессии, объём трафика и то, к каким дата-центрам Telegram идёт соединение. Содержимое облачных чатов он не прочитает, там шифрование на уровне клиентов. Но метаданные - это уже много: с кем, как часто, в какое время.
Для болтовни с друзьями риск умеренный. Для рабочего аккаунта, через который идут сделки, клиентские данные и внутренние обсуждения, это лотерея. Особенно когда сервер стоит на чужом VPS, оплаченном неизвестно чем и способном завтра сменить хозяина без предупреждения.
Ещё один сценарий - подмена точки входа. Клиент доверяет узлу установить соединение, и никто не гарантирует, что этот узел не собирает запросы авторизации. Двухфакторка спасает, но включена она далеко не у всех.
MTProto: прокси на уровне транспорта, а не второй VPN
Архитектурно MTProto-прокси живёт внутри протокола Telegram. Клиент не заворачивает в него весь трафик устройства, как в случае с VPN. Он подключается к прокси, а тот держит соединение с ближайшим дата-центром Telegram. Дальше пакеты идут по уже установленному шифрованному каналу.
Что это даёт на практике. Первое: скорость. Если сервер стоит во Франкфурте, а дата-центр Telegram в Амстердаме, лишний хоп добавляет 5-15 мс, а не 200, как при маршруте через полмира. Второе: селективность. Через MTProto идёт только Telegram, остальной трафик машины не затрагивается. Это важно, когда ноутбук работает в корпоративной сети с инспекцией.
Шифрование остаётся сквозным между отправителем и получателем. Прокси видит пакеты, но не содержимое секретных чатов. Принципиальное отличие от ситуации, когда предлагают перехватывающий сервер с расшифровкой: там просто читают всё, что могут.
Настройка у MTProto короткая: адрес, порт и секрет. Секрет привязывает клиент к конкретному узлу, без него соединение не установится. Именно поэтому строку из чужого списка нельзя просто подставить в другой сервер: она работает только с тем, для которого выдана.
Минус один и серьёзный: MTProto не поможет браузеру, git и остальным приложениям. Он узкоспециализированный. Если нужен канал для всей рабочей машины, смотрят в сторону SOCKS5.
SOCKS5: рабочая лошадка для браузера и git
SOCKS5 просто перенаправляет TCP-соединения. Шифрования сам по себе он не добавляет, за это отвечает приложение сверху: HTTPS, SSH, TLS. Зато умеет то, чего не умеет MTProto: тянет любой трафик, включая UDP-ассоциации и DNS-запросы.
Для разработки это основной инструмент. Git по HTTPS идёт через SOCKS5 без плясок с бубном: достаточно одной строки в конфиге или переменной окружения. Тяжёлые клоны с субмодулями и LFS не рвутся на середине. Соединение стабильное и не зависит от того, жив ли очередной бесплатный узел из списка.
Про DNS отдельный разговор. Если клиент резолвит имена локально, запросы уходят мимо туннеля и часть картинки всё равно видна провайдеру. В настройках браузера и в конфиге git проверяйте, что резолвинг идёт через прокси. Иначе вся затея наполовину бессмысленна.
Есть нюанс с производительностью. SOCKS5 не сжимает трафик и не кеширует, вся работа ложится на канал. Если брать датацентр-прокси в том же регионе, где живёт ваш сервер или офис, прирост задержки почти незаметен. Если гнать через резидентский IP на другом континенте, готовьтесь к 300+ мс и медленным push/pull.
GitHub отдельно: где реально болит
С GitHub история отдельная. Главные причины - лимиты API и скорость. У REST API GitHub без авторизации лимит 60 запросов в час на IP, с токеном - 5000. Если вы или ваш CI гоняете скрипты в цикле, лимит выжигается за минуты, и дальше прилетает 403 на всё подряд.
Второй сценарий - корпоративная сеть. Внутри периметра git часто ходит через один шлюз, и все сборки идут с одного адреса. Пять разработчиков, дёргающих API параллельно, превращаются в один IP с общим лимитом. Прокси с пулом адресов и ротацией снимает вопрос без переписывания пайплайнов.
Технически всё решается в двух местах. Для HTTPS: строка вида http.proxy в конфиге git, после чего клоны и пуши идут через SOCKS5 или HTTP-прокси. Для SSH: директива ProxyCommand в ssh-конфиге, которая заворачивает соединение на 22-й порт в тот же туннель. Оба варианта настраиваются один раз и работают годами, пока жив узел.
Третий сценарий - распределённые сборки. Нужно прогнать тесты из конкретного региона или проверить, как ведёт себя вебхук с внешней стороны. Узел в нужной геолокации дешевле, чем поднимать отдельную инфраструктуру ради одной проверки.
Настройка в Telegram: по шагам, куда нажимать
В мобильном клиенте: Настройки, затем Продвинутые настройки (в части версий - Данные и память), дальше Тип подключения, кнопка Добавить прокси. Выбираете MTProto или SOCKS5, вводите адрес, порт, при необходимости секрет для MTProto или логин с паролем для SOCKS5. Жмёте Проверить, потом включаете переключатель «Использовать прокси».
В десктопной версии путь короче: Настройки, Продвинутые, Тип подключения, Добавить прокси. Там же есть поле для быстрого импорта строки целиком. Удобно, когда узлов несколько и вы переключаетесь между ними по ситуации.
В браузере логика другая. В настройках сети указываете SOCKS5-хост и порт, при необходимости включаете проксирование DNS. Для Chrome и Firefox удобнее держать отдельный профиль под рабочую сессию, чтобы не гонять весь домашний трафик через один узел.
В публичном Wi-Fi прокси настраивают в первую очередь для защиты трафика: открытые сети легко слушают. Шифрованный туннель до собственного узла снимает этот риск. Именно поэтому корпоративные команды держат один-два собственных SOCKS5-узла для поездок и командировок.
Свой узел на VPS: когда это дешевле, чем кажется
Минимальная конфигурация для MTProto-прокси - один vCPU и 512 МБ памяти. Такого хватает на 50-100 активных пользователей без заметной деградации. Ставится за пятнадцать минут по инструкции, дальше нужны только мониторинг и регулярные обновления.
Ключевой момент - локация. Выбирайте хостера, у которого дата-центр рядом с европейскими площадками Telegram. Разница между Франкфуртом и дальневосточным регионом в задержке - это разница между «работает как обычно» и «медиа грузятся по три секунды».
Для SOCKS5 всё строже: нужен нормальный канал, потому что через него пойдёт не только текст, но и трафик браузера, git и CI. Считайте терабайт на человека в месяц как базовую оценку для рабочей машины.
Держать свой узел имеет смысл, когда пользователей больше пяти и есть кому его администрировать. На Reddit владельцы небольших узлов отмечают обратную сторону: обновления, мониторинг и разбор инцидентов съедают вечера. Для одного-двух человек выгоднее брать готовый прокси в каталоге: вы платите за стабильность, а не за чтение логов.
Каталог вместо репозитория: что смотреть при выборе
Когда бесплатные списки надоедают, люди приходят к нормальному каталогу. У 3seller в разделе прокси сразу видно то, что важно на практике: протокол, страна, тип IP, поддержка авторизации, лимиты по трафику и скорости.
На что смотреть в первую очередь:
- Протокол. Для Telegram - MTProto, для браузера и git - SOCKS5, для скриптов и парсеров часто хватает HTTP/HTTPS.
- Тип IP. Датацентр быстрый и дешёвый. Резидентский и мобильный выглядят для внешних сервисов как обычные пользователи, но стоят дороже.
- Геолокация. Один узел рядом с вами для скорости, второй в нужном регионе для проверки гипотез.
- Ротация. Для парсинга и работы с лимитами API нужна смена адреса, для рабочего аккаунта - стабильный.
- Лимиты. Смотрите не на цену за месяц, а на цену за гигабайт при вашем профиле нагрузки.
Практический совет: не берите пакет на год, пока не погоняли узел неделю на реальной задаче. Скорость и стабильность у разных провайдеров отличаются сильнее, чем заявлено в описании. Проверьте, есть ли авторизация по логину и паролю или привязка к IP. Второй вариант удобнее для CI, но требует статичного адреса раннера.
Парсинг и аналитика: где прокси оправдан
Отдельная история - сбор данных из Telegram для бизнеса. Мониторинг упоминаний бренда, аналитика каналов, динамика подписчиков, выгрузка постов в свою базу. Всё это идёт через клиентские библиотеки и требует стабильного канала, иначе сборка рвётся на середине и данные теряются.
Здесь важна не только скорость, но и репутация адреса. Если с одного IP идёт активная работа, Telegram начинает ограничивать запросы. Пул с ротацией снимает проблему, но каждый узел должен быть чистым, иначе смысл теряется.
Момент, который часто упускают: для аналитики лучше отдельный аккаунт и отдельный прокси, не пересекающийся с рабочим. Тогда ограничения на сбор не задевают личную переписку, а при смене узла не приходится заново проходить проверку на основном аккаунте.
Начните с одного узла и замерьте задержку
Самый быстрый способ увидеть разницу между списком с гита и нормальным прокси - взять один узел и сравнить. Откройте Telegram, зайдите в настройки подключения, посмотрите время отклика. У публичного узла из свежего списка оно обычно 250-400 мс. У нормального европейского - 60-90. Медиа и звонки разницу чувствуют сразу.
Дальше решайте по задаче. Нужен только Telegram на телефоне - хватит одного MTProto. Нужен браузер, git и CI - берите SOCKS5 с пулом. Нужна аналитика и парсинг - смотрите в сторону ротации и чистых адресов в каталоге прокси.
И перестаньте обновлять README с бесплатными узлами каждую неделю. Время на поиск живого прокси стоит дороже подписки. А нервы после подключения через чужой сервер дороже вдвойне.