أفضل VPS لبوت Telegram: الاستقصاء وWebhooks وIPv4 والتكلفة الشهرية

يرد البوت على كل رسالة حتى تغلق غطاء الحاسوب، ثم يصمت. يحل VPS صغير المشكلة ببضعة دولارات شهريًا. يعتمد الاختيار على طريقة وصول التحديثات: إما يطلبها البوت من Telegram أو يرسلها Telegram إليه.

يحدد ذلك المنافذ والشهادة المطلوبة والحاجة إلى اتصال IPv4 عام.

النسخة المختصرة

• لبوت واحد على VPS، استخدم الاستقصاء الطويل. لا يحتاج إلى نطاق أو شهادة أو منفذ مفتوح.
• تحتاج Webhooks إلى 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 وهامش الذاكرة، وليس السعر المعلن وحده.

الاستقصاء أم Webhooks: الخيار الذي يحدد متطلبات الخادم

يتلقى البوت التحديثات بطريقتين. في الاستقصاء الطويل يستدعي getUpdates ويبقي Telegram الطلب مفتوحًا حتى وصول تحديث أو انتهاء المهلة؛ تبدأ جميع الاتصالات من خادمك. مع Webhook تسجل رابطًا مرة واحدة باستخدام setWebhook، ويرسل Telegram كل تحديث إليه بطلب POST عبر HTTPS.

يتبع عمود Webhook متطلبات Telegram الخاصة بـWebhooks.

لمعرفة طريقة البوت، استعلم من Bot API:

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

إذا احتوت الاستجابة على "url":""، فلا يوجد Webhook مهيأ ويمكن استخدام الاستقصاء الطويل. يستخدم bot.start() في grammY الاستقصاء الطويل افتراضيًا؛ ويستخدم python-telegram-bot الدالة run_polling() أو run_webhook().

لبوت واحد على VPS مستقل، أختار الاستقصاء، وهو أيضًا ما توصي به grammY افتراضيًا. تناسب Webhooks خادمًا يشغل وكيلًا عكسيًا بالفعل (خادم ويب يمرر طلبات HTTPS إلى البوت)، أو عدة بوتات تشترك في نقطة HTTPS، أو منصة دون خادم. هنا يحصل Caddy على الشهادة ويجددها دون مهمة cron.

يؤخر الانقطاع القصير الرسائل دون فقدها. وفق قواعد تحديثات Bot API، يحتفظ Telegram بالتحديثات حتى 24 ساعة إلى أن يستلمها البوت، بالطريقتين، ويعيد طلبات Webhook الفاشلة قبل التوقف عن المحاولة.

إذا كان Webhook يستخدم منفذه مباشرة، فاقصر الوصول إلى هذا المنفذ على نطاقات عناوين المصدر التي ينشرها Telegram. إذا كان المنفذ 443 مشتركًا عبر وكيل عكسي يخدم مواقع أخرى، فطبق التقييد على مسار Webhook فقط أو استخدم الرمز السري الخاص بـTelegram بدل حظر جميع طلبات HTTPS الأخرى. يسرد دليل Webhooks نطاقين لعناوين المصدر ويحذر من إمكانية تغيرهما. باستخدام 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، لذلك تبقى الحاوية المشغلة باستخدام -p 443:443 مفتوحة للجميع. اضبط أيضًا secret_token في setWebhook. يعيده Telegram في ترويسة X-Telegram-Bot-Api-Secret-Token بكل طلب، ويرفض معالجك الطلبات التي لا تحتوي عليه.

إبقاء البوت نشطًا: systemd أم Docker

تشغيل بوت على مدار الساعة يعني إعادته بعد الأعطال وإعادة التشغيل. يتولى systemd ذلك على VPS، أو Docker إذا كان البوت موزعًا كصورة.

وحدة systemd ملف إعداد قصير يوضح لنظام التهيئة كيفية تشغيل برنامج وإعادة تشغيله. أنشئ /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

يعيد Restart=always تشغيل البوت بعد الخروج الطبيعي أو التعطل؛ ويتجاهل on-failure الخروج الطبيعي وفق دليل systemd.service. يفصل RestartSec=5 بين المحاولات، ويشغل WantedBy=multi-user.target مع enable البوت عند الإقلاع. عند تكرر إعادة التشغيل، يعرض sudo journalctl -u telegram-bot -n 50 تتبع الخطأ. تحقق أولًا من غياب 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 إن الحاوية تعود عند انتهاء عمليتها أو إعادة تشغيل عملية Docker الخلفية، وليس بعد أن توقفها بنفسك. يشمل ذلك إعادة إقلاع الجهاز إذا بدأ Docker نفسه عند الإقلاع، كما يحدث افتراضيًا على Debian وUbuntu. في الأنظمة الأخرى نفذ sudo systemctl enable docker.service.

قاعدتي: لسكربت واحد على خادم صغير أستخدم systemd، دون عملية خلفية إضافية في الذاكرة. إذا كنت تبني صورًا أو تشغل حاويات أخرى بالفعل، فاستخدم Docker مع احتساب أن عمليته الخلفية تستهلك جزءًا من RAM.

لا تنبهك أي من الأداتين عند توقف البوت. يستطيع مراقب دفع Uptime Kuma على خادم ثانٍ ذلك. يستدعي البوت رابط المراقبة دوريًا، وينبهك Uptime Kuma عبر Telegram عند توقف الاستدعاءات.

حدود الاستضافة المجانية والخوادم المنزلية

يوقف Render خدمة الويب المجانية بعد 15 دقيقة دون حركة واردة، وتقدر وثائق خطة Render المجانية مدة الاستيقاظ بنحو دقيقة. لا يستقبل بوت الاستقصاء حركة واردة، لذلك يجري إيقافه. يوقظ طلب POST من Telegram بوت Webhook، مع بدء بارد بعد فترات الخمول. لذا تتوقف جدوى الاستضافة المجانية لبوت Telegram على الطريقة التي يستخدمها.

يسرد دليل grammY منصات دون خادم مناسبة لـWebhooks، بينما يحتاج الاستقصاء الطويل إلى جهاز دائم التشغيل. يحاسب Fly.io حسب الاستخدام ويشترط بطاقة مسجلة.

يمكن لـRaspberry Pi أو حاسوب قديم تشغيل بوت استقصاء ما دام الجهاز والكهرباء والاتصال متاحين. تحتاج Webhooks المنزلية أيضًا إلى عنوان عام وإعادة توجيه المنافذ. قد يكفي أي من الخيارين المجانيين لبوت هواية.

يلائم VPS الطريقتين بسعر شهري ثابت.

مقارنة خمسة مزودي VPS لبوت Telegram

يقارن الجدول خمس خطط مدفوعة أساسية لبوتات Telegram بالأسعار الشهرية المعلنة في أكتوبر 2026 قبل الضرائب. تُذكر العروض الترويجية عند وجودها.

خطة Vultr الخاصة بـIPv6 فقط لا تتضمن IPv4، وسعر Hetzner يستثني عنوان IPv4. بدونه لا يستقبل أي منهما Webhook.

يمكن للاستقصاء العمل عبر 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 متطلبًا للذاكرة. يتوقف الأمر على ما يشاركه الخادم: نظام التشغيل وعملية 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) هو إيقاف النواة لعملية لتفريغ RAM. يعيد systemd تشغيل البوت، وقد يكون سطر السجل الدليل الوحيد المتاح. انتقل إلى 1 GB عند ظهور حالات OOM أو استخدام 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 لـWebhooks.
• مساحة ونقل أكبر مع 512 MB: Cloudzy يوفر أعلى تخزين بين هذه الخطط (20 GB NVMe مقابل 10) ونقلًا أكبر (1 TB مقابل نحو 500 GB)، مع IPv4 وIPv6. وسعره الترويجي الحالي أقل من بقية الخطط الأساسية المقارنة.

يجمع Cloudzy بسعره الترويجي الحالي بين أقل سعر شهري في هذه المقارنة ومساحة تخزين ونقل أكبر من خطط 512 MB الأخرى. تُحاسب خطة Cloudzy بسعة 512 MB بالساعة مع ضمان استرداد الأموال لمدة 14 يومًا، لتشغّل البوت عليها بضعة أيام قبل الالتزام. اختر أقرب موقع للمستخدمين، وانشر خادم Cloudzy Linux VPS، وأضف وحدة systemd السابقة.

الأسئلة الشائعة