Aiogram 3机器人断网后无法自动恢复问题及解决方案咨询
解决Aiogram 3机器人断网后无法自动恢复的问题
一、修复Aiogram内置重连逻辑
Aiogram 3本身支持配置连接重试策略,结合外层异常捕获循环,就能稳定处理网络波动:
配置网络重试策略
初始化Bot时,通过aiohttp-retry实现指数退避重试,覆盖常见网络异常:from aiogram import Bot, Dispatcher from aiogram.client.default import DefaultBotProperties from aiogram.session.aiohttp import AiohttpSession from aiohttp_retry import RetryClient, ExponentialRetry # 指数退避重试:最多5次,捕获连接/超时/系统异常 retry_strategy = ExponentialRetry( attempts=5, exceptions={ConnectionError, TimeoutError, OSError} ) # 带重试的会话 session = AiohttpSession(client=RetryClient(retry_strategy=retry_strategy)) bot = Bot( token="YOUR_BOT_TOKEN", session=session, default=DefaultBotProperties(parse_mode="HTML") ) dp = Dispatcher()外层异常捕获与重启逻辑
将启动逻辑包裹在循环中,捕获全局异常并重试,同时添加管理员通知:import asyncio import logging logging.basicConfig(level=logging.INFO) logger = logging.getLogger(__name__) ADMIN_CHAT_ID = 123456789 # 替换为管理员实际聊天ID async def send_admin_alert(bot: Bot): try: await bot.send_message(ADMIN_CHAT_ID, "Bot run again") except Exception as e: logger.error(f"发送重启通知失败: {e}") async def main(): while True: try: await dp.start_polling(bot) except (ConnectionError, TimeoutError) as e: logger.warning(f"网络异常,即将重启机器人: {e}") await asyncio.sleep(10) # 10秒后重试,避免频繁请求 except Exception as e: logger.error(f"未知错误,即将重启机器人: {e}") await asyncio.sleep(30) finally: # 重启成功后发送通知 await send_admin_alert(bot) if __name__ == "__main__": asyncio.run(main())
二、之前方案失效的原因
- psutil进程检测:可能机器人进程未完全退出(处于僵死状态),导致检测逻辑无法触发重启;或进程识别规则错误,误判进程状态。
- 简单while循环:未覆盖Aiogram运行中的所有异常(如API调用超时、会话失效等),导致循环提前终止。
三、系统级兜底保障
如果代码层重连仍不稳定,可借助系统守护进程实现进程级自动重启:
- Linux使用systemd:创建
my_bot.service文件:
执行以下命令启用:[Unit] Description=Aiogram Bot Service After=network.target [Service] User=your_username WorkingDirectory=/path/to/your/bot ExecStart=/usr/bin/python3 /path/to/your/bot/main.py Restart=always RestartSec=10 [Install] WantedBy=multi-user.target
该配置会在进程崩溃/退出时自动重启,与代码层重连形成双重保障。sudo systemctl daemon-reload sudo systemctl start my_bot.service sudo systemctl enable my_bot.service
四、注意事项
- 合理设置重试间隔,避免因频繁请求触发Telegram API限流。
- 管理员通知需放在可靠的执行分支(如
finally块),确保仅在机器人真正恢复时发送,避免重复通知。
内容的提问来源于stack exchange,提问作者Rostik Stadnikov
相关产品推荐
相关产品推荐

