Telegram Desktop 7.1.1 добавил в настройки соединения новый тип прокси - WEB proxy. В 7.1.2 его дошлифовали. Правка не косметическая: клиент упаковывает трафик MTProxy в обычное HTTPS/WebSocket-соединение с доменом, который снаружи выглядит как обычный сайт.
Для владельца канала, команды поддержки и человека в офисе с плотными сетевыми правилами расклад меняется. Раньше выбирали между скоростью и стабильностью. Теперь есть третий вариант, и по архитектуре он ближе к вебу, чем к телеграмовским протоколам.
Как работает WEB proxy на самом деле
Схема простая, если разложить по шагам. Telegram Desktop открывает встроенный мини-браузер (WebView), поднимает HTTPS-соединение с доменом и гоняет весь трафик через WebSocket внутри этого соединения. Отдельных портов и своего хендшейка на уровне сокета нет.
На сервере стоит relay. Он принимает один поток, разбирает его на отдельные соединения и пересылает в обычный MTProxy. Ключевой момент: relay ничего не расшифровывает. Он работает как сортировочный центр, а не как хранилище переписки. Расшифровка идет на конечном узле, и это принципиально для оценки рисков.
Домен живет двойной жизнью. Обычному посетителю отдает нормальную страницу. Клиенту Telegram после проверки показывает мостовую страницу и открывает туннель. Для сетевого инженера, который смотрит логи, это обращение к сайту, каких в потоке сотни. Поэтому WEB прокси для телеграмм обсуждают не только гики, но и сисадмины в компаниях.
Есть еще нюанс. Несколько соединений Telegram упаковываются в один поток. Это снижает число одновременных сессий наружу и экономит ресурсы клиента на слабых машинах. На старых ноутбуках и в мобильном роуминге разница заметна.
Чем это отличается от SOCKS5 и обычного MTProto
SOCKS5 - универсальный транспортный прокси. Ему все равно, что внутри: Telegram, браузер, клиент базы. Плюс в универсальности. Минус в том, что он открывает TCP-соединение напрямую, и по характеру трафика его видно легче. Для дома нормально, для корпоративного контура с DPI уже вопрос.
MTProto-прокси работает только с Telegram и знает структуру протокола. Он держит один канал на несколько устройств, аккуратно разводит потоки, экономит на хендшейках. Но у него есть свой почерк в трафике, и это слабое место.
WEB proxy - надстройка над MTProto. Он берет структуру телеграмовского прокси и заворачивает ее в веб-обертку. В большинстве сценариев это лучший компромисс из трех: скорость как у MTProto, профиль трафика как у обычного сайта.
Задержка важнее скорости, и вот почему
Люди при выборе прокси смотрят на скорость скачивания файлов. А страдают от пинга. Разница между 80 мс и 140 мс в текстовом чате не видна. В групповом звонке на двадцать человек она превращается в перебивания и неловкие паузы.
Смотреть надо на RTT до узла, стабильность RTT в течение дня и наличие узлов в регионе аудитории. Если команда сидит в Москве, а узел в Амстердаме, медиа будет тянуться с задержкой даже при гигабитной скорости.
Второй фактор - джиттер. Ровный пинг 90 мс ощущается лучше, чем скачущий от 40 до 300. Для голосовых сообщений и звонков это критичнее пиковой пропускной способности. Дешевый перегруженный узел с красивой цифрой в описании раздражает сильнее, чем средний, но с ровным каналом.
Свой VPS или готовый узел: считаем честно
Свой сервер имеет смысл, когда есть человек, который умеет в сертификаты, nginx, мониторинг и обновления. Минимальный инстанс обойдется в 200-300 рублей в месяц, плюс домен, плюс время на настройку. Время и есть самая дорогая часть: на поднятие и отладку уходит вечер, на поддержку - по чуть-чуть каждый месяц.
Для компании из пяти человек это нормальный вариант. Агентству, где прокси нужны под задачи клиентов, проще брать готовые узлы и не превращать инфраструктуру в отдельный проект. Тут выручает каталог: https://3seller.com/proxy. Там видно страны, протоколы, условия по трафику и ротации, без переписки с менеджером на два дня.
Мой критерий простой. Если задача разовая или нужна прямо сейчас, беру готовый узел. Если это инфраструктура на годы и есть кому ее обслуживать, поднимаю свой. Смешивать подходы в одном проекте почти всегда дороже, чем выбрать один.
Пошаговая настройка в десктопном клиенте
В Telegram Desktop откройте Настройки, затем Продвинутые настройки, затем Тип подключения. Там будет кнопка добавления прокси. Выбираете тип WEB proxy и вставляете ссылку или домен от провайдера.
Клиент сам проверит соединение и покажет статус. Если подключение не поднялось, проверьте, что домен вставлен целиком, вместе с параметрами из ссылки. Вторая частая причина - старый клиент. В версиях ниже 7.1.1 этого типа прокси нет в списке, и человек полчаса ищет кнопку, которой не существует.
На мобильных клиентах логика похожая: Настройки, Данные и память, Прокси, добавить. Интерфейс отличается, суть та же. Если ссылка пришла в чате, ее обычно достаточно нажать, и приложение предложит подключить автоматически.
Публичный Wi-Fi и корпоративные сети
В кафе, аэропорту и коворкинге трафик до точки доступа идет открытым. Прокси шифрует участок от устройства до узла. На чужой сети это минимум, который стоит сделать. Банковские приложения лучше не открывать. Разница с публичным бесплатным узлом огромная: там владелец сервера видит ваш трафик, а вы не видите ничего.
В корпоративном контуре другая история. Компании часто режут все, кроме 443 порта. WEB proxy как раз про это: он живет на стандартном HTTPS, и сетевому администратору не нужно открывать дыры в правилах. Удобно и сотруднику, и безопаснику, который не хочет исключений ради одного мессенджера.
Четыре типовые поломки
Первое - истекший сертификат на домене. Симптом неприятный: соединение вроде есть, но медиа не грузится. Второе - перегруз узла. Когда на сервер садится втрое больше людей, чем он рассчитан, первым умирает видео, потом голосовые, потом текст.
Третье - MTU и фрагментация. На некоторых провайдерах большие пакеты режутся, и соединение рвется на длинных файлах. Лечится подбором узла или снижением MTU на стороне сервера, если он ваш.
Четвертое, самое обидное, - домен перестал отвечать. Поэтому в серьезной работе держат два-три узла в запасе и переключаются за минуту, а не ищут новый адрес по чатам. Каталог с живыми узлами экономит нервы: 3seller.com/proxy.
Балансировка и несколько узлов
Когда устройств больше пяти, ручное переключение превращается в цирк. Нормальная схема: разные узлы под разные задачи. Один под переписку и звонки, второй под загрузку медиа и архивов, третий резервный.
Для распределенной команды полезно разводить трафик по географии. Клиенты в Европе идут через европейский узел, в Азии через азиатский. Это снижает задержку и разгружает каналы. Прирост от такой схемы заметнее, чем от смены тарифа на более дорогой.
Парсинг, аналитика и рабочие задачи
Отдельная история - сбор данных. Мониторинг упоминаний бренда, анализ открытых каналов, статистика по конкурентам. Telegram быстро начинает ограничивать частоту запросов с одного адреса. Здесь важна не скорость, а количество независимых сессий и их стабильность.
Для таких задач берут пул адресов с ротацией. Адреса должны быть из разных подсетей, иначе смысла в пуле нет. И провайдер не должен смешивать ваш пул с чужим, где уже кто-то нашумел. В каталоге это видно по описанию: выделенные или общие, с ротацией по запросу или по времени.
Еще один практический момент. Парсинг через мобильные прокси дороже, но у него выше выживаемость сессий. Через серверные дешевле, но часть задач требует именно мобильных адресов. Считать надо не по цене за гигабайт, а по цене за успешно собранную единицу данных. Разница в итоге может быть трехкратной.
Как выбирать провайдера без иллюзий
Публичные бесплатные узлы годятся для проверки, что все работает. Для работы не подходят: владелец видит трафик, uptime никто не гарантирует, узел исчезает без предупреждения. Экономия в триста рублей оборачивается потерянным вечером.
Пять проверок выглядят так. Наличие нужного типа прокси (WEB proxy поддерживают не все). География узлов. Условия ротации. Скорость ответа поддержки: если человек отвечает за десять минут в час дня, он ответит и в три ночи, когда у вас упадет все.
Пятая проверка - тест на своей задаче. Не на тесте скорости, а на реальном сценарии: позвонить в группу, отправить файл на 300 МБ, открыть канал с медиа. Пять минут такой проверки дают больше, чем таблица характеристик.
Первый шаг: проверить тип прокси
Откройте настройки подключения в своем клиенте и посмотрите, какой тип прокси стоит. Если там SOCKS5 или старый MTProto, попробуйте WEB proxy на том же узле и сравните пинг в звонке. Разница обычно слышна сразу, и это самый честный тест.
Если своего узла нет, начните с готового: каталог прокси 3seller. Возьмите один узел в нужной географии, погоняйте сутки на реальных задачах и только потом решайте, нужен ли второй и стоит ли поднимать свой сервер. Такой порядок экономит деньги и время.