Production MTProto user-бот на FastAPI + Telethon: WARP для обхода DPI и 5 граблей с Telegram

[horyzon]

Отличный разбор. Пять граблей — все рабочие, сам наступал.

Два дополнения из своего опыта:

1. Session-string в .env — это ключевой риск. Автор правильно говорит «не коммитить». Добавлю: даже в рантайме session-string лучше держать не в переменной окружения, а в tmpfs (если контейнер) или в файле с 0600. Если злоумышленник получит доступ к /proc//environ — сессия утекает. У нас в ATP все секреты идут через Fernet-шифрование + in-memory keyring, сессия расшифровывается только при старте lifespan.

2. WARP как single point of failure. Автор пишет что WARP не падал — везёт. У меня был кейс когда warp-cli ушёл в registration loop после обновления CF-сертификатов, и сервис молча лежал 40 минут. После этого добавил healthcheck с fallback на резервный MTProto-прокси (свой на foreign VPS за $5). Два канала — WARP основной, прокси резервный. Переключение по таймауту 10 секунд.

В остальном — архитектура с n8n → FastAPI → Telethon чистая. Особенно оценка что 90% стабильности это обработка edge cases, а не бизнес-логика. Так и есть.

[viktdo]

Спасибо, оба пункта по делу - добавляю их в мысленный пул на «что в архитектуре стоит дотянуть».

По session-string безопасности. У нас сейчас компромисс попроще: .env с правами 0600 + systemd unit под отдельным пользователем, plus директива EnvironmentFile= (читается только при старте сервиса, не висит в /proc). Идея с Fernet + in-memory keyring сильная: для систем где session это эквивалент банковского пароля (а с точки зрения Telegram security именно так и есть) это правильный уровень. tmpfs тоже отличный поинт, на новых проектах буду стартовать с этого.

По WARP как SPOF. Откровенно повезло, кейс с registration loop после CF-сертификатов не знал, добавлю в свой checklist «что мониторить». Сейчас единственная защита от WARP-падения у меня это systemd Requires=warp-svc.service который перестартует контейнер при отвале, но если warp-cli ушёл в нагруженный loop как у вас, это не поможет. Fallback на foreign-MTProxy за $5/мес с переключением по 10 секундам, это правильное решение для систем где downtime критичен. В моём кейсе 40 минут downtime = специалисты не могут попасть в чат проекта, заметят но не блокирует бизнес. На критичных интеграциях (платежи, рассылки) сделал бы как вы.

Интересно: у вас MTProxy на foreign VPS свой, или используете публичный? И как формируете healthcheck для переключения, client.get_me() или что-то более лёгкое?

[PM_Inna_Ka]

Хорошая систематизация — у нас похожая история, но с противоположной стороны: не запись (создание групп/добавление юзеров), а чтение. Задача была прочитать конкретное сообщение из форум-супергруппы через обычного Bot API бота, без MTProto. Оказалось, что Bot API в принципе не даёт «зайти и посмотреть историю» — только copyMessage/forwardMessage по уже известному message_id, либо то, что реально прилетело через getUpdates/webhook. Enumerate/перебор соседних ID для угадывания нужного сообщения — уже не техническое ограничение, а прямая дыра в приватности чужой переписки, так что это тупик и по этическим, не только по API-причинам. Отдельно споткнулись о то, что ID топика форума совпадает с message_id его служебного сообщения-создания — а такое служебное сообщение само не копируется и не форвардится («the message can't be copied»), что сначала выглядело как баг, а на деле оказалось ожидаемым поведением. В итоге единственный законный путь для бота — либо дождаться сообщения живьём через getUpdates, либо использовать getChat→pinned_message, если что-то реально закреплено. Ваш кейс с access_hash в MTProto и наш с message_id в Bot API — по сути одна и та же тема: обе части Telegram API спроектированы так, что программно можно уверенно оперировать только тем, что система уже «показала» этой конкретной сессии/боту, а не тем, что просто существует в чате.