Два слоя Telegram: битые топики и глушение MTProto

«Если сообщение не дошло, виноват не обязательно бот» — фраза, которую я повторял себе два дня подряд, разбирая две поломки Telegram, случившиеся друг за другом и оказавшиеся совсем не связанными. Одна — серверная регрессия топиков, вторая — сетевая блокировка протокола. Делюсь методикой.

Контекст

В домашнем хозяйстве живёт self-hosted Telegram-бот-агент: принимает голосовые и текстовые команды, ходит в LLM, управляет инструментами. Часть уведомлений бота раньше была переведена на зарубежный VPS — российский канал время от времени деградировал. Роутер MikroTik держит раздельную маршрутизацию. Этот фон важен: обе поломки выглядели как «Telegram сломался», но причина каждый раз была своя.

Слой первый: серверная регрессия топиков

Симптом: в личном чате с ботом перестали доходить сообщения в новых топиках. Приложение при этом честно показывает галочку «отправлено». Старые топики продолжают работать.

Логи Bot API поставили диагноз:

Bot_topic_wrong_home

Серверная сторона считала свежесозданный топик «не тем домом» для бота. Это не мой код и не мой конфиг — регрессия на стороне Telegram API.

Воркараунды, пока чинят upstream

писать в корень личного чата: Bot API при ошибке откатывает доставку в последний существующий топик;
не создавать новые топики, а переименовывать старые — семантика та же, доставка живая.

Оба воркараунда выросли не из догадок, а из кода: PR с фолбэком доставки в последний топик — как раз то, на чём и держится «писать в корень».

Репорты в upstream

Найденное оформлено репортами (оба подтверждены мейнтейнерами):

issue #905 в telegram-bot-api — серверная регрессия Bot_topic_wrong_home на новых топиках личного чата;
issue в репозитории самого агента — описание поведения на стороне клиента и связка с PR фолбэка доставки.

Слой второй: «часики» и MTProto DC2

Параллельно с топиками возник второй симптом: Telegram Desktop через зарубежный VPS висит на «часиках» — сообщения не уходят. При этом бот по Bot API через тот же VPS работает идеально.

Вот здесь легко сделать ложный вывод «VPS сломан». Разбор показал другое:

клиентский трафик Telegram ходит по MTProto, и подсеть дата-центра №2 (149.154.167.0/24) глушится ТСПУ именно на зарубежном маршруте;
Bot API — обычный HTTPS-эндпоинт, ему всё равно;
значит, «часики» на десктопе и живой бот — не противоречие, а два разных слоя одной инфраструктуры.

Решение — сплит-роутинг на MikroTik: подсеть MTProto DC2 уходит через российский канал, остальной трафик Telegram остаётся на VPS.

Проверка, что виноват маршрут, а не клиент: телефон через тот же VPS воспроизводил проблему один в один.

Грабли диагностики, чтобы не повторять

curl к MTProto-edge невалиден. Это не HTTP: успешный TCP-коннект ничего не доказывает. Проверять надо живым клиентом или на уровне пакетов.
MSS-clamp на зарубежном канале — мина. Менять его «на всякий случай» нельзя без полной проверки канала: маскирует реальные симптомы.
Один и тот же сервис в разных сетях — разный зверь: часть проблем раньше лечили переводом на VPS, теперь оказалось, что и у VPS-маршрута есть своя слепая зона.

Методика: разделяй слои

Главный вывод вечера — у «неработающего Telegram» в российских сетях минимум два независимых слоя:

Слой	За что отвечает	Как ломается	Как проверять
Серверный Bot API	доставка ботам	регрессии API, доступность эндпоинта	логи Bot API, коды ошибок
Клиентский MTProto	доставка пользователям	блокировки/деградация на маршруте (ТСПУ)	живой клиент через подозреваемый маршрут

«Часики» на десктопе не означают, что бот недоступен — и наоборот. Диагностировать оба слоя одним тестом нельзя: у меня за два дня сломались оба, и каждое лечение было своим.

Результаты

Бот жив: доставка восстановлена воркараундами, репорты ушли мейнтейнерам.
Десктоп жив: сплит-роутинг вернул MTProto-клиенту нормальный маршрут.
Сетевая картина стала симметричной: у каждого канала — свой понятный набор рабочих сервисов.

Ограничения и открытые вопросы

Воркараунды — временные: серверная регрессия чинится на стороне Telegram, issue #905 мейнтейнеры закрыли как исправленный (10.11.2026) — останется снять воркараунды после обновления Bot API.
Поведение ТСПУ на маршрутах со временем меняется — сплит-роутинг потребует сопровождения.

Выводы

Когда «всё сломалось сразу», начинайте с разделения слоёв: транспорт против приложения, сервер против клиента. В моём случае один симптом лечился кодом воркараунда в боте, второй — одной строкой маршрута на роутере. Смешать их — значит потратить вечер на диагностику несуществующей проблемы.

Источники

Обсудить в Telegram