Полтора года назад я поставил на свой Pixel сборку локального MTProto-прокси с GitHub, чтобы проверить её в поездке. Через двое суток телефон начал жаловаться на расход батареи, а в логах висели реконнекты каждые сорок секунд. Проект живой, звёзды растут, но ощущения «поставил и забыл» не появилось. С тех пор запрос «github прокси для телеграмм андроид» для меня - поиск инструмента под конкретную задачу, а не волшебной кнопки.
Дальше - что реально лежит в открытых Android-репозиториях, как это работает на уровне архитектуры и в какой момент дешевле взять управляемый узел, чем играть в сборщика APK.
На GitHub под словом «прокси» живут два разных зверя
Первая категория - приложения-парсеры. Трафик они не проксируют вообще. Скачивают текстовые списки серверов, пингуют и показывают табличку: жив, мёртв, задержка 120 мс. Классический пример - ComradeBingo/Proxy-Telegram-Android: 179 звёзд, 15 форков, 8 наблюдателей, работа на основе файлов proxy_ru.txt и proxy_eu.txt плюс сторонний список от одного популярного канала. В README честно написано: работоспособность серверов как прокси для Telegram не гарантируется.
Вторая категория - локальные прокси-серверы, которые поднимаются прямо на телефоне. Тут уже настоящая архитектура: amurcanov/tg-ws-proxy-android, Android-форк проекта Flowseal на Rust и Kotlin. Приложение поднимает MTProto-прокси на самом устройстве и гонит трафик либо через CloudFlare WebSocket, либо напрямую к дата-центрам Telegram. Разница между категориями примерно как между списком заправок в навигаторе и собственным бензобаком.
Есть и третий слой, о котором часто забывают: сам Telegram выкладывал в открытый доступ исходники MTProto-прокси-сервера с инструкцией по развёртыванию через Docker. Это серверная часть, её ставят на VPS. Важная деталь из истории протокола: MTProto-прокси работает только внутри мессенджера, снаружи его не переиспользуешь ни в браузере, ни в другом приложении.
Локальный MTProto на телефоне: как это устроено внутри
Схема простая, если смотреть на неё без маркетинга. Приложение поднимает listener на localhost, Telegram подключается к нему как к обычному прокси, дальше трафик уходит либо в дата-центр Telegram напрямую, либо заворачивается в WebSocket к CloudFlare. Ключевое слово - localhost. Трафик не покидает устройство до момента выхода в сеть, а мессенджер даже не подозревает, что между ним и сетью появился посредник.
В форке amurcanov это реализовано аккуратно: Foreground Service с постоянным уведомлением, чтобы Android не убивал процесс при агрессивном менеджменте памяти, встроенный лог-вьюер с событиями в реальном времени, пул соединений и Dynamic Colors на Android 12 и выше. Порядок запуска описан в README: скачать APK со страницы релизов, установить, открыть, нажать «Запустить прокси», затем «Применить в Telegram» и подтвердить подключение в клиенте. Четыре экрана и одно подтверждение.
Смысл держать прокси на телефоне один - задержка. Когда посредник живёт в том же устройстве, вы экономите сетевой хоп, и в мобильной сети это иногда даёт 40-80 мс на коротких запросах. Для переписки незаметно, для загрузки медиа в поезде ощутимо. Цена - батарея: телефон тратит её на шифрование и держит постоянное соединение, которое система старается придушить.
Парсер списков: почему 179 звёзд не равны стабильной связи
С парсерами другая история. Приложение скачивает .txt, стучится по адресам, замеряет пинг и отдаёт отсортированный список. Звучит удобно, пока не посмотришь, что происходит через сутки. Публичные списки обновляют люди со своими интересами: кто-то рекламирует канал через прокси, кто-то держит узел на домашнем роутере, который выключается на ночь. Пинг в момент проверки ничего не говорит о пропускной способности и о том, выдержит ли сервер десять одновременных подключений.
В README того же ComradeBingo прямо сказано: доступность и пинг проверяются, а работоспособность как прокси для Telegram не гарантируется. Вот и весь контракт. Вы получаете инструмент для отбора, а не готовую инфраструктуру. Для разового эксперимента сойдёт, для ежедневной работы с клиентами и файлами на 200 МБ - лотерея.
Отдельный нюанс - монетизация. Владельцы публичных MTProto-узлов часто зарабатывают не на трафике, а на рекламных каналах, которые подсовываются в клиент при подключении через их сервер. Технически это легально и заложено в протокол, но для корпоративного аккаунта отдела продаж лишняя реклама в интерфейсе выглядит странно. Свой узел или платный каталог такой сюрприз исключают.
Батарея, пинг и мобильный трафик: чего ждать на практике
По моим замерам на трёх устройствах (Pixel 6a, Redmi Note 11, Samsung A54) локальный MTProto-прокси в фоне съедал от 3 до 7% батареи за восемь часов простоя. Не катастрофа, но при привычке к двум дням автономности разница заметна. На Reddit в тредах про самодельные Android-сборки этот же расклад повторяют почти слово в слово: ночной простой, 5-7% заряда, нагрев на слабых чипах при загрузке больших файлов.
С WebSocket-маршрутом через CloudFlare картина другая. На нестабильном мобильном интернете стабильность выше: WebSocket лучше переживает смену соты и кратковременные провалы, зато базовая задержка вырастает на 20-50 мс из-за лишнего плеча. Для голосовых звонков это слышно, для текста и файлов - нет.
Трафик считается без сюрпризов, но есть подвох: некоторые публичные узлы режут скорость после определённого объёма или отдают приоритет «своим» каналам. В логах это выглядит как внезапное падение throughput с 8 Мбит/с до 400 Кбит/с без единой ошибки соединения. На стороне клиента такое не диагностировать - вы просто видите медленную загрузку и грешите на оператора.
Где заканчивается GitHub и начинается нормальная инфраструктура
Любой, кто возится с этими репозиториями, рано или поздно приходит к одному выводу: открытый код хорош как песочница и плох как сервис. Нужен узел, за который кто-то отвечает, с понятной географией, лимитами и заменой при отказе. Для этого есть каталог прокси 3seller.com/proxy - серверы по типам (SOCKS5, HTTP, MTProto), странам и назначению, с фильтрами по скорости и объёму трафика.
Каталог хорош тем, что не надо угадывать. Видно, где физически стоит узел, какой у него канал, годится ли он под мобильную работу или под парсинг маркетплейсов с десятков потоков. Для команды из пяти человек проще взять пакет на выделенные адреса, чем объяснять каждому сотруднику, как собрать APK из исходников и почему через день он перестал работать.
Корпоративный сценарий выглядит иначе. Когда десять менеджеров сидят в Telegram с рабочих ноутбуков и телефонов, а трафик идёт через публичный Wi-Fi в коворкинге, вменяемый вариант один - свой VPS с MTProto или SOCKS5-узел из каталога. Тогда вы контролируете, кто и куда ходит, и не зависите от того, обновил ли автор репозитория список .txt файлов.
Куда нажимать: настройка в клиенте Telegram
Если у вас уже есть рабочий узел, дальше всё делается руками в приложении. Порядок на Android такой:
- Откройте Telegram и зайдите в «Настройки».
- Пролистайте до раздела «Данные и память» (в некоторых сборках пункт называется «Данные и хранилище»).
- Найдите блок «Настройки прокси» или «Прокси».
- Нажмите «Добавить прокси» и выберите тип: MTProto или SOCKS5.
- Введите адрес сервера, порт и секрет (для MTProto секрет обязателен, без него подключение не поднимется).
- Сохраните и включите переключатель «Использовать прокси».
После включения клиент покажет статус соединения в верхней части экрана настроек. Если индикатор зелёный, но сообщения висят в «часиках», проблема почти всегда в секрете или в типе узла. Для локального прокси с GitHub шаги те же, только адрес будет локальный, порт возьмёте из приложения, а секрет оно сгенерирует само.
На iOS история другая: MTProto-прокси в клиенте там долго не поддерживался на уровне приложения. Отсюда и привычка всех статей про такие проекты начинаться со слова «Android». Если в команде есть айфоны, планируйте SOCKS5 или корпоративный шлюз, а не локальный APK.
Кому хватит репозитория, а кому нужен каталог
Разделю по-честному. Если вы один, у вас технический интерес, вы готовы раз в неделю менять список серверов и не работаете с крупными файлами - GitHub-проекты дадут всё нужное бесплатно. Парсер для быстрой проверки, локальный MTProto для ускорения загрузки в мобильной сети, лог-вьюер для понимания, что происходит. Экспериментируйте - это лучший способ понять, как протокол ведёт себя на вашем операторе.
Если речь про работу, деньги и людей - логика другая. Нужна предсказуемость: узел не пропадает, скорость не падает в середине созвона, а если что-то сломалось, есть куда написать. Тут каталог прокси 3seller закрывает вопрос за пару минут: выбрал страну, тип, объём, оплатил, вставил данные в клиент. Никаких сборок и никаких «а почему вчера работало, а сегодня нет».
Ещё один аргумент, который редко пишут в README. Публичные узлы видят ваш трафик в объёме метаданных: кто, когда, к какому дата-центру и сколько. Для личной переписки это вопрос гигиены, для рабочей - вопрос договора. Свой VPS или платный сервер снимает эту головную боль полностью.
Мой рабочий сценарий на каждый день
Сложилось так: дома и в офисе у меня стационарный SOCKS5-узел из каталога, он держит рабочие клиенты и парсеры. На телефоне в поездках - локальный MTProto из того самого форка, но только когда нужен быстрый доступ к большим вложениям. Включаю вручную, в фоне сутками не держу. Публичные списки с GitHub оставил как развлечение на выходные: иногда там попадаются конфигурации, которые потом переношу на свой сервер.
Такая связка снимает главную проблему всех этих репозиториев - зависимость от чужой доброй воли. Открытый код даёт понимание архитектуры, инфраструктура - стабильность. Смешивать одно с другим в одном инструменте не получится, и это нормально.
Если хотите повторить - начните с малого: поднимите один узел, проверьте его на своём операторе в час пик, замерьте пинг до и после. Дальше решение придёт само, и вы будете точно знать, за что платите.