Дополню про прокси, потому что на этой строчке многие спотыкаются.
127.0.0.1:1080 сработает только если на этом порту у вас реально
кто-то слушает. Большинство VPN-клиентов (WireGuard, OpenVPN и почти все
десктопные приложения) работают на уровне TUN-интерфейса и заворачивают
весь системный трафик — локальный SOCKS5 они при этом не поднимают.
Скопируете строку как есть и получите ConnectionRefusedError, после чего
будете думать, что дело в Telethon.
Проверить за секунду:
curl --socks5 127.0.0.1:1080 -s -o /dev/null -w "%{http_code}\n"
https://api.telegram.org
ss -ltn | grep 1080 # на Linux
netstat -ano | findstr 1080 # на Windows
Пусто — значит SOCKS5 у вас нет. Локальный SOCKS5 дают: ssh -D 1080
на свой сервер, Tor (порт 9050), xray/v2ray, Shadowsocks. Обычный
VPN-клиент — нет.
Теперь главное. Судя по логам, у вас есть bot_token — то есть вы делаете
бота, а не юзербота. Тогда MTProto вам, скорее всего, не нужен вообще.
Telethon ходит по MTProto, и для DPI этот протокол выглядит характерно,
поэтому режется охотнее. Bot API работает по обычному HTTPS на
api.telegram.org. С той же машины, где Telethon даёт TcpFull и таймауты,
Bot API часто отвечает без всяких прокси. Проверяется одной командой:
curl
https://api.telegram.org/bot/getMe
Ответил — значит канал живой, и проблема была в протоколе, а не в сети.
Тогда берите aiogram или python-telegram-bot, и вопрос с прокси
закрывается сам.
Telethon оправдан, только если нужны функции обычного аккаунта, которых
в Bot API нет: читать чужие чаты, работать от лица пользователя,
доставать историю. Если этого в задаче нет — переезд решает проблему,
а не обходит её.
Если всё-таки остаётесь на Telethon с прокси, учтите: прокси становится
единственной точкой отказа. Упал — упал бот. Ставьте явные таймауты,
автопереподключение и проверку прокси перед использованием, иначе
клиент будет висеть молча.