Сентябрь, коворкинг на окраине, гостевой Wi-Fi пускает только 80 и 443 порт. Всё остальное молча умирает на фильтре. Нужно отправить три десятка сообщений и два файла, а Telegram десять минут висит на «Обновление соединения». MTProto-прокси с секретом на 443 в этой сети не поднялся: железо ждало нормальный TLS, а не бинарный поток. Через час я собрал на своём VPS связку Caddy плюс релей, и мессенджер поехал. Та же идея, только аккуратнее и с мультиплексированием, сейчас лежит в Telegram Desktop под названием WEB Proxy.
Дальше - устройство WEB-прокси, требования к своему узлу, кнопки в клиентах и грабли, на которые я уже наступил. И честный ответ, в какой момент настройка своими руками перестаёт быть выгодной.
WEB-прокси это транспорт, а не ещё одна галочка в настройках
Официального анонса от команды мессенджера до сих пор не было. Компоненты WEB Proxy нашли в десктопном клиенте: они лежат в бета-ветках и включаются не у всех. Схема простая. Клиент формирует привычный MTProxy-трафик и упаковывает его в веб-поток. Несколько соединений мессенджера идут через один HTTPS-канал, отдельное TCP-соединение под каждый запрос открывать не нужно.
На серверной стороне получается почти обычный сайт. Прототип, который тестировали на Хабре в блоге Домклика, собран из набора сервисов на Go поверх Caddy. Сервер отдаёт страницу по base_path, и по тому же адресу доступен API, которым пользуется клиент Telegram. В edge-схеме тяжёлый трафик уходит на отдельный узел, а входной сервер только терминирует TLS. Снаружи это запрос к обычному HTTPS-сайту: те же заголовки, тот же 443, тот же сертификат.
Практическая ценность именно в этом. Сеть, которая пускает только веб-трафик, WEB-прокси проходит без экзотических трюков. Обычный MTProto с секретом часто спотыкается о придирчивое сетевое оборудование, а здесь сигнатура первого пакета самая безобидная.
Чем отличается от MTProto и SOCKS5
Классический MTProto-прокси работает на своём секрете, обычно на 443, но без TLS-обёртки. Быстрый, дешёвый по ресурсам, ставится на любую железку за пять минут. Слабое место - предсказуемая структура пакетов и один поток на соединение. Когда в сети стоит анализатор трафика, MTProxy начинает «моргать»: то коннектится, то нет, а в логах клиента красивая надпись «прокси не отвечает».
SOCKS5 - транспорт общего назначения. Сам он ничего не шифрует, шифрование живёт внутри Telegram, а прокси перекидывает байты. Удобно, универсально, поднимается одной строкой в SSH. Но маскировки под веб нет, и в офисных сетях с белым списком портов он часто бесполезен.
WEB-прокси занимает нишу между ними. Снаружи TLS 1.3 на 443, ALPN h2, валидный сертификат на нормальный домен. Внутри - тот же MTProxy-поток. Плюс мультиплексирование: десяток чатов и каналов едут через одно соединение, TLS-рукопожатие делается один раз, а не пятнадцать. На телефоне это меньший расход батареи, на плохом канале - более ровный пинг.
Где WEB-прокси реально выручает
Гостиничные и аэропортовые сети. Почти всегда allowlist по портам и подмена DNS. Мобильный клиент на WEB-прокси поднимается там, где MTProto упорно не хочет, и я перестал закладывать на это время в поездках.
Корпоративная сеть. Отдел на 30 человек, админ не любит нестандартные порты - свой узел с валидным сертификатом решает вопрос предсказуемо. Один домен, один 443, весь трафик мессенджера идёт через ваш сервер. Видно объём, можно ставить лимиты.
Публичный Wi-Fi. Здесь важнее не доступ, а гигиена. Открытая сеть в кафе видит, к каким IP вы ходите, и любит подсовывать свои сертификаты. Трафик через собственный узел с проверяемым сертификатом так просто не перехватить.
Несколько сервисов на одном домене. WEB-прокси отдаёт страницу по base_path и API по соседнему пути, поэтому на одном VPS живёт и корпоративная вики, и прокси-точка для мессенджера. Экономия 200 рублей в месяц погоды не делает, зато возни с DNS и сертификатами вдвое меньше.
Что понадобится, чтобы поднять свой узел
- VPS с 1 vCPU и 1 ГБ RAM. По моим замерам хватает на 80-100 одновременных соединений, дальше начинаются танцы с conntrack.
- Домен и A-запись на IP сервера. Без нормального домена не будет нормального сертификата, а с самоподписанным клиент молча отвалится.
- Свободный 443/tcp. Если на сервере уже живёт сайт, ставьте прокси на отдельный поддомен или используйте edge-схему.
- Caddy как входная точка. Автоматический Let's Encrypt, HTTP/2 из коробки, конфиг на десять строк.
- Собственно релей. Готовая сборка tproxy_relay или свой бинарник на Go, если хочется контролировать логику.
Трафик считайте заранее. Двадцать активных пользователей с перепиской и парой каналов съедают 3-5 ГБ в сутки. Видеозвонки и пересылка файлов легко утроят цифру. VPS берите с запасом по каналу, а не по диску: диск в этой задаче вообще не при чём.
Серверная часть: порядок действий
- Направьте A-запись поддомена на IP сервера и дождитесь, пока обновятся NS. Пока DNS не устоялся, Let's Encrypt не выдаст сертификат.
- Поставьте Caddy и опишите в Caddyfile один сайт: домен плюс reverse_proxy на локальный порт релея. TLS Caddy поднимет сам.
- Соберите и запустите релей. Ему на вход нужен base_path, случайный секрет и локальный порт прослушивания. Наружу он не смотрит вообще.
- Проверьте, что по адресу https://ваш-домен/base_path отдаётся страница с кодом 200, а не 404. Это самый частый источник тишины в логах.
- Оберните релей в systemd с автоперезапуском и лимитом памяти. Он не должен ронять сервер, если один клиент решит скачать гигабайт.
- Закройте всё лишнее файрволом: наружу только 22, 80 и 443. Локальный порт релея снаружи быть недоступен.
Всё вместе у меня заняло чуть больше часа, из которых сорок минут ждал DNS. Самое долгое - не сборка, а отладка того, что клиент видит 404 вместо страницы.
Клиенты: куда именно нажимать
Telegram Desktop. Настройки - Продвинутые настройки - Тип подключения - Прокси - Добавить прокси. В типе выбираете WEB, дальше домен, порт 443 и секрет, который выдал ваш релей. Кнопка «Подключиться» появляется сразу, статус видно внизу окна. Если пункта WEB в списке нет, у вас стабильная сборка без нужных компонентов. Обновитесь на бету или используйте MTProto на том же сервере.
Android. Настройки - Данные и память - Прокси - Добавить прокси. Выбираете тип, вводите адрес, порт и секрет, сохраняете и включаете переключатель. В мобильной версии WEB-прокси появляется позже десктопа, так что если типа нет, дело не в ваших руках.
iOS и macOS. Настройки - Данные и память - Прокси. Логика та же: адрес, порт, секрет, включить. На iOS при активном прокси в шапке чатов появляется значок, по нему удобно проверять, что вы не едете напрямую.
Браузерная версия Telegram Web работает через системные настройки прокси, и это отдельная песня. Если нужен именно веб-клиент, проще поднять локальный туннель на машине и не мучить вкладку.
Один HTTPS-канал вместо десяти TCP
Мультиплексирование звучит как маркетинг, пока не посмотришь на цифры. В моём замере на канале с RTT 90 мс установка одного TLS-соединения занимает примерно одно рукопожатие, а дальше десяток чатов едет по уже открытому каналу. У MTProto-схемы каждый новый чат с активной синхронизацией тянет своё соединение. На слабом мобильном интернете это выливается в подтормаживания при переключении между чатами.
Есть и обратная сторона. Разработчики прототипа на Хабре прямо предупреждают про head-of-line blocking: если один большой файл залип, остальные сообщения ждут вместе с ним. Поэтому в настройках релея я всегда ограничиваю размер буфера на соединение и держу два канала на клиента - один под текст, второй под медиа. Мелочь, а ощущения от работы меняет сильно.
Грабли, на которые я наступал лично
Самоподписанный сертификат. Клиент не покажет внятной ошибки, просто «прокси недоступен». Полдня диагностики, а лечится одной строкой в Caddyfile и перевыпуском через Let's Encrypt.
Забытый base_path. Сервер отдаёт 404, Caddy пишет 200 в логах доступа, и кажется, что всё хорошо. Сверяйте путь в конфиге релея и в клиенте посимвольно, включая завершающий слеш.
Переполненная таблица conntrack. На дешёвых VPS с 512 МБ памяти при полусотне клиентов ядро начинает дропать пакеты, и это выглядит как «прокси работает через раз». Лечится sysctl и нормальным размером RAM, а не шаманством.
Надежда на публичные бесплатные узлы. Живут они часами, секрет утекает в открытые каналы за сутки, скорость падает до нуля к вечеру. Для теста сойдёт, для рабочего процесса нет.
Один узел на всех без лимитов. Кто-то обязательно включит автоскачивание всех медиа и выест канал. Ставьте лимит на соединение и мониторьте трафик с первого дня.
Когда свой сервер не нужен: готовый прокси из каталога
Держать узел имеет смысл, когда есть команда, админ и предсказуемая география. Для точечных задач - поездка, пара аккаунтов, тест рекламной связки - свой VPS превращается в хобби с обновлениями и мониторингом. Тут проще взять готовое.
Я пользуюсь каталогом прокси 3seller: там видно страну, тип, протокол и цену без переписки с менеджером. Для мессенджера обычно хватает обычного узла в нужной географии, для сбора данных и проверки выдачи берут резидентские. Перед покупкой есть тест, так что пинг и стабильность проверяются до оплаты.
Практическая разница простая. Свой узел - это контроль над секретом, логами и лимитами, но вы же и служба поддержки. Каталог - это скорость старта и предсказуемая оплата, но настраивать клиент все равно придётся вам. Ключевой шаг один и там и там: получить адрес, порт и секрет и правильно вписать их в настройки подключения.
Что сделать прямо сейчас
Если задача разовая, возьмите готовый узел в каталоге 3seller, добавьте его в Telegram Desktop через «Добавить прокси» и проверьте скорость на своём обычном канале. Если прокси нужен постоянно и под своих людей, поднимите VPS с Caddy и релеем: час работы, домен за 200 рублей в год и полный контроль над трафиком.
И заведите второй профиль подключения. Любая прокси-схема рано или поздно упирается в сеть, которая её не пропускает, а переключение на запасной профиль занимает десять секунд и спасает встречу.