Polling hay webhook — tôi nên dùng cái nào?

Bắt đầu với polling. Nó hoạt động từ bất kỳ cỗ máy nào có internet đi ra — không tên miền, không cổng mở, không TLS — và nó dư dả cho hầu hết các bot. Chuyển sang một webhook chỉ khi bạn chạy ở quy mô (hàng nghìn người dùng) hoặc cần độ trễ thấp nhất có thể; một webhook cần một endpoint HTTPS công khai, nghĩa là một tên miền và một cổng đến tới được (một IP riêng, hoặc một reverse proxy), nên nó là nhiều phần chuyển động hơn. Cho 95% các bot, polling trên một VPS nhỏ là câu trả lời đúng.

Tôi có cần một IP riêng hoặc một tên miền cho một Telegram bot không?

Không cho polling — bot chỉ tạo các cuộc gọi đi ra tới Telegram, nên một gói NAT với SSH chuyển tiếp cổng là đủ. Bạn cần một endpoint HTTPS công khai (tên miền + cổng đến, tức là một IP riêng hoặc reverse proxy) chỉ nếu bạn chuyển sang chế độ webhook. Hầu hết các bot không bao giờ cần nó.

Một bot aiogram cần VPS kích cỡ nào?

Cái nhỏ nhất. Một bot polling chủ yếu chờ long-poll của Telegram, nên 1 vCPU / 1 GB (một Nano $3) xử lý hầu hết các bot thoải mái. Nâng kích cỡ chỉ khi bản thân bot làm việc nặng — một cơ sở dữ liệu, xử lý media, hoặc một mô hình cục bộ — điều đẩy bạn tới 2 GB ($5) hoặc hơn.

Làm sao giữ bot chạy sau khi tôi đăng xuất?

Chạy nó như một dịch vụ systemd với Restart=always. Khởi chạy trong terminal của bạn nó chết khi SSH đóng; dưới systemd nó sống sót qua đăng xuất, khởi động lại khi sập, và trở lại sau một lần khởi động lại. Đó là ranh giới giữa một demo và một thứ bạn có thể dựa vào.

Chạy một Telegram bot 24/7 trên một VPS: aiogram, systemd, polling so với webhook

Bạn đã viết một Telegram bot với aiogram, kiểm thử nó cục bộ, và nó hoạt động. Giờ nó phải sống ở đâu đó không ngủ khi bạn đóng laptop. Một VPS nhỏ là ngôi nhà tự nhiên — nhưng có một khoảng cách giữa python bot.py trong một phiên SSH và một bot thực sự ở lại lên qua các lần sập, khởi động lại, và kết nối của bạn rớt.

Đây là phiên bản production: một virtualenv, token giữ khỏi mã của bạn, một dịch vụ systemd hồi sinh bot một mình, và một câu trả lời rõ ràng cho câu hỏi ai cũng cuối cùng hỏi — polling hay webhook?

Sao không chỉ chạy nó trên laptop của bạn

Một bot cần một kết nối đi ra ổn định tới Telegram. Laptop của bạn ngủ, khởi động lại để cập nhật, và nhảy giữa các mạng — mỗi cái trong đó rớt bot, và người dùng đâm vào một bức tường im lặng. Một VPS giữ kết nối đó suốt ngày đêm. Đó là toàn bộ lý do chuyển nó khỏi máy của bạn, và nó là cùng lý do một Discord bot thuộc về một máy chủ nữa.

Nếu bạn chỉ muốn con đường "đưa nó online" nhanh nhất có thể với một bot tối thiểu, hướng dẫn host-một-Telegram-bot bao quát điều đó. Bài này đi một mức sâu hơn: aiogram, xử lý token an toàn, và biết khi nào mở rộng.

Bot, trong một virtualenv

SSH vào và giữ bot cô lập trong venv của riêng nó — đừng cài các gói toàn hệ thống, nó làm nâng cấp và dọn dẹp thành một mớ sau này:

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

Một bot aiogram 3 tối thiểu đọc token của nó từ môi trường, không phải từ một chuỗi hard-code:

# 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())

Giữ token khỏi mã của bạn

Đừng bao giờ dán token BotFather vào bot.py — một lần push tới một repo công khai và nó rò rỉ. Đặt nó trong một tập tin env root-đọc-được thay vào đó:

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

Một token rò rỉ cách một /revoke trong BotFather là được sửa — nhưng một thứ gì khác rò rỉ trên một cỗ máy dùng chung tệ hơn. Một VPS chuyên dụng cho bot thành thật là một ngôi nhà an toàn hơn cho token so với laptop hằng ngày của bạn: nếu nó rò rỉ, bạn xoay một token, không phải cả thiết lập của bạn.

Phần giữ nó sống: systemd

Đây là cái tách một bot chạy khỏi một bot ở lại chạy. Tạo dịch vụ:

# /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

Chạy nó như một người dùng không-root (botuser ở trên), không phải root — nếu bot có bao giờ bị xâm nhập, bạn muốn nó bị đóng hộp. Rồi:

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

Restart=always với RestartSec=3 nghĩa là một lần sập — một cập nhật tồi từ Telegram, một ngoại lệ không được xử lý, một OOM — đưa bot trở lại trong ba giây thay vì để nó chết cho tới khi bạn để ý. Xem nó trực tiếp:

journalctl -u tgbot -f

Đó là toàn bộ thiết lập log của bạn. Không tập tin log để xoay, không công cụ thêm — journald đã có nó.

Cập nhật không kịch tính downtime

Khi bạn đổi mã hoặc nâng aiogram:

cd ~/tgbot && source venv/bin/activate
pip install -U aiogram          # nếu nâng cấp thư viện
sudo systemctl restart tgbot
journalctl -u tgbot -n 30 --no-pager   # xác nhận nó trở lại sạch

Lần khởi động lại làm bot chớp một hai giây. Cho một bot polling điều đó vô hình với người dùng — Telegram xếp hàng các cập nhật và giao chúng một khi bot kết nối lại.

Polling so với webhook — phiên bản trung thực

Đây là quyết định người ta nghĩ quá nhiều. Đây là phiên bản thẳng:

Polling (start_polling, cái mã ở trên dùng) cho bot hỏi Telegram "có gì mới không?" trên một kết nối tồn tại lâu. Nó không cần gì ngoài internet đi ra — không tên miền, không TLS, không cổng đến mở. Nó chạy tốt sau NAT. Cho đại đa số các bot, đây là đúng và bạn nên dừng ở đây.

Webhook cho Telegram đẩy các cập nhật tới bạn, nghĩa là bạn phải phơi một endpoint HTTPS công khai. Điều đó đòi hỏi một tên miền và một cổng đến tới được — nên hoặc một IP công khai riêng hoặc một reverse proxy ở phía trước. Nhiều thiết lập hơn, nhiều thứ vỡ hơn. Phần thưởng là độ trễ thấp hơn và ít chi phí phụ hơn ở quy mô lớn — hàng nghìn người dùng đồng thời, khối lượng cập nhật nặng.

Quy tắc thực tế: bắt đầu với polling trên một gói NAT. Chuyển sang một webhook chỉ khi bạn đã thực sự vượt quá polling — và nếu bạn làm, đó là khi một IP riêng xứng đáng có mặt, vì bạn cần endpoint HTTPS đến đó.

Nó tốn gì để chạy

Một bot polling nhẹ. Nó nhàn rỗi trên long-poll của Telegram và phản ứng với tin nhắn, nên cỗ máy chủ yếu chờ:

Nano $3 (1 vCPU / 1 GB) — ổn cho hầu hết các bot, kể cả những cái khá nhiều lời.
Micro $5 (2 vCPU / 2 GB) — khi bot giữ một cơ sở dữ liệu (SQLite/Postgres), xử lý media, hoặc phục vụ nhiều người dùng.
Cao hơn chỉ nếu bản thân bot làm việc thật — xử lý ảnh, một mô hình cục bộ, logic nặng theo-từng-tin-nhắn.

Đăng ký chỉ-email và bạn thanh toán bằng USDC hoặc USDT trên Base hoặc Ethereum — không thẻ, không giấy tờ. Một thẻ cũng hoạt động, nhưng on-ramp có mức tối thiểu ~$27, nên cho một gói $3 mượt hơn khi nạp một số dư nhỏ một lần và để các gia hạn rút từ nó. Nó chỉ-CPU, một datacenter ở Đức — không phải vấn đề cho một bot, đáng biết nếu bạn cần một GPU hoặc một khu vực cụ thể.

Kết luận trung thực

Một Telegram bot là một trong những thứ rẻ nhất bạn có thể tự host: một cỗ máy $3, một unit systemd, và polling cho bạn một bot online qua các lần sập và khởi động lại mà không cần bạn trông trẻ. Với tới một webhook và một gói lớn hơn chỉ khi quy mô thực sự ép nó — không phải vì một hướng dẫn nói với bạn webhook "tốt hơn." Lấy cỗ máy nhỏ, giữ token trong một tập tin env, để systemd xử lý thời gian hoạt động, và — trước bất cứ gì khác — chạy danh sách kiểm tra bảo mật VPS-mới để chính cỗ máy được khóa lại.

Sẵn sàng host của bạn? Một Telegram bot gần như không dùng tài nguyên — gói Nano ($3/tháng) chạy nó 24/7 không phiền.