Открываешь Telegram в коворкинге, а он висит на «Connecting...» вторую минуту. Сообщения вроде уходят, медиа не грузится, звонок срывается на первой секунде. Виноват не телефон и не оператор, а сеть: она душит длинные соединения и нестандартные порты.
Дальше разберу, как поставить веб-прокси на тг своими руками: что подготовить, какие команды вводить, куда нажимать в приложении и где чаще всего спотыкаются. Без магии, на конкретном примере с собственным доменом.
Веб-прокси в Telegram - это отдельный зверь, а не просто «прокси»
В десктопном клиенте WEB-прокси появился в версии 7.1.1, и это не то же самое, что привычная ссылка с MTProto. Схема трёхслойная: Telegram Desktop стучится по HTTPS на 443 порт, дальше стоит Caddy с сертификатом Let's Encrypt, за ним крутится tproxy-server, а он поднимает MTProxy и уводит трафик в Telegram.
Снаружи весь этот поток выглядит как обычный визит на сайт по HTTPS. Никаких экзотических портов, никакого подозрительного хендшейка. Для корпоративного firewall или гостевого Wi-Fi в отеле это просто защищённое соединение с доменом, у которого есть сертификат.
Практический смысл тоже есть. MTProxy плохо живёт за реверс-прокси, а tproxy-server обвязывает его HTTPS-фронтом и раздаёт клиентам ссылку с двумя параметрами: домен и секрет. Секрет - hex-строка, ключ, которым клиент доказывает право на подключение. Руками его менять не надо, установщик генерит нормальный вариант сам.
Важная деталь, которую многие не знают: звонки через прокси не идут. Голос и видео поднимают отдельный канал, MTProxy их не трогает. Если в офисе жалуются «прокси не работает, звонок не проходит», проблема не в конфиге.
Что подготовить до первой команды
Сервер. Хватит самого дешёвого VPS: одно ядро и гигабайт памяти спокойно тянут команду из 20-50 человек при обычной переписке. Больше памяти нужно, если через узел пойдёт медиа в промышленных объёмах.
Домен обязателен, и именно DNS hostname: IP-адрес тут не работает. Сертификат выпускается на имя, и Caddy откажется получать его для голого адреса. Берём поддомен вроде proxy.mysite.com, ставим A-запись на сервер и ждём, пока DNS разлетится. Обычно 5-15 минут, дольше - если TTL был большой.
Открытый 443. Конструкция живёт только на этом порту. Если на машине уже висит nginx или другой веб-сервер, его надо освободить или подружить с Caddy, иначе установщик упадёт на попытке занять порт.
Почта. Нужен живой email: на него Let's Encrypt регистрирует аккаунт и присылает уведомления о продлении сертификата. Адрес вида admin@localhost не подойдёт, письма не дойдут.
Ставим tproxy-server: четыре шага
Заходим на сервер по SSH под пользователем с sudo.
- Клонируем репозиторий: git clone официального telegramdesktop/tproxy-server.
- Переходим в каталог: cd tproxy-server.
- Запускаем установщик с тремя параметрами: sudo ./deploy/install.sh --hostname proxy.mysite.com --email you@mysite.com --site-dir /var/www/tproxy-site.
- Дожидаемся, пока скрипт развернёт MTProto-ядро, поднимет Caddy и выпустит сертификат.
Параметр site-dir неслучаен: установщик кладёт в указанную папку маленький сайт-заглушку, чтобы домен отдавал хоть какую-то страницу и вёл себя как нормальный веб-ресурс. Пустой домен без контента выглядит подозрительно, а страница с текстом и заголовком - естественно.
В конце установщик печатает ссылку для подключения: префикс tg://webproxy, дальше параметр server с вашим доменом и параметр secret с hex-строкой. Ссылку можно скопировать и разослать команде, а можно вбить данные руками - результат одинаковый.
Что реально происходит на сервере после установки
Появляются два systemd-юнита: сам tproxy-server и Caddy. Конфиг Caddy лежит в /etc/caddy/Caddyfile, сертификаты в /var/lib/caddy, логи удобнее смотреть через journalctl -u tproxy-server и journalctl -u caddy с ключом -f, чтобы видеть картину в реальном времени.
Проверить HTTPS-фронт можно обычным curl с любой машины: домен должен ответить кодом 200 и отдать ту самую заглушку. Если curl отвечает таймаутом, сначала разбираемся с сетью и файрволом, лезть в конфиги раньше времени бессмысленно.
Caddy продлевает сертификат автоматически за месяц до истечения, но только если домен продолжает резолвиться в тот же сервер. Переехали на новую машину, забыли обновить A-запись, и через пару месяцев узел тихо умрёт. Напоминалка на 60 дней вперёд спасает нервы.
Как добавить веб-прокси в Telegram на разных устройствах
Самый быстрый путь - скопировать ссылку и открыть её. Клиент сам предложит добавить прокси, поля заполнятся автоматически, останется нажать «Добавить». Дальше приложение прогонит тест соединения и покажет статус.
На десктопе руками: Настройки, Продвинутые настройки, Тип соединения. Там включаем «Использовать собственный прокси» и заполняем тип, адрес, порт, логин и пароль. В свежих сборках есть отдельный раздел «Прокси» с кнопкой добавления. На Reddit в ветках про Telegram Desktop как раз на этом месте чаще всего и застревают: люди ищут пункт в «Продвинутых настройках», а он уже переехал. На Windows, macOS и Linux логика одинаковая, различаются только подписи в меню.
На телефоне путь похожий: Настройки, «Данные и память», раздел «Прокси», включаем «Использовать прокси», жмём «Добавить прокси». Дальше выбираем тип (SOCKS5 или MTProto), вводим адрес, порт, при необходимости логин и пароль, сохраняем. Telegram сразу тестирует и пишет «Подключено», если всё сошлось.
На iOS шаги те же, разве что раздел может называться иначе в зависимости от версии. На старых клиентах веб-прокси не появится в списке типов - там нужен свежий билд или обычный MTProto с адресом и портом.
Совет из практики: добавляйте сразу два-три узла. Telegram запоминает список и переключается между ними за пару секунд. Когда основной узел ляжет, а он рано или поздно ляжет, вы не останетесь без связи посреди рабочего дня.
Почему IP вместо домена ломает всю схему
Самая частая ошибка новичков - вписать в конфиг адрес сервера вместо домена. Не заведётся. Сертификат выписан на конкретное имя, клиент при TLS-хендшейке отправляет SNI с этим именем, и Caddy ищет в хранилище соответствующий сертификат. С голым IP сопоставлять нечего, соединение рвётся на рукопожатии.
Let's Encrypt принципиально не выдаёт сертификаты на IP-адреса. Либо домен, либо никак. Заодно это защита от глупостей: домен привязан к вашему аккаунту, извне его не подменить.
SOCKS5, MTProto и веб-прокси: разница на уровне архитектуры
Тут многие путаются, а разница принципиальная. SOCKS5 работает на пятой уровне OSI: просто перекидывает TCP-соединения и сам не шифрует. Шифрование ложится на приложение сверху, обычно TLS. Отсюда универсальность: через SOCKS5 ходит браузер, парсер, бот и вообще что угодно с TCP.
MTProto - прикладной протокол Telegram с собственным шифрованием пакетов. Экономнее по оверхеду, лучше переносит потери пакетов и переподключения в мобильных сетях, поэтому мессенджер на нём бодрее. Обратная сторона: годится только для Telegram, под сбор данных его не прикрутишь.
Веб-прокси - это MTProto, завёрнутый в HTTPS. Компромисс: плюсы MTProto остаются, а снаружи получается обычный защищённый веб-трафик на стандартном порту. Для офиса, где наружу разрешён только 443, это единственный рабочий вариант.
Отсюда выбор под задачу. Нужен мессенджер в сети с жёстким файрволом - веб-прокси на своём домене. Нужен сбор данных, работа с API, ротация адресов для маркетинговой аналитики - берите SOCKS5 с пулом узлов и балансировкой. Держать оба сценария на одной машине можно, но конфигурация усложняется, и я обычно развожу их по разным серверам.
Сколько выдержит один узел и где начнутся проблемы
Одно ядро и гигабайт памяти держат порядка 50 активных пользователей переписки и каналов. Дальше начинается борьба за CPU на TLS-хендшейках: каждая новая сессия - это криптография, и при сотне одновременных подключений слабый VPS заметно тормозит.
Канал важнее процессора. Если через узел гонят видео и файлы, гигабита хватит на небольшую команду, а сотня мегабит закончится быстро. На дешёвых тарифах трафик лимитирован, и узел тихо упирается в потолок к концу месяца. На Reddit в обсуждениях самодельных узлов админы сходятся в том же: упираются чаще в канал, а не в процессор.
Аптайм дешёвых VPS - лотерея. Ставьте простенький мониторинг, хотя бы проверку домена раз в пять минут через внешний сервис, и алерт в тот же Telegram. Один раз это спасает полдня разбирательств «почему у всех всё отвалилось, а я узнал об этом от коллег».
Свой узел или готовое решение: считаем деньги и нервы
Свой VPS с доменом - 4-6 долларов в месяц плюс час на настройку. Для команды дёшево, а контроль полный: логи под рукой, секрет можно перевыпустить в любой момент, скорость не делится с сотней посторонних людей.
Минус в том, что один узел - одна точка отказа и одно гео. Нужна ротация по странам, десяток адресов под парсинг маркетплейсов или отдельные выходы под разные аккаунты - на своём железе это дорого и бессмысленно. Проще взять готовый пул в каталоге прокси, где есть фильтры по стране, типу и назначению.
Про бесплатные списки отдельно. Первые сутки всё летает, на третьи скорость падает до 200 КБ/с, потому что на одном узле висят тысячи человек. Плюс никто не гарантирует, что владелец не логирует трафик. Экономия в ноль рублей обычно заканчивается потерянным рабочим днём.
Проверка и типовые грабли
Крутится колёсико, статус не меняется. Первым делом проверяем DNS: если A-запись не разлетелась, Caddy не выпустит сертификат, а без сертификата соединения не будет. Второе - занят ли 443 порт. Третье - логи Caddy и tproxy-server, там прямо написано, на каком шаге всё встало.
Подключилось, но медиа не грузится. Скорее всего упало MTProto-ядро, а HTTPS-фронт продолжает отвечать. Перезапускаем сервис и смотрим логи: часто упирается в лимиты по памяти на дешёвом VPS.
На десктопе работает, на телефоне нет. Проверяем версию клиента: веб-прокси поддерживают только свежие сборки. На старых остаётся классический MTProto с адресом и портом.
Отваливается раз в сутки в одно и то же время. Смотрим cron и обновление сертификата, а также не стоит ли на сервере fail2ban, который банит сам себя после серии переподключений с одного адреса.
Корпоративный сценарий: один узел на команду
В компаниях история выглядит иначе, чем у одного человека: один домен, несколько секретов под разные отделы, мониторинг доступности и понятный регламент, кому выдавать ссылку. Секрет работает как пропуск: отозвал hex-строку, и доступ у человека пропал, переустанавливать ничего не надо.
Ещё один сценарий, который я вижу всё чаще, - защита трафика в публичных сетях. Человек сидит в аэропорту, подключается к открытому Wi-Fi, и весь его поток до узла идёт внутри TLS. Это не паранойя, а базовая гигиена, особенно если в ноутбуке открыты рабочие чаты и админки.
Для аналитики и сбора данных логика другая: нужен пул адресов, ротация по запросам и стабильные гео, иначе выборка по регионам получается кривой. Под такие задачи удобнее брать готовые пулы в каталоге 3seller, а не масштабировать один VPS до состояния фермы.
Что сделать прямо сейчас
Если задача - закрыть мессенджер для себя или небольшой команды, порядок такой: берём поддомен, ставим A-запись, поднимаем tproxy-server одной командой, копируем ссылку и раздаём. Час работы, и у вас собственный узел, который не зависит от чужих бесплатных списков и чужого настроения.
Если нужны разные гео, ротация и объёмы, начинать с железа смысла нет. Сначала посмотрите, что есть в каталоге прокси, прикиньте стоимость под свою нагрузку, и только потом решайте, нужен ли свой сервер и какой тариф брать.