在 VPS 上 7×24 跑一个 Telegram 机器人：aiogram、systemd、轮询 vs webhook

你用 aiogram 写了一个 Telegram 机器人、在本地测过、它能用。现在它得住在一个你合上笔记本时不会睡眠的地方。一台小 VPS 是天然的家——但从 SSH 会话里的 python bot.py 到一个真正能熬过崩溃、重启和你连接掉线的机器人，中间有一道坎。

这是生产版本：一个 virtualenv、token 放在代码之外、一个自己复活机器人的 systemd 服务，以及对每个人最终都会问的那个问题的清醒回答——轮询还是 webhook？

为什么不直接在笔记本上跑

一个机器人需要一条到 Telegram 的稳定出站连接。你的笔记本会睡眠、为更新重启、在网络间跳——这里每一样都让机器人掉线，用户撞上一片沉默。一台 VPS 全天候保持那条连接。那就是把它从你机器上搬走的全部理由，也是一个 Discord 机器人也该待在服务器上的同一个理由。

如果你只想要用一个极简机器人最快“让它上线”的路径，托管 Telegram 机器人走查讲了那个。本篇更深一层：aiogram、安全的 token 处理，以及知道何时该扩容。

机器人，装在 virtualenv 里

SSH 进去、把机器人隔离在它自己的 venv 里——别全系统装包，那会让以后的升级和清理一团糟：

sudo apt update && sudo apt install -y python3-venv
mkdir ~/tgbot && cd ~/tgbot
python3 -m venv venv && source venv/bin/activate
pip install -U aiogram

一个从环境读 token、而不是从硬编码字符串读的极简 aiogram 3 机器人：

# bot.py
import asyncio, logging, os
from aiogram import Bot, Dispatcher
from aiogram.types import Message
from aiogram.filters import CommandStart

logging.basicConfig(level=logging.INFO)
dp = Dispatcher()

@dp.message(CommandStart())
async def start(m: Message):
    await m.answer("Alive and running on a VPS.")

async def main():
    bot = Bot(os.environ["BOT_TOKEN"])
    await dp.start_polling(bot)

if __name__ == "__main__":
    asyncio.run(main())

把 token 放在代码之外

永远别把 BotFather 的 token 粘进 bot.py——往公开仓库一推它就泄露了。改把它放在一个 root 可读的环境文件里：

sudo tee /etc/tgbot.env >/dev/null <<'EOF'
BOT_TOKEN=123456:your-token-from-botfather
EOF
sudo chmod 600 /etc/tgbot.env

一个泄露的 token，在 BotFather 里一个 /revoke 就修好了——但一台共享机器上泄露别的任何东西更糟。一台给机器人专用的 VPS，老实说比你的日常笔记本更适合放 token：如果泄露，你轮换一个 token，而不是你整套配置。

让它保活的部分：systemd

这是一个能跑的机器人和一个保持运行的机器人之间的分界。创建服务：

# /etc/systemd/system/tgbot.service
[Unit]
Description=Telegram bot (aiogram)
After=network-online.target
Wants=network-online.target

[Service]
User=botuser
WorkingDirectory=/home/botuser/tgbot
EnvironmentFile=/etc/tgbot.env
ExecStart=/home/botuser/tgbot/venv/bin/python bot.py
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

以一个非 root 用户（上面的 botuser）跑它，而不是 root——万一机器人被攻陷，你想让它被关在盒子里。然后：

sudo systemctl daemon-reload
sudo systemctl enable --now tgbot

Restart=always 配 RestartSec=3 意味着一次崩溃——Telegram 的一次坏更新、一个未处理的异常、一次 OOM——让机器人在三秒内回来，而不是让它死着直到你注意到。实时看它：

journalctl -u tgbot -f

那就是你全部的日志配置。没有日志文件要轮转、没有额外工具——journald 已经有了。

无停机戏剧地更新

当你改代码或升级 aiogram：

cd ~/tgbot && source venv/bin/activate
pip install -U aiogram          # 如果升级库
sudo systemctl restart tgbot
journalctl -u tgbot -n 30 --no-pager   # 确认它干净地回来了

重启让机器人闪断一两秒。对一个轮询机器人，那对用户是隐形的——Telegram 把更新排队、在机器人重连后送达。

轮询 vs webhook——诚实的版本

这是人们想太多的决定。这是大白话版本：

轮询（start_polling，上面代码用的）让机器人在一条长连接上问 Telegram“有新东西吗？”。它除了出站网络什么都不需要——不用域名、不用 TLS、不用开入站端口。它在 NAT 后面跑得好好的。对绝大多数机器人，这是对的，你该停在这里。

Webhook 让 Telegram 把更新推给你，这意味着你必须暴露一个公网 HTTPS 端点。那需要一个域名和一个可达的入站端口——所以要么一个独立公网 IP、要么前面一个反向代理。更多搭建、更多会坏的东西。回报是在大规模下更低的延迟和更少的开销——成千上万并发用户、大量更新。

实用规则：在一个 NAT 套餐上从轮询开始。 只有当你真正长过轮询时才转 webhook——如果你转了，那时一个独立IP才配得上它的位置，因为你需要那个入站 HTTPS 端点。

跑它要花多少

一个轮询机器人很轻。它在 Telegram 的长轮询上空闲、对消息做反应，所以机器大多在等：

• $3 Nano（2 vCPU / 1 GB） —— 对大多数机器人没问题，甚至相当话痨的。
• $5 Micro（2 vCPU / 2 GB） —— 当机器人带一个数据库（SQLite/Postgres）、处理媒体、或服务很多用户。
• 只有当机器人自己做真活时才更高——图像处理、本地模型、每条消息的重逻辑。

注册只用邮箱，你用 Base 或 Ethereum 上的 USDC 或 USDT 付款——不用卡、不用证件。银行卡也能用，但 on-ramp 有约 $27 的最低额，所以对一个 $3 套餐，一次充一小笔余额、让续费从里面扣更顺。它是纯 CPU、在德国和芬兰两个地点（下单时可以看到哪个可用）——对机器人不是问题，如果你需要 GPU 或某个特定地区，知道一下也好。

诚实的一句话

一个 Telegram 机器人是你能自托管的最便宜的东西之一：一台 $3 机器、一个 systemd unit、加轮询，就给你一个熬过崩溃和重启、不用你照看的在线机器人。只有当规模真的逼着你时，才去上 webhook 和更大的套餐——而不是因为某个教程告诉你 webhook“更好”。拿那台小机器、把 token 放在环境文件里、让 systemd 管正常运行时间，并——在别的一切之前——跑一遍新 VPS 安全清单，好让机器本身锁得严实。

准备好托管你的了？ 一个 Telegram 机器人几乎不占资源——Nano 套餐（$3/月） 就能 7×24 不费劲地跑它。