WEB-прокси Telegram помогает клиенту, но не инфраструктуре бота

В Telegram Desktop 7.1.0 появился новый тип подключения — WEB proxy. Его уже успели описать как способ, с помощью которого Telegram может выглядеть для сети как обычный HTTPS-сайт.

Если сильно упростить официальное описание архитектуры, работает это так:

1. Клиент сохраняет обычный MTProxy framing и шифрование.

2. Соединения проходят через скрытый WebView внутри приложения.

3. WebView передаёт несколько логических потоков через один или несколько HTTPS- либо WebSocket-соединений с тем же доменом.

4. Серверный 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 или ограничиваетесь метриками самого приложения?