VPS ที่ดีที่สุดสำหรับโฮสต์บอต Telegram: Polling, Webhook, IPv4 และค่าใช้จ่ายรายเดือน

บอตตอบทุกข้อความจนกระทั่งคุณปิดฝาแล็ปท็อป จากนั้นผู้ใช้ก็ไม่ได้รับคำตอบ VPS ขนาดเล็กช่วยแก้ปัญหานี้ได้ด้วยค่าใช้จ่ายเดือนละไม่กี่ดอลลาร์ VPS ที่เหมาะกับบอต Telegram มากที่สุดขึ้นอยู่กับวิธีรับอัปเดต โดยบอตจะร้องขอจาก Telegram หรือให้ Telegram ส่งมาที่บอต

ทางเลือกนี้กำหนดพอร์ตและใบรับรองที่ต้องใช้ รวมถึงความจำเป็นในการเชื่อมต่อผ่าน IPv4 สาธารณะ

เวอร์ชันสั้น

• หากมีบอตหนึ่งตัวบน VPS หนึ่งเครื่อง ให้ใช้ long polling ซึ่งไม่ต้องมีโดเมน ใบรับรอง หรือเปิดพอร์ตรับการเชื่อมต่อ
• Webhook ต้องใช้ HTTPS บนพอร์ต 443, 80, 88 หรือ 8443 และที่อยู่ IPv4 สาธารณะ Telegram ไม่ส่ง webhook ผ่าน IPv6
• 512 MB of RAM is a workable start for one bot with no local database.
• ใช้ systemd เพื่อให้บอตทำงานต่อเนื่อง หรือใช้นโยบายรีสตาร์ตของ Docker หากคุณใช้งานคอนเทนเนอร์อยู่แล้ว
• เลือกผู้ให้บริการจาก IPv4 และ RAM ที่เหลือเผื่อใช้งาน ไม่ใช่ดูแค่ราคาที่ระบุ

Polling หรือ Webhook: ทางเลือกที่กำหนดความต้องการของเซิร์ฟเวอร์

บอต Telegram รับอัปเดตได้สองวิธี ในแบบ long polling บอตเรียก getUpdates แล้ว Telegram จะเปิดคำขอค้างไว้จนมีอัปเดตหรือหมดเวลารอ การเชื่อมต่อทุกครั้งจึงเริ่มจากเซิร์ฟเวอร์ของคุณ ส่วน webhook คุณลงทะเบียน URL ครั้งเดียวด้วย setWebhook แล้ว Telegram จะส่งแต่ละอัปเดตไปยัง URL นั้นด้วย POST ผ่าน HTTPS

คอลัมน์ webhook อ้างอิงตาม ข้อกำหนด webhook ของ Telegram

หากต้องการทราบว่าบอตใช้วิธีใด ให้สอบถาม Bot API:

curl "https://api.telegram.org/bot<YOUR_TOKEN>/getWebhookInfo"

หากคำตอบมี "url":"" แสดงว่ายังไม่ได้ตั้งค่า webhook และบอตสามารถใช้ long polling ได้ bot.start() ของ grammY ใช้ long polling เป็นค่าเริ่มต้น ส่วน python-telegram-bot ใช้ run_polling() หรือ run_webhook()

หากมีบอตหนึ่งตัวบน VPS ของตัวเอง ผมจะเลือก polling ซึ่งเป็น คำแนะนำเริ่มต้นของ grammY เช่นกัน Webhook เหมาะกว่าเมื่อเครื่องมี reverse proxy อยู่แล้ว (เว็บเซิร์ฟเวอร์ที่ส่งต่อคำขอ HTTPS ให้บอต) เมื่อหลายบอตใช้ HTTPS endpoint เดียวกัน หรือบนแพลตฟอร์ม serverless ในกรณีนี้ Caddy จะขอและต่ออายุใบรับรอง โดยไม่ต้องมี cron job

การหยุดทำงานสั้น ๆ ทำให้ข้อความล่าช้า แต่ไม่สูญหาย ตาม กฎการรับอัปเดตของ Bot API Telegram เก็บอัปเดตไว้สูงสุด 24 ชั่วโมงจนกว่าบอตจะรับ ไม่ว่าจะใช้วิธีใด และจะลองส่งคำขอ webhook ที่ล้มเหลวอีกครั้งก่อนเลิกพยายาม

หาก webhook ใช้พอร์ตโดยตรงเพียงตัวเดียว ให้จำกัดพอร์ตนั้นไว้เฉพาะช่วงที่อยู่ต้นทางที่ Telegram เผยแพร่ หาก reverse proxy ที่ให้บริการเว็บไซต์อื่นด้วยใช้พอร์ต 443 ร่วมกัน ให้จำกัดเฉพาะเส้นทาง webhook หรือใช้โทเค็นลับของ Telegram แทนการบล็อก HTTPS อื่นทั้งหมด คู่มือ webhook ระบุช่วงที่อยู่ต้นทางสองช่วง และเตือนว่าอาจเปลี่ยนแปลงได้ หากใช้ UFW เป็นไฟร์วอลล์ของเครื่อง:

sudo ufw allow 22/tcp    # keep SSH open before you enable the firewall

sudo ufw allow proto tcp from 149.154.160.0/20 to any port 443

sudo ufw allow proto tcp from 91.108.4.0/22 to any port 443

sudo ufw allow 80/tcp    # if your HTTPS setup uses HTTP validation or redirects HTTP to HTTPS

sudo ufw enable

เปลี่ยน 443 หาก webhook รับฟังบน 80, 88 หรือ 8443 กฎเหล่านี้ปกป้องบอตที่ทำงานบนโฮสต์โดยตรง เอกสารไฟร์วอลล์ของ Docker ระบุว่าพอร์ตที่เผยแพร่ข้าม UFW ดังนั้นคอนเทนเนอร์ webhook ที่เริ่มด้วย -p 443:443 ยังเปิดให้ทุกคนเข้าถึงได้ ตั้ง secret_token ใน setWebhook ด้วย Telegram จะส่งค่านี้กลับมาในเฮดเดอร์ X-Telegram-Bot-Api-Secret-Token ของทุกคำขอ และตัวจัดการควรปฏิเสธคำขอที่ไม่มีค่านี้

ให้บอตทำงานต่อเนื่อง: systemd หรือ Docker

การรันบอต Telegram ตลอด 24 ชั่วโมงหมายถึงต้องเริ่มใหม่หลังโปรแกรมล่มหรือเครื่องรีบูต บน VPS ให้ systemd ทำหน้าที่นี้ หรือใช้ Docker หากบอตแจกจ่ายเป็นอิมเมจ

ยูนิต systemd คือไฟล์ตั้งค่าสั้น ๆ ที่บอกระบบ init ว่าจะเริ่มและรีสตาร์ตโปรแกรมอย่างไร สร้าง /etc/systemd/system/telegram-bot.service:

[Unit]
Description=Telegram bot
After=network-online.target
Wants=network-online.target

[Service]
User=bot
WorkingDirectory=/opt/bot
EnvironmentFile=/opt/bot/.env
ExecStart=/opt/bot/venv/bin/python bot.py
# Node: ExecStart=/usr/bin/node bot.js
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

เก็บโทเค็นในไฟล์ .env ภายในโฟลเดอร์โครงการในรูปแบบ BOT_TOKEN=... แล้วอ่านด้วย os.environ["BOT_TOKEN"] (Node ใช้ process.env.BOT_TOKEN) เพื่อไม่ให้โทเค็นอยู่ในโค้ด จากนั้นคัดลอกโครงการไปยังตำแหน่งใช้งานและเริ่มรัน:

sudo mkdir -p /opt/bot

sudo cp -r ~/your-bot/. /opt/bot/        # your project, after git clone or scp from your machine; include .env and requirements.txt

sudo apt install -y python3-venv         # Debian/Ubuntu

sudo useradd --system --no-create-home bot

sudo chown -R bot:bot /opt/bot

sudo -u bot python3 -m venv /opt/bot/venv

sudo -u bot /opt/bot/venv/bin/pip install -r /opt/bot/requirements.txt

# Node: skip the venv and pip commands above, then run:

cd /opt/bot && sudo -u bot npm ci

sudo chmod 600 /opt/bot/.env

sudo systemctl daemon-reload

sudo systemctl enable --now telegram-bot

systemctl status telegram-bot    # look for: Active: active (running)

sudo journalctl -u telegram-bot -f    # follow the bot's logs

ตาม คู่มือ systemd.service ค่า Restart=always จะรีสตาร์ตบอตทั้งเมื่อจบตามปกติและเมื่อล่ม ส่วน on-failure ไม่รีสตาร์ตเมื่อจบตามปกติ RestartSec=5 เว้นช่วงระหว่างการลองใหม่ และ WantedBy=multi-user.target ร่วมกับ enable ทำให้บอตเริ่มเมื่อบูต หากรีสตาร์ตไม่หยุด ให้ใช้ sudo journalctl -u telegram-bot -n 50 เพื่อดู traceback โดยตรวจสอบก่อนว่าขาด BOT_TOKEN หรือไม่

ใน Docker ใช้แฟล็กเดียวเพื่อให้ได้ผลเทียบเท่า:

docker run -d --name telegram-bot --restart unless-stopped --env-file .env your-bot-image

docker logs -f telegram-bot

ใน Compose ใช้บรรทัด restart: unless-stopped เอกสารนโยบายรีสตาร์ตของ Docker ระบุว่าคอนเทนเนอร์จะกลับมาทำงานเมื่อหยุดหรือเมื่อ daemon เริ่มใหม่ แต่ไม่กลับมาหากคุณสั่งหยุดเอง วิธีนี้ครอบคลุมการรีบูตเมื่อ Docker เริ่มตอนบูตด้วย ซึ่งเป็นค่าเริ่มต้นบน Debian และ Ubuntu สำหรับระบบอื่นให้รัน sudo systemctl enable docker.service

หลักของผมคือ ถ้าเป็นสคริปต์เดียวบนเครื่องเล็กให้ใช้ systemd เพื่อไม่ต้องมี daemon เพิ่มมาใช้หน่วยความจำ หากสร้างอิมเมจหรือรันคอนเทนเนอร์อื่นอยู่แล้ว ให้ใช้ Docker และเผื่อ RAM ส่วนที่ daemon ต้องใช้

ทั้งสองเครื่องมือไม่แจ้งเมื่อบอตหยุดทำงาน แต่ตัวตรวจสอบแบบ push ของ Uptime Kuma บนเซิร์ฟเวอร์อีกเครื่องทำได้ บอตเรียก URL ของตัวตรวจสอบเป็นระยะ และ Uptime Kuma แจ้งเตือนทาง Telegram เมื่อการเรียกหยุดลง

ข้อจำกัดของโฮสติ้งฟรีและเซิร์ฟเวอร์ที่บ้าน

Render พักบริการเว็บฟรีหลังไม่มีทราฟฟิกขาเข้า 15 นาที และเอกสารแพ็กเกจฟรีของ Renderระบุว่าใช้เวลาปลุกประมาณหนึ่งนาที บอต polling ไม่มีทราฟฟิกขาเข้าจึงถูกหยุด บอต webhook ถูกปลุกด้วย POST จาก Telegram แต่ต้องเริ่มแบบ cold start หลังเงียบไปพักหนึ่ง ดังนั้นโฮสติ้งฟรีเหมาะกับบอต Telegram หรือไม่จึงขึ้นอยู่กับวิธีที่บอตใช้

คู่มือ grammY ระบุแพลตฟอร์ม serverless ว่าเหมาะกับ webhook ส่วน long polling ต้องใช้เครื่องที่ทำงานตลอดเวลา Fly.io คิดค่าบริการตามการใช้งานและต้องลงทะเบียนข้อมูลบัตร

Raspberry Pi หรือพีซีเก่าสามารถรันบอต polling ได้ตราบใดที่เครื่อง ไฟฟ้า และเครือข่ายยังทำงาน Webhook จากบ้านต้องมีที่อยู่สาธารณะและการส่งต่อพอร์ตด้วย สำหรับบอตงานอดิเรก ทางเลือกฟรีทั้งสองอาจเพียงพอ

VPS รองรับทั้งสองวิธีด้วยค่าบริการรายเดือนคงที่

เปรียบเทียบผู้ให้บริการ VPS ห้ารายสำหรับบอต Telegram

ตารางเปรียบเทียบแพ็กเกจเริ่มต้นแบบชำระเงินห้าแพ็กเกจสำหรับบอต Telegram ตามราคารายเดือนที่โฆษณา ณ เดือนตุลาคม 2026 ก่อนภาษี โดยระบุราคาโปรโมชั่นเมื่อมี

แพ็กเกจ IPv6 เท่านั้นของ Vultr ไม่มี IPv4 และราคา Hetzner ไม่รวมที่อยู่ IPv4 หากไม่มี ทั้งสองก็รับ webhook ไม่ได้

บอต polling รันด้วย IPv6 อย่างเดียวได้ เพราะ api.telegram.org มีที่อยู่ IPv6 แต่ปลายทางอื่นทั้งหมดที่บอตเข้าถึงต้องมีด้วย ทั้งคลังแพ็กเกจ โฮสต์ Git และทุก API ที่เรียก ตรวจสอบแต่ละโฮสต์ก่อนเลือก:

dig +short AAAA api.telegram.org

dig +short AAAA github.com

dig +short AAAA pypi.org    # repeat for every host your bot or its installs reach

คำตอบว่างหมายความว่าโฮสต์นั้นไม่มีที่อยู่ IPv6

512 MB เพียงพอสำหรับบอต Telegram หรือไม่?

ผมจะเริ่มบอตหนึ่งตัวที่ไม่มีฐานข้อมูลในเครื่องด้วย 512 MB เอกสาร python-telegram-bot ไม่ระบุความต้องการหน่วยความจำ สิ่งที่ใช้เครื่องร่วมกันเป็นตัวกำหนด ทั้งระบบปฏิบัติการ daemon ของ Docker หากใช้ และฐานข้อมูลในเครื่อง จึงควรวัดการใช้งานจริง

free -m                   # "available" is your headroom; the Swap row shows swap use

ps -o rss,cmd -p "$(systemctl show -p MainPID --value telegram-bot)"   # bot's resident memory, in KB

docker stats --no-stream  # per-container memory, if the bot runs in Docker

journalctl -k | grep -i "out of memory"   # kernel OOM kills

การยุติโปรเซสเพราะหน่วยความจำไม่พอหรือ OOM kill คือ kernel จบโปรเซสเพื่อคืน RAM โดย systemd จะเริ่มบอตใหม่ จึงอาจเหลือเพียงบรรทัดบันทึกเป็นหลักฐาน เพิ่มเป็น 1 GB เมื่อพบ OOM kill เมื่อมีการใช้ swap ต่อเนื่อง หรือก่อนเพิ่มฐานข้อมูลในเครื่องหรือบอตตัวที่สอง

ควรเลือกตัวไหน

สำหรับบอตหนึ่งตัว ผมจะเลือกแพ็กเกจ 512 MB ที่รวม IPv4 สาธารณะ จากนั้นพิจารณาผู้ให้บริการจากราคา ทรัพยากรเผื่อใช้ และตำแหน่งผู้ใช้

• ราคารายเดือนต่ำสุดในขณะนี้: Cloudzy $2.48 ระหว่างโปรโมชั่นลด 50% พร้อม IPv4 และ IPv6
• ราคาต่ำสุดที่รวม IPv4 ในขณะนี้: Cloudzy $2.48 ระหว่างโปรโมชั่น รวม IPv4 เฉพาะและ IPv6
• 1 GB of headroom for Docker or a small database: Linode, from $5 a month.
• หลายบอตหรือฐานข้อมูล และผู้ใช้อยู่ยุโรป: Hetzner ให้ทรัพยากรต่อยูโรมากที่สุดในตารางนี้เมื่อแพ็กเกจมีพร้อมให้บริการ (แพ็กเกจนี้ถูกระบุว่าไม่พร้อมให้บริการในเดือนตุลาคม 2026) บวกค่า IPv4 หากใช้ webhook
• ดิสก์และปริมาณรับส่งข้อมูลมากขึ้นที่ระดับ 512 MB: Cloudzy ในบรรดาแพ็กเกจ 512 MB มีพื้นที่เก็บข้อมูลมากที่สุด (20 GB NVMe เทียบกับ 10 GB) และปริมาณรับส่งข้อมูลสูงสุด (1 TB เทียบกับประมาณ 500 GB) พร้อม IPv4 และ IPv6 ด้วยราคาโปรโมชั่นปัจจุบัน Cloudzy ยังถูกกว่าแพ็กเกจเริ่มต้นอื่นในการเปรียบเทียบนี้

ด้วยราคาโปรโมชั่นปัจจุบัน Cloudzy ให้ทั้งราคารายเดือนต่ำสุดในการเปรียบเทียบนี้และพื้นที่เก็บข้อมูลกับปริมาณรับส่งข้อมูลมากกว่าแพ็กเกจ 512 MB อื่น แพ็กเกจ 512 MB ของ Cloudzy คิดรายชั่วโมงพร้อมรับประกันคืนเงิน 14 วัน จึงลองรันบอตสักสองสามวันก่อนตัดสินใจได้ เลือกตำแหน่งที่ใกล้ผู้ใช้ที่สุด ติดตั้ง Cloudzy Linux VPS แล้วเพิ่มยูนิต systemd ด้านบน

คำถามที่พบบ่อย