WEB-прокси Telegram помогает клиенту, но не инфраструктуре бота
В Telegram Desktop 7.1.0 появился новый тип подключения — WEB proxy. Его уже успели описать как способ, с помощью которого Telegram может выглядеть для сети как обычный HTTPS-сайт.
Если сильно упростить официальное описание архитектуры, работает это так:
Клиент сохраняет обычный MTProxy framing и шифрование.
Соединения проходят через скрытый WebView внутри приложения.
WebView передаёт несколько логических потоков через один или несколько HTTPS- либо WebSocket-соединений с тем же доменом.
Серверный relay разделяет потоки и передаёт каждый локально запущенной официальной реализации MTProxy.
При этом relay видит только непрозрачный поток данных: он не расшифровывает содержимое и не выбирает Telegram-сервер назначения.
Указанный домен продолжает работать как обычный HTTPS-сайт. Если запрос не содержит корректного capability, вычисленного из домена и секрета WEB-прокси, посетитель получает публичную страницу. Bridge открывается только клиенту с правильными параметрами подключения.
Сейчас готовая реализация работает в Telegram Desktop. Для Android существует экспериментальный клиент, а поддержка iOS пока описана только в планах проекта.
Что это меняет для разработчика бота
Сам WEB-прокси обслуживает соединение Telegram-клиента с инфраструктурой мессенджера. Он не становится общим туннелем для всех компонентов продукта.
По-прежнему существуют отдельные сетевые контуры:
Telegram Desktop пользователя → WEB-прокси → Telegram;
сервер бота → api.telegram.org;
Telegram → webhook endpoint бота;
Mini App → домен, на котором размещено веб-приложение.
Если сервер бота потеряет доступ к api.telegram.org, результат будет зависеть от способа получения обновлений.
При long polling бот перестанет и получать обновления, и вызывать методы Bot API.
При webhook входящие обновления ещё могут приходить, если endpoint доступен извне. Однако обычные исходящие обращения к Bot API работать не будут. Есть редкое исключение: Telegram разрешает передать один метод Bot API прямо в HTTP-ответе на webhook. Но узнать результат выполнения такого метода бот уже не сможет.
WEB-прокси также не восстановит недоступный webhook и не поможет загрузить Mini App, если проблема возникла с доменом самого веб-приложения.
Это не недостаток новой технологии. Просто WEB-прокси решает задачу доступности клиента, а не отказоустойчивости сторонней инфраструктуры.
Что по-прежнему остаётся на стороне разработчика
Для long polling нужно отдельно контролировать доступность Bot API и задержку получения обновлений.
Для webhook полезно отслеживать через getWebhookInfo как минимум:
pending_update_count;
last_error_date;
last_error_message.
Обработку обновлений лучше делать идемпотентной: если webhook отвечает кодом вне диапазона 2xx, Telegram повторяет доставку. А слепой повтор исходящих методов вроде sendMessage, наоборот, способен создать дубли.
Получается, фраза «Telegram у пользователя открылся» ещё не означает, что бот, webhook и Mini App тоже работают.
Подскажите, держите ли для Bot API резервный egress или HTTPS-прокси? И состояние webhook вы контролируете через getWebhookInfo или ограничиваетесь метриками самого приложения?
