وبهوک یا long-polling؟ روش‌های اتصال ربات تلگرام به سرور

هر ربات تلگرام برای دریافت پیام‌های کاربران باید به‌نوعی با سرورهای Bot API تلگرام در ارتباط باشد. تلگرام دقیقاً دو روش رسمی برای این ارتباط تعریف کرده: Webhook و متد getUpdates که معمولاً با نام long-polling شناخته می‌شود. این دو روش فقط یک تفاوت سلیقه‌ای نیستند؛ انتخاب هرکدام مستقیماً روی نیاز به دامنه، سرعت پاسخ‌گویی، مصرف منابع سرور و حتی نحوه‌ی مقیاس‌دادن ربات در آینده اثر می‌گذارد. در این مقاله هر دو روش را با جزئیات فنی واقعی — نه فقط تعریف سطحی — بررسی می‌کنیم.

وبهوک تلگرام (Webhook) چیست و چطور کار می‌کند؟

در روش Webhook، شما با متد setWebhook یک آدرس (URL) روی سرور خود را به تلگرام معرفی می‌کنید و از آن پس، تلگرام به‌جای اینکه منتظر بماند شما بپرسید، خودش با یک درخواست HTTPS POST هر آپدیت جدید را به همان آدرس می‌فرستد. این یعنی مدل push به‌جای pull: تلگرام در ربات شما را می‌زند، نه برعکس. این روش تأخیر بسیار کمی دارد و چون سرور شما بین درخواست‌ها بیکار می‌ماند (به‌جای اینکه مدام سوال بپرسد)، منابع کمتری هم مصرف می‌کند. اما دو پیش‌نیاز فنی مشخص دارد: آدرس باید HTTPS معتبر باشد و روی یکی از پورت‌های مجاز تلگرام — یعنی 443، 80، 88 یا 8443 — گوش دهد؛ در غیر این صورت setWebhook با خطا مواجه می‌شود.

یک نکته‌ی کمتر شناخته‌شده این است که تلگرام گواهی self-signed (خودامضا) را هم می‌پذیرد، به‌شرطی که هنگام فراخوانی setWebhook همان فایل certificate را پیوست کنید؛ این گزینه برای سرورهایی که دامنه دارند ولی هنوز از یک صادرکننده‌ی معتبر مثل Let's Encrypt گواهی نگرفته‌اند مفید است، هرچند برای production معمولی، گواهی معتبر و رایگان (مثل Let's Encrypt) گزینه‌ی ساده‌تر و پایدارتری است. پارامتر دیگری به نام max_connections هم وجود دارد که مشخص می‌کند تلگرام حداکثر چند درخواست هم‌زمان به سرور شما بفرستد (پیش‌فرض ۴۰، قابل تنظیم تا ۱۰۰)؛ برای ربات‌های پرترافیک، افزایش این عدد می‌تواند از صف‌شدن آپدیت‌ها جلوگیری کند.

long-polling چیست و چه زمانی به‌کار می‌آید؟

در روش long-polling، برنامه‌ی شما به‌طور مداوم متد getUpdates را با یک offset (شماره‌ی آخرین آپدیت دیده‌شده) صدا می‌زند. اگر آپدیت جدیدی نباشد، تلگرام درخواست را برای مدتی (با پارامتر timeout، معمولاً چند ثانیه تا حداکثر ۵۰ ثانیه) باز نگه می‌دارد و به‌محض رسیدن پیام جدید، فوراً پاسخ می‌دهد؛ این «طولانی نگه‌داشتن» درخواست است که به آن long-polling می‌گویند، برخلاف polling ساده که هر چند ثانیه یک درخواست کوتاه و مستقل می‌زند. مزیت اصلی این روش این است که هیچ دامنه یا گواهی SSL لازم نیست و روی هر سیستمی — از یک سرور ساده تا لپ‌تاپ شخصی — قابل اجراست؛ به همین دلیل برای توسعه، تست محلی، یا شرایطی که هنوز دامنه‌ی HTTPS ندارید، انتخاب طبیعی است.

یک محدودیت مهم getUpdates این است که تلگرام فقط یک دریافت‌کننده‌ی فعال برای هر توکن ربات می‌پذیرد؛ اگر دو نمونه از همان کد (مثلاً یک نسخه‌ی قدیمی که هنوز روی سرور اجرا مانده و یک نسخه‌ی جدید) هم‌زمان getUpdates بزنند، تلگرام با خطای 409 Conflict یکی را رد می‌کند. این یکی از رایج‌ترین خطاهایی است که توسعه‌دهندگان تازه‌کار هنگام دیپلوی مجدد ربات با آن روبه‌رو می‌شوند.

• Webhook: تأخیر کم، بهینه، کم‌مصرف — اما نیازمند دامنه‌ی HTTPS روی پورت مجاز؛ مناسب production
• long-polling: بدون نیاز به دامنه، ساده برای راه‌اندازی — اما مستعد خطای 409 اگر دو نمونه هم‌زمان اجرا شوند

در بات‌ساز لازم نیست این جزئیات فنی را دستی تنظیم کنید: در صفحه‌ی «اتصال ربات» (bots/[شناسه ربات]/connect) فقط توکنی را که از BotFather گرفته‌اید وارد می‌کنید؛ از همان لحظه، پنل به‌جای شما setWebhook را با آدرس HTTPS و secret_token صدا می‌زند تا ربات فعال شود.

نکته‌ی امنیتی درباره‌ی Webhook

یک نکته‌ی امنیتی مهم درباره‌ی Webhook وجود دارد: چون آدرس شما عمومی است، هر کسی که آن را حدس بزند یا پیدا کند می‌تواند درخواست جعلی به آن بفرستد و وانمود کند که تلگرام است. برای جلوگیری از این حمله، هنگام setWebhook می‌توانید یک secret_token تعیین کنید؛ تلگرام این مقدار را در هدر X-Telegram-Bot-Api-Secret-Token هر درخواست واقعی قرار می‌دهد و سرور شما باید قبل از پردازش هر آپدیت، این هدر را با مقدار ذخیره‌شده مقایسه کند و درخواست‌های بدون هدر معتبر را رد کند. در بات‌ساز این مرحله بخشی از همان فراخوانی setWebhook است که هنگام اتصال ربات (در صفحه‌ی اتصال ربات، بعد از وارد کردن توکن) روی سرور اجرا می‌شود؛ شما فقط توکن را وارد می‌کنید، تنظیم secret_token را کد سرور انجام می‌دهد.

چرا گاهی ربات روی هاست ایران به مشکل می‌خورد؟

یکی از چالش‌های رایج در راه‌اندازی ربات تلگرام در ایران این است که گاهی سرور یا هاست به api.telegram.org دسترسی مستقیم ندارد. در این حالت چه از Webhook استفاده کنید و چه از long-polling، ربات نمی‌تواند با تلگرام ارتباط برقرار کند، چون هر دو روش در نهایت به همین دامنه وصل می‌شوند (Webhook برای فراخوانی متدهای ارسال پیام، و long-polling برای خود getUpdates). راه‌حل رایج این مشکل، استفاده از یک پروکسی یا میرور Bot API است؛ یعنی به‌جای اتصال مستقیم، درخواست‌ها از طریق یک واسط (مثلاً یک Cloudflare Worker شخصی) به تلگرام می‌رسند. پلتفرم‌های حرفه‌ای مثل بات‌ساز این قابلیت را دارند که آدرس Bot API را قابل تنظیم کنند تا روی هاست‌های با دسترسی محدود هم ربات بدون مشکل کار کند.

مقیاس‌پذیری: کدام روش برای رشد ربات بهتر است؟

فراتر از سرعت پاسخ، تفاوت مهم دیگری که کمتر به آن اشاره می‌شود مقیاس‌پذیری است. با long-polling، معمولاً فقط یک فرآیند می‌تواند به‌طور پیوسته getUpdates بزند (وگرنه به همان خطای 409 برمی‌خورید)، یعنی اگر بخواهید بار پردازش را بین چند سرور تقسیم کنید، باید یک لایه‌ی صف‌بندی جداگانه اضافه کنید. Webhook از این نظر ساده‌تر مقیاس می‌گیرد: چون تلگرام مستقیماً به آدرس شما درخواست می‌زند، پشت آن آدرس می‌تواند یک load balancer با چند سرور باشد بدون آنکه تلگرام از این موضوع خبر داشته باشد یا محدودیتی ایجاد کند. برای رباتی که در حد چند ده یا چند صد پیام در روز دارد این تفاوت عملاً حس نمی‌شود؛ اما برای رباتی که هزاران کاربر فعال دارد، معماری Webhook از ابتدا مسیر رشد راحت‌تری فراهم می‌کند.

• long-polling برای مقیاس بزرگ نیاز به لایه‌ی صف‌بندی اضافه دارد
• Webhook به‌طور طبیعی پشت چند سرور و یک load balancer کار می‌کند
• روی هاست‌های با دسترسی محدود، از پروکسی Bot API استفاده کنید
• بات‌ساز روش بهینه را متناسب با نیاز هر ربات به‌صورت خودکار انتخاب می‌کند

چرا نباید نگران جزئیات فنی اتصال باشید؟

شناخت تفاوت Webhook و long-polling برای درک بهتر کارکرد ربات مفید است، اما با یک پلتفرم ربات‌ساز خوب، نیازی نیست خودتان درگیر این جزئیات فنی شوید. هدف اصلی شما فروش و رشد کسب‌وکار است، نه مدیریت زیرساخت فنی، تمدید گواهی SSL یا رفع خطای 409. در بات‌ساز، مرحله‌ی «اتصال ربات» همین کار را انجام می‌دهد: توکنی که از BotFather گرفته‌اید را در فرم اتصال وارد می‌کنید و سرور به‌جای شما setWebhook را با آدرس HTTPS دامنه‌ی بات‌ساز و secret_token صدا می‌زند. این جداسازی نگرانی‌های فنی از کسب‌وکار، یکی از بزرگ‌ترین مزیت‌های استفاده از ربات‌ساز آماده در مقابل کدنویسی دستی است — و همین زیرساخت مشترک است که به بات‌ساز اجازه می‌دهد یک ربات را هم‌زمان روی تلگرام، بله و روبیکا هم فعال نگه دارد.

• اتصال از صفحه‌ی «اتصال ربات» با یک توکن انجام می‌شود، نه با تنظیم دستی Webhook
• سرور به‌جای شما setWebhook را با آدرس HTTPS و secret_token صدا می‌زند
• شما روی فروش تمرکز می‌کنید، نه زیرساخت

یک سناریوی فرضی: مشکل اتصال روی هاست محدود

برای روشن‌شدن موضوع، این سناریوی فرضی را در نظر بگیرید: یک توسعه‌دهنده‌ی تازه‌کار ربات خودش را روی یک هاست ارزان داخلی نصب می‌کند، اما ربات هیچ پیامی دریافت نمی‌کند. بعد از بررسی لاگ‌ها متوجه می‌شود هاستش به api.telegram.org دسترسی مستقیم ندارد. در چنین حالتی، دو مسیر پیش رو دارد: یا خودش یک پروکسی Bot API راه بیندازد و آن را نگهداری کند، یا از پلتفرمی استفاده کند که این مشکل اتصال را از قبل و به‌صورت متمرکز حل کرده باشد. این مثال صرفاً برای نشان‌دادن ماهیت مشکل است، نه گزارش یک مورد مشخص.

جمع‌بندی

Webhook و long-polling دو راه رسمی تلگرام برای رساندن آپدیت‌ها به ربات شما هستند. Webhook تأخیر کمتر، مصرف منابع کمتر و مسیر رشد ساده‌تری دارد اما به دامنه‌ی HTTPS معتبر و تنظیمات امنیتی (secret_token) نیاز دارد؛ long-polling ساده‌تر راه می‌افتد و برای شروع، تست یا هاست بدون دامنه مناسب است، اما باید مراقب اجرای هم‌زمان چند نمونه (خطای 409) باشید. با یک پلتفرم مثل بات‌ساز این تنظیمات به یک فرم اتصال ساده تبدیل می‌شوند: توکن ربات را وارد می‌کنید و پنل، Webhook را با گواهی و secret_token لازم برای شما برقرار می‌کند — همین یک بار اتصال، ربات را روی تلگرام، بله و روبیکا هم‌زمان فعال نگه می‌دارد و شما فقط روی فروش‌تان تمرکز می‌کنید.

مقالات مرتبط