تأخیر پیام ربات تلگرام؛ چرا پیام‌ها دیر می‌رسند و چگونه رفع کنیم؟

کاربر ساعت ۱۰:۰۱ برای ربات تلگرام پیام می‌فرستد، اما پاسخ ساعت ۱۰:۰۴ می‌رسد. در ظاهر ربات «کند» است؛ ولی تأخیر ممکن است پیش از ورود رویداد به سرور، در صف برنامه، هنگام فراخوانی Bot API یا حتی در مسیر تحویل پاسخ رخ داده باشد. چرا پیام‌های ربات تلگرام دیر ارسال می‌شوند؟ برای یافتن علت، باید زمان رویداد را در چند نقطه مستقل ثبت کرد و به‌جای حدس‌زدن، زمان انتظار هر مرحله را مقایسه کرد.

در این راهنما مسیر کامل پاسخ ربات را از دریافت Update تا تأیید ارسال بررسی می‌کنیم: Webhook، Long Polling، Queue، Rate Limit، Timeout، Retry و مشکلات شبکه سرور ایران. تمرکز مقاله عیب‌یابی تأخیر پیام است؛ نه آموزش مقدماتی ثبت Webhook یا مقایسه کلی دو معماری. آن مباحث در آموزش ساخت ربات با Laravel و مقایسه Webhook و Long Polling آمده‌اند.

ابتدا مشخص کنید پیام ورودی دیر می‌رسد یا پاسخ خروجی دیر ارسال می‌شود

یک مسیر نمونه را در نظر بگیرید: Telegram Update را به Endpoint شما تحویل می‌دهد؛ سرور پس از اعتبارسنجی، رویداد را در دیتابیس ثبت می‌کند؛ Job وارد صف می‌شود؛ Worker منطق پاسخ را اجرا می‌کند؛ درخواست sendMessage به Bot API ارسال می‌شود و در پایان Telegram پاسخ موفق را برمی‌گرداند. تأخیر در هر کدام از این مراحل می‌تواند تجربه کاربر را تغییر دهد.

مرحله	زمانی که باید ثبت شود	خطای رایج	مالک بررسی
دریافت Update	received_at روی Backend	قطع مسیر ورودی، Webhook معوق	شبکه و Endpoint دریافت
ثبت و ورود به صف	enqueued_at	دیتابیس کند، Redis یا Queue خطادار	برنامه و ذخیره‌سازی
شروع Worker	started_at	کمبود Worker، صف طولانی	Queue و ظرفیت پردازش
ارسال به Telegram	send_started_at	DNS، TLS، Timeout، خطای 429	شبکه خروجی و Bot API
پاسخ Bot API	send_finished_at	Rate Limit، درخواست نامعتبر، 5xx	منطق Retry و Provider

اختلاف started_at - enqueued_at زمان انتظار در صف را نشان می‌دهد، نه زمان پاسخ Bot API. اگر فقط زمان کل را ذخیره کنید، نمی‌توانید بفهمید مشکل از کمبود Worker است یا از محدودیت تلگرام. برای رصد واقعی کاربر باید زمان رسیدن پیام به تلگرام را جدا از زمان تأیید درخواست خودتان در نظر بگیرید؛ موفق‌شدن sendMessage به‌تنهایی زمان نمایش روی دستگاه مخاطب را اثبات نمی‌کند.

چرا Webhook ربات تلگرام تأخیر ایجاد می‌کند؟

Webhook به یک URL عمومی HTTPS نیاز دارد که از مسیر Telegram قابل دسترسی باشد. اگر DNS، TLS یا مقصد کند باشند، تلگرام ممکن است در تحویل Update به مشکل بخورد. همچنین اگر Controller قبل از پاسخ HTTP منتظر عملیات سنگین بماند، Timeout باعث تلاش دوباره و افزایش بار می‌شود.

از getWebhookInfo چه اطلاعاتی بگیریم؟

متد رسمی getWebhookInfo برای بررسی URL ثبت‌شده، pending_update_count و در صورت وجود last_error_date و last_error_message کاربرد دارد. مقدار Pending بالا می‌تواند نشان دهد Updateها منتظر تحویل‌اند؛ اما به‌تنهایی معلوم نمی‌کند علت شبکه است، Secret اشتباه است یا وب‌سرور پاسخ مناسبی نمی‌دهد. مستند اصلی: Telegram Bot API: getWebhookInfo.

# For a private, trusted diagnostic environment only:
curl -sS --connect-timeout 5 --max-time 12 \
  "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/getWebhookInfo"

در این نمونه، Token داخل URL فرمان قرار می‌گیرد؛ روی میزبان چندکاربره ممکن است از فهرست Process قابل مشاهده باشد. برای محیط عملیاتی، بهتر است درخواست را با HTTP Client و Secret Manager سمت Backend انجام دهید و خروجی را بدون توکن و داده حساس ثبت کنید.

چرا پاسخ HTTP 200 از Webhook پایان کار نیست؟

اگر Handler پس از تأیید Secret و ذخیره پایدار Update پاسخ 200 بدهد و پردازش را در Queue ادامه دهد، عملیات تجاری هنوز تمام نشده است. در مقابل، اگر پیش از ثبت پایدار پاسخ موفق برگرداند و سپس برنامه متوقف شود، ردیابی رویداد دشوار خواهد شد. پاسخ‌دهی سریع مهم است، ولی «سریع و بدون ثبت» راه‌حل نیست.

صف پردازش چطور پیام ربات را چند دقیقه عقب می‌اندازد؟

زمان انتظار در صف از اندازه صف، تعداد Workerهای فعال، مدت اجرای هر Job و سهمیه پردازش تأثیر می‌گیرد. اگر ۶۰۰ رویداد در یک دقیقه وارد شوند اما Workerها در مجموع تنها ۱۰۰ رویداد در دقیقه پردازش کنند، حتی با شبکه سالم، صف رشد می‌کند. این عدد یک مثال فرضی ظرفیت است و به عملکرد واقعی محصول خاصی اشاره ندارد.

برای Laravel، وضعیت Worker، Failed Jobها و قدیمی‌ترین رکورد Pending را جدا ببینید. یک Worker فعال لزوماً کافی نیست؛ ممکن است روی وظیفه سنگین دیگری مشغول باشد یا Queue نامناسبی را گوش دهد. فرمان نمونه برای مشاهده فرایند و صف:

ps -eo pid,etime,comm,args | grep '[q]ueue:work'
php artisan queue:failed
# Verify queue names and worker supervision in the deployment config.

queue:failed فهرست کارهای شکست‌خورده را نشان می‌دهد و چیزی را دوباره اجرا نمی‌کند. اجرای دستورهایی مانند queue:retry all بدون بررسی Idempotency می‌تواند پیام تکراری یا اثر مالی ناخواسته ایجاد کند. مدت انتظار Queue را به تفکیک Bot و نوع Job اندازه بگیرید؛ یک کار سنگین برای همه ربات‌ها نباید صف مشترک را مسدود کند.

خطای 429 و محدودیت نرخ Telegram Bot API چه تأثیری دارند؟

Bot API محدودیت‌هایی برای تعداد پیام دارد. در پرسش‌های متداول رسمی Telegram Bots توصیه شده برای یک Chat از ارسال پیوسته بیش از حدود یک پیام در ثانیه خودداری شود؛ در گروه‌ها حدود ۲۰ پیام در دقیقه و در ارسال گروهی حدود ۳۰ پیام در ثانیه بدون قابلیت پولی مطرح شده است. این‌ها مقادیر عملی و وابسته به سیاست سرویس هستند، نه تضمین ظرفیت هر Bot در هر لحظه.

اگر پاسخ API خطای 429 می‌دهد، ممکن است فیلد retry_after در ResponseParameters زمان انتظار پیشنهادی را مشخص کند. ارسال دوباره فوری همان پیام، وضعیت را بدتر می‌کند و ممکن است صف را طولانی‌تر کند. محدودسازی را هم در سطح Chat و هم در سطح Bot اعمال کنید؛ اگر هزار پیام برای یک Chat دارید، افزودن Worker بیشتر نرخ مجاز همان Chat را افزایش نمی‌دهد.

نمونه زمان‌بندی درست برای ارسال گروهی

فرض کنید ۳۰۰ اعلان غیراضطراری برای Chatهای مستقل آماده شده‌اند. اگر سیاست جاری امکان ارسال حدود ۳۰ پیام در ثانیه را می‌دهد، صرفاً تقسیم ۳۰۰ بر ۳۰ حداقل نظری ۱۰ ثانیه را می‌دهد؛ سربار شبکه، خطا، محدودیت هر Chat و Retry زمان نهایی را بیشتر می‌کنند. در سیستم واقعی باید Token Bucket یا صف نرخ‌محدود به‌ازای Bot و Chat داشته باشید و زمان ارسال را به کاربر وعده ثابت ندهید.

Timeout شبکه و Retry چه زمانی علت تأخیر یا پیام تکراری می‌شوند؟

Timeout ارتباط با Telegram دو حالت دارد: ممکن است اتصال پیش از رسیدن درخواست قطع شود، یا درخواست ارسال شده باشد اما پاسخ به برنامه نرسیده باشد. در حالت دوم، اجرای دوباره sendMessage می‌تواند پیام تکراری ایجاد کند، چون همه متدهای ارسال الزاماً شناسه Idempotency برنامه شما را پشتیبانی نمی‌کنند.

برای خطای ۴۰۱ یا ۴۰۳ باید مجوز، Chat و Token را بررسی کنید، نه اینکه Retry نامحدود انجام دهید. برای بعضی ۵xx، Timeout و 429 با شرایط مناسب می‌توان از Backoff و Jitter استفاده کرد. هر تلاش باید شناسه و وضعیت مجزا داشته باشد و بعد از سقف تلاش به مرحله بررسی انسانی منتقل شود.

چطور کندی شبکه سرور ایران را از کندی برنامه تشخیص دهیم؟

در سرورهای داخل ایران، مسیر ورودی Telegram به Webhook و مسیر خروجی سرور به Bot API ممکن است رفتار متفاوتی داشته باشند. در Long Polling، اتصال خروجی دریافت Update هم اهمیت دارد. پاسخ 200 از Endpoint محلی به معنای بازبودن مسیر خارجی نیست. برای بررسی کم‌خطر، زمان DNS، TCP و TLS، و یک درخواست سبک مجاز را از همان شبکه سرور ثبت کنید.

# Read-only DNS and TLS connectivity diagnostics:
getent ahostsv4 api.telegram.org
openssl s_client -connect api.telegram.org:443 \
  -servername api.telegram.org -verify_return_error -brief < /dev/null
# Use timeouts and a trusted operator environment for production checks.

این بررسی Token را ارسال نمی‌کند و نشان می‌دهد آیا یک دست‌دهی TLS قابل انجام است. بااین‌حال TLS سالم اثبات نمی‌کند تمام متدهای Bot API با حساب یا شبکه شما کار خواهند کرد. برای تفاوت محدودیت شبکه، خطای DNS و قطعی منطقه‌ای، راهنمای اتصال ربات تلگرام از سرور ایران را مطالعه کنید.

نقشه عیب‌یابی ده‌دقیقه‌ای برای یک پیام دیررس

1. یک پیام آزمایشی با شناسه قابل پیگیری از Chat مجاز ارسال کنید؛ ساعت فرستنده و سرور را هماهنگ کنید.
2. زمان دریافت Update و ثبت آن در Backend را پیدا کنید. اگر اصلاً ثبت نشده، وضعیت getWebhookInfo یا Offset Polling را بررسی کنید.
3. اگر Update ثبت شده ولی started_at دیر است، طول صف، Worker و کارهای سنگین همان بازه را بررسی کنید.
4. اگر Worker سریع شروع شده ولی sendMessage دیر تمام شده، خطاهای HTTP، retry_after و زمان DNS/TLS خروجی را جدا بسنجید.
5. اگر Bot API پاسخ موفق داده اما کاربر هنوز پیام را ندیده، تفاوت زمان تحویل سمت Telegram و دستگاه مخاطب را با محدودیت مشاهده خودتان مشخص کنید.
6. در پایان، p50 و p95 تاخیر را در چند ساعت واقعی مقایسه کنید؛ یک تست موفق نشانه حل دائمی مشکل نیست.

همه این مراحل را می‌توان بدون حذف صف یا Restart سرویس انجام داد. ثبت محتوای خام پیام برای تشخیص تأخیر لازم نیست؛ شناسه رویداد، زمان‌ها و کد وضعیت معمولاً کافی‌اند. اگر ساعت سرور غلط باشد، اختلاف زمان‌ها گمراه‌کننده می‌شود؛ همگام‌سازی ساعت باید جدا تأیید شود.

داده‌های حداقلی برای داشبورد تأخیر تلگرام چیست؟

شاخص	روش اندازه‌گیری	به چه درد می‌خورد؟
زمان دریافت Update	ثبت Timestamp در Endpoint ورودی	تفکیک اختلال مسیر دریافت
سن قدیمی‌ترین Job	مقایسه اکنون با زمان ثبت Pending	شناسایی صف انباشته
p95 انتظار Queue	اختلاف زمان ورود و شروع Job	سنجش ظرفیت Worker
نرخ خطای 429	کد پاسخ و retry_after	تعیین سیاست ارسال کنترل‌شده
زمان تماس Bot API	شروع تا دریافت پاسخ HTTP	تفکیک تأخیر Provider و شبکه
تلاش‌های ارسال	ثبت Attempt به‌ازای عملیات منطقی	کشف حلقه Retry یا پیام تکراری

برای سرویس چندرباتی، شاخص‌ها باید به تفکیک Bot و مقصد تحویل باشند؛ میانگین کلی می‌تواند تأخیر شدید یک ربات کم‌مصرف را پنهان کند. مقدار هشدار را از رفتار عادی و حساسیت برنامه استخراج کنید، نه از آستانه واحد برای همه Botها.

سه سناریوی عملی و تفاوت راه‌حل آن‌ها

سناریو اول: پیام فقط هنگام کمپین دیر می‌رسد

اگر زمان دریافت Update طبیعی است، اما صف ارسال رشد می‌کند و خطای 429 بالا می‌رود، ظرفیت Worker به‌تنهایی پاسخ نیست. اول نرخ ارسال در سطح Bot و Chat، صف اعلان‌های کم‌اولویت و زمان‌بندی Retry را اصلاح کنید. اعلان تراکنشی مهم نباید پشت صدها پیام تبلیغاتی منتظر بماند.

سناریو دوم: فقط یک Bot در چند پروژه کند است

اگر هسته دریافت مشترک سالم است ولی یک مقصد Backend دیر پاسخ می‌دهد، بررسی Endpoint آن پروژه، طول Queue مقصد و خطای تحویل مفیدتر از تغییر Webhook همه ربات‌هاست. صف جداگانه برای مقصدهای مختلف می‌تواند از اثر متقابل جلوگیری کند؛ ولی در منابع مشترک مانند Redis اشباع‌شده همچنان امکان اختلال جمعی وجود دارد.

سناریو سوم: تأخیر بعد از تغییر شبکه یا DNS آغاز شده است

اگر چند Bot هم‌زمان از یک سرور دچار Timeout شده‌اند، نخست اتصال TCP/TLS و پاسخ DNS را از همان سرور بررسی کنید. ممکن است شبکه خروجی به Bot API مشکل داشته باشد درحالی‌که وب‌سرور محلی بدون خطا کار کند. تفاوت این وضعیت با مجوز اشتباه Token یا Chat باید از پاسخ واقعی مشخص شود.

اشتباه‌هایی که تأخیر را بیشتر می‌کنند

• افزایش بدون محدودیت تعداد Workerها در حالی که مشکل از 429 است؛ فشار و Retry را بیشتر می‌کند.
• اجرای تماس‌های طولانی Bot API در Controller Webhook و نگه‌داشتن اتصال ورودی باز.
• Retry همه خطاها از جمله Token نامعتبر، بدون سقف تلاش یا Backoff.
• حذف دستی همه Jobهای Pending برای «سبک‌شدن» صف؛ احتمال از دست‌رفتن رویداد.
• ثبت Token در URL کامل Log برای عیب‌یابی شبکه؛ ایجاد ریسک امنیتی.
• قضاوت درباره سرعت صرفاً از روی پاسخ موفق HTTP بدون اندازه‌گیری انتظار Queue.

Avaztek Telegram چگونه به پیگیری تأخیر کمک می‌کند؟

Avaztek Telegram طبق معرفی رسمی محصول، دریافت و ثبت رویداد Webhook، تفکیک Bot و شرکت، صف تحویل، Retry و تحویل امضاشده به پروژه مقصد را در یک لایه مرکزی سامان می‌دهد. این معماری برای تفکیک «رویداد وارد هسته شد؟» از «مقصد آن را تحویل گرفت؟» مفید است؛ البته در یک پروژه واقعی باید جزئیات Log، تأخیر و قابلیت مشاهده براساس نسخه و تنظیمات بررسی شوند.

سامانه لزوماً محدودیت نرخ رسمی Telegram را افزایش نمی‌دهد و مشکل تمام شبکه‌های ایران را تضمینی رفع نمی‌کند. برای قرارداد تحویل به Laravel، مستندات SDK مرجع است. اگر چند Bot با تأخیر یا صف تحویل دارید، مشخصات پروژه، حجم تقریبی پیام و نشانه خطا را در فرم تماس و بررسی اتصال تلگرام آوازتک ثبت کنید؛ Token و داده مشتری را ارسال نکنید.

پرسش‌های متداول درباره تأخیر پیام ربات تلگرام

چرا sendMessage موفق است اما پیام در ربات دیر نمایش داده می‌شود؟

موفقیت Bot API به معنی پذیرش درخواست است؛ زمان نمایش روی دستگاه به مسیرهای دیگری هم وابسته است. زمان شروع و پایان تماس، وضعیت صف و زمان مشاهده کاربر را جدا ثبت کنید.

آیا افزایش تعداد Queue Worker همیشه سرعت ربات را بیشتر می‌کند؟

خیر. اگر محدودیت Telegram یا یک Chat عامل اصلی باشد، Worker بیشتر می‌تواند 429 را افزایش دهد. ابتدا طول Queue و مرحله واقعی تأخیر را پیدا کنید.

برای خطای 429 چه زمانی پیام را دوباره ارسال کنیم؟

از retry_after در صورت وجود و سیاست Rate Limit فعلی استفاده کنید. Retry فوری یا نامحدود مناسب نیست و ممکن است صف را سنگین‌تر کند.

آیا Webhook از Long Polling سریع‌تر است؟

هیچ برتری تضمینی وجود ندارد. Long Polling می‌تواند منتظر Update بماند و Webhook نیز به HTTPS و پردازش مقصد وابسته است؛ p95 زمان واقعی را بسنجید.

چطور بفهمم تأخیر از شبکه سرور ایران است؟

زمان DNS، TCP، TLS و تماس مجاز به Bot API را از خود سرور اندازه بگیرید و با زمان انتظار Queue مقایسه کنید. صرف خطای Timeout علت دقیق را ثابت نمی‌کند.

آیا سامانه Avaztek Telegram تأخیر پیام را تضمینی برطرف می‌کند؟

خیر. دریافت، ثبت و تحویل صفی می‌تواند عیب‌یابی را منظم کند، اما محدودیت Telegram یا اختلال شبکه همچنان باید مستقل بررسی شود.

جمع‌بندی: از زمان‌بندی مرحله‌ای شروع کنید، نه تغییر فوری معماری

برای رفع دیر ارسال‌شدن پیام ربات تلگرام، ابتدا مسیر Update تا sendMessage را زمان‌بندی کنید. سپس بر اساس شواهد، Webhook، Queue، Rate Limit یا شبکه را اصلاح کنید. در پروژه‌های چندرباتی، Avaztek Telegram می‌تواند گزینه‌ای برای مدیریت مرکزی تحویل و پیگیری خطا باشد؛ درخواست بررسی متناسب با نیاز پروژه از طریق فرم رسمی سامانه انجام می‌شود.