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() или что-то более лёгкое?