Первый раз WEB-транспорт в Telegram Desktop я заметил по логам nginx. Клиент поднял соединение на 443, попросил Upgrade, получил 101 Switching Protocols и дальше погнал трафик, который к сайту на этом домене не имел никакого отношения. Галочки «включить web proxy» в клиенте нет. Есть ссылка, которую Telegram открывает как обычную страницу, и дальше эта страница работает каналом. Разбираю, как подключить её на десктопе, что подготовить на своей стороне и где люди стабильно спотыкаются.
WEB-транспорт живёт по другим правилам, чем обычный прокси
Привычный прокси в Telegram это адрес, порт, тип и пара логин-пароль. Клиент открывает TCP-соединение до узла и гонит через него пакеты. WEB-вариант устроен иначе: клиент сначала делает HTTPS-запрос к домену, а уже внутри этого запроса передаёт данные. Снаружи в сетевом дампе видно нормальное обращение к сайту: TLS-рукопожатие, ALPN h2, заголовки, ответ 200 или 101.
Отсюда главное следствие, которое ломает половину ожиданий. WEB-ссылка работает только в Telegram Desktop. Мобильные клиенты этот транспорт не реализуют, и если вы кинете ссылку в чат коллеге с iPhone, он увидит текст, а не кнопку подключения. Наличие ссылки не добавляет поддержку в приложение, которое про такой транспорт ничего не знает.
Второе следствие касается задачи. Корпоративная сеть часто разрешает наружу только 443 и только к доменам из белого списка. Обычный SOCKS5 на нестандартном порту там просто не поднимется, а WEB-транспорт на 443 с валидным сертификатом и живым лендингом в эти правила укладывается. Тот же приём актуален в публичном Wi-Fi аэропорта или отеля, где наружу выпускают только веб.
Ссылка вместо полей: как подключить web proxy в тг на десктопе
Начинается всё с того, что вы получаете от своего узла или сервиса ссылку вида https://ваш-домен/какой-то-путь. Порядок такой:
- Открываете Telegram Desktop и жмёте три полоски в левом верхнем углу.
- Заходите в «Настройки», затем в «Продвинутые настройки».
- Нажимаете «Тип соединения».
- Включаете «Использовать собственный прокси» и жмёте «Добавить прокси».
- Вставляете ссылку в поле для ссылки, клиент сам разбирает тип, адрес и порт.
- Сохраняете и смотрите на статус соединения.
Если всё сошлось, Telegram покажет «Подключено» и через пару секунд подтянет непрочитанные. Если нет, он честно напишет, что соединение не установлено, и это полезнее молчаливого зависания. Проверить, что трафик реально идёт через узел, можно по логам сервера: там видно запросы клиента с его User-Agent и временем рукопожатия.
В обсуждениях на Reddit по Telegram Desktop всплывает нюанс, о котором почти никто не пишет: ссылка привязана к домену. Поменяли домен, переехали на другой сервер, перевыпустили сертификат на новое имя - старая ссылка перестаёт работать. Держите её там же, где храните конфиги, а не в переписке с самим собой.
Классические поля никуда не делись: HTTP и SOCKS5 вручную
Если WEB-ссылки нет, никто не мешает подключить обычный прокси руками. В том же окне «Тип соединения» выбираете «Использовать собственный прокси», нажимаете «Добавить прокси», указываете тип HTTP или SOCKS5, вбиваете адрес сервера, порт, логин и пароль, сохраняете. Telegram сразу пробует соединение и показывает пинг до узла.
Разница между HTTP и SOCKS5 на практике ощутимее, чем кажется. HTTP-прокси проще и быстрее в настройке, но он по сути работает на уровне запросов. SOCKS5 не лезет в содержимое и просто передаёт поток байтов, поэтому с ним меньше сюрпризов при звонках и передаче файлов. Для рабочего аккаунта с большим объёмом медиа я обычно выбираю SOCKS5, для быстрой проверки гипотезы хватает HTTP.
Отдельно про MTProto. Этот транспорт жил в Telegram исторически, у него своя обфускация и свои прокси-серверы, и он до сих пор актуален там, где нужен именно телеграмовский протокол. Сравнивать его с WEB-вариантом по скорости бессмысленно, они решают разные задачи. MTProto это про устойчивость к разбору трафика, WEB это про то, чтобы соединение выглядело как визит на сайт.
iOS и Android: путь другой, поля те же
На iPhone и iPad всё лежит в другом разделе. Открываете Telegram, идёте в «Настройки» на нижней вкладке, дальше «Данные и память», пролистываете до блока «Прокси», включаете «Использовать прокси», жмёте «Добавить прокси». Дальше тип SOCKS5, адрес сервера, порт, логин и пароль, сохранение по галочке. Приложение само тестирует соединение и показывает статус.
На Android логика та же, только раздел называется «Данные и хранилище», и добавление прокси живёт внутри него. Заполняете те же четыре поля и сохраняете. Проверить просто: отправьте себе сообщение в «Избранное», если оно ушло за секунду, канал живой.
Практический совет, который экономит вечер. Не заводите на телефоне прокси, который не проверили на десктопе. Мобильный клиент ведёт себя строже к сертификатам и таймаутам, и разбираться сразу с двумя платформами утомительно. Сначала десктоп, потом телефон.
Архитектура: HTTPS-страница как транспорт
Внутри WEB-схемы есть публичный TLS-листенер на 443, который держит HTTP/2, и приватный слушатель на localhost, куда nginx проксирует запросы. Публичный nginx обязан передавать реальный заголовок Host, потому что сервер сверяет его со своим hostname из конфига. Если подставить константу вместо $http_host, соединение отвалится на первом же запросе, и в логах будет что-то невнятное.
Второй момент: публичная часть может и должна работать по HTTP/2, а вот связка nginx с внутренним слушателем остаётся на HTTP/1.1. Если выбрать транспорт на WebSocket, нужно пробрасывать заголовки Upgrade и Connection, иначе апгрейд не состоится. После правок конфига всегда nginx -t, потом reload, и только потом перезапуск самого узла.
По задержкам выходит примерно так. Рукопожатие до европейского узла из Москвы это 120-180 мс, обёртка в HTTP-фреймы добавляет ещё 20-40 мс на круг. Для переписки неощутимо, для звонков лучше держать узел ближе физически. Мультиплексирование в HTTP/2 частично снимает проблему очереди пакетов, но чудес не бывает.
Картинка для наглядности:
Что подготовить на сервере до первого подключения
Домен и A-запись на адрес сервера. Без домена схема не работает, потому что клиент идёт по HTTPS и проверяет сертификат. Дальше валидный сертификат, самый простой путь это Let's Encrypt с автопродлением. Потом nginx на 443 с HTTP/2 и upstream на приватный порт. Наружу торчит только 443, внутренний слушатель висит на localhost и снаружи недоступен.
Firewall настраивается скучно и жёстко: 443 для всех, SSH по ключу и только с ваших адресов, остальное закрыто. Это база, но именно на ней чаще всего экономят, а потом удивляются странным запросам в логах.
Отдельно продумайте аутентификацию. Логин с паролем на каждого пользователя, а не один общий на всех. Если людей больше пяти, это уже не паранойя, а нормальная гигиена: ушёл человек, вы просто удалили его учётку, а не меняли пароль всей команде.
Сайт прикрытия решает не ту задачу, о которой думают
Все думают, что лендинг на том же домене нужен для маскировки. На самом деле он нужен для того, чтобы домен вёл себя как домен. Открыли в браузере, увидели нормальную страницу с текстом и картинками, а не пустой экран с ошибкой. Корпоративные фильтры и публичные точки доступа часто смотрят именно на это.
Технически всё просто: корень отдаёт статическую страницу, а по отдельному пути живёт WEB-транспорт. Ошибка новичка в том, что на корень ставят заглушку в три слова. Такой сайт выглядит подозрительнее, чем его отсутствие. Сделайте честную страницу на 5-6 блоков: кто вы, чем занимаетесь, контакты. Пять минут работы, а вопросов к домену становится в разы меньше.
Пять мест, где настройка ломается
- Host подменён константой в конфиге nginx, и сервер не узнаёт свой домен.
- В upstream включили HTTP/2, хотя внутренний слушатель ждёт HTTP/1.1.
- Публичный порт не 443, и корпоративный фильтр просто не пускает соединение.
- Сертификат выпущен на www, а ссылка и клиент идут на голый домен без www.
- В ссылке остался старый путь после смены конфигурации, клиент стучится в пустоту.
Каждый из этих пунктов даёт одинаковый внешний симптом: «не подключается». Разбирать приходится по логам, поэтому они должны быть включены до того, как вы начнёте тестировать, а не после.
Диагностика без шаманства
Первый шаг это curl с того же устройства. Запрос на корень домена должен вернуть 200 и HTML. Запрос на путь транспорта без нужных заголовков вернёт ошибку, и это нормально, он не для браузера. Второй шаг openssl s_client на 443, смотрите цепочку сертификатов и ALPN. Если в ответе нет h2, публичная часть настроена неверно.
Третий шаг логи nginx. Ищите коды 101 и 200 на пути транспорта, время апстрима и размер отданного тела. Пустой лог при живом клиенте означает, что запрос не дошёл до сервера, и копать надо в сторону DNS и firewall. Четвёртый шаг tcpdump на интерфейсе, если совсем непонятно, кто молчит.
И последнее. Смотрите не на «подключено», а на стабильность. Оставьте клиент на час, потом проверьте, не растут ли таймауты. Разовая удача ничего не значит, а вот ровный пинг в течение дня это уже результат.
Где взять прокси, если свой узел поднимать не хочется
Поднимать VPS с nginx и сертификатом ради теста обычно лень, и это нормально. Быстрее взять готовый прокси, проверить гипотезу на живом клиенте и уже потом решать, нужен ли свой узел. Для таких задач я держу под рукой каталог прокси с фильтрами по гео, типу и протоколу: HTTP и SOCKS5, разные страны, оплата на короткий срок. Взял на день, прогнал тесты, понял, что к чему.
Практика показывает: связка «дешёвый прокси на сутки плюс свой скрипт проверки» экономит больше времени, чем час ковыряния в конфиге nginx вслепую. А когда схема подтвердилась, уже осмысленно вкладываться в собственный сервер с доменом и нормальным сертификатом.
Гигиена доступа: логи, лимиты, ротация
Логи пишите, но без содержимого трафика. Вам нужны время, адрес клиента, код ответа и объём, а не то, что человек писал в чат. Это и этика, и банальная безопасность: логи утекают чаще, чем серверы взламывают.
Поставьте лимит одновременных соединений на пользователя. Без него один клиент с криво настроенной синхронизацией выест канал у всей команды: я видел ноутбук с четырьмя аккаунтами, который держал под сорок соединений и душил остальных. Пароли меняйте раз в 30-60 дней, а при уходе человека удаляйте учётку сразу, а не «в конце месяца».
Мониторинг сделайте примитивный: раз в минуту проверка, что публичный порт отвечает 200 на корне, и что внутренний слушатель жив. Падение одного из двух это сигнал. Без такой проверки вы узнаете о проблеме от коллег, и это будет неприятный разговор.
Когда WEB-транспорт оправдан, а когда это стрельба из пушки по воробьям
Оправдан он в трёх случаях. Первый: корпоративная сеть с жёстким белым списком, где 443 это единственный выход. Второй: распределённая команда, которой нужен предсказуемый канал с одного домена и понятной статистикой. Третий: аналитика и парсинг открытых данных, где важно выглядеть как обычный веб-клиент.
Не оправдан он, когда вас трое и все в одном офисе. Тут SOCKS5 на нормальном сервере закроет задачу за десять минут и не потребует ни домена, ни лендинга, ни возни с заголовками. Я видел проекты, где человек неделю строил WEB-схему, чтобы переписываться с двумя коллегами. Не надо так.
Ещё один трезвый критерий: наличие человека, который умеет читать логи nginx. Если такого нет, любой WEB-узел превратится в чёрный ящик, который работает до первого обновления сертификата. Тогда лучше брать готовый прокси и не строить инфраструктуру.
Начните с малого: возьмите один прокси, вбейте его в Telegram Desktop через «Тип соединения», убедитесь, что статус зелёный и сообщения ходят. Дальше решите, нужна ли вам ссылка на своём домене. Если нужна, подготовьте домен, сертификат и nginx с передачей Host, проверьте ALPN и логи. И держите под рукой каталог на случай, когда свой узел ляжет, а работать надо сейчас.