Как я решил проблему с недоступностью Telegram Bot API через собственный прокси

С проблемой недоступности Telegram я столкнулся не в теории, а на практике. В какой-то момент в России Telegram стал недоступен, и вместе с этим перестали нормально работать сервисы, которые использовали его для уведомлений. Особенно это коснулось интеграций через api.telegram.org: боты не могли отправлять сообщения, мониторинг молчал, а внутренние системы перестали присылать важные события.

И, как оказалось, я был не один. Многие личные и корпоративные сервисы давно используют Telegram как простой и удобный канал уведомлений: help desk сообщает о новых тикетах, Zabbix присылает алерты, внутренние скрипты уведомляют о сбоях, а кто-то, как я, ещё и пишет собственных Telegram-ботов под рабочие задачи.

В чём была проблема

Обычно бот или сервис отправляет запросы напрямую на официальный адрес Telegram Bot API:

https://api.telegram.org

Когда доступ к этому адресу пропадает, перестают работать отправка сообщений, получение обновлений и другие методы Bot API. При этом проблема не в самом боте и не в коде: токен правильный, настройки не менялись, но сервер просто не может достучаться до Telegram.

Как я это исправил

Решение оказалось достаточно простым: я поднял небольшой VPS за рубежом, где доступ к Telegram работает стабильно, и организовал на нём собственный HTTP-прокси. Теперь мои сервисы обращаются не напрямую к api.telegram.org, а к моему домену, например:

https://tg-proxy.example.com

А уже этот сервер пересылает запросы дальше в Telegram Bot API. Для приложений почти ничего не меняется: вместо официального адреса Telegram указывается адрес моего прокси.

Архитектура решения

Схема получилась простой:

Сервис / Zabbix / Help Desk / бот
        ↓
Nginx Proxy Manager с доменом и SSL
        ↓
Docker-контейнер с proxy-приложением
        ↓
api.telegram.org

Снаружи запросы принимает Nginx Proxy Manager. Он отвечает за домен, SSL-сертификат Let’s Encrypt и проксирование HTTPS-запросов на контейнер. Само proxy-приложение запущено в Docker, чтобы его было легко обновлять, переносить и автоматически перезапускать после перезагрузки сервера.

Что делает прокси

Прокси принимает запрос от внутреннего сервиса и пересылает его в Telegram. Например, если сервис обращается к:

https://tg-proxy.example.com/bot<TOKEN>/sendMessage

то прокси отправляет этот же запрос на:

https://api.telegram.org/bot<TOKEN>/sendMessage

При этом сохраняются HTTP-метод, путь, параметры и тело запроса. Прокси не разбирает логику бота, а просто выступает промежуточным звеном между сервисом и Telegram API.

Зачем нужны логи

Отдельно я сделал логирование запросов и ответов. Это сильно помогает при диагностике: видно, дошёл ли запрос до прокси, что именно отправил сервис, какой код ответа вернул Telegram и где возникла ошибка — в токене, chat_id, параметрах запроса или доступности самого API.

Логи удобно хранить на сервере через Docker volume, например в файле:

./logs/proxy.log

Что важно учесть по безопасности

Такой прокси нельзя оставлять полностью открытым. Через него проходят токены Telegram-ботов и текст служебных уведомлений. Поэтому обязательно нужно использовать HTTPS, ограничить доступ по IP, не публиковать адрес прокси в открытом доступе, настроить firewall и ротацию логов.

Итог

Собственный Telegram Bot API proxy — простой способ вернуть работу уведомлений, если серверы не могут напрямую обращаться к api.telegram.org. В моём случае это помогло сохранить уведомления от help desk, Zabbix и собственных ботов без серьёзной переделки существующей инфраструктуры.

По сути, меняется только адрес API, а вся логика сервисов остаётся прежней. Внутренние системы отправляют запросы на мой домен, Nginx Proxy Manager принимает HTTPS, Docker-контейнер пересылает запросы в Telegram, а ответ возвращается обратно приложению.

Статью подготовил: Галявиев Руслан.