Telegram API 限流完全指南：客服與群發場景下的頻率限制與規避策略

經營一個 Telegram Bot，最令人頭痛的問題之一，就是突然收到 429 Too Many Requests 錯誤，或是發現 Bot 被臨時封禁，無法向使用者發送訊息。這通常是因為觸發了 Telegram API 限流 機制。

無論你是用 Bot 做即時客服，或是進行批量群發，理解並遵守 Telegram 的頻率限制規則，是確保業務穩定運作的前提。本文將系統整理 Telegram API 的核心限流規則，並針對客服與群發兩大高頻場景，提供可落地的規避策略與最佳實務。

為什麼 Telegram Bot 會觸發 API 限流？

Telegram 設計限流機制，不是為了限制正常使用，而是為了保護整個生態系的穩定性。如果沒有這些規則，少數 Bot 的異常高頻請求（如惡意刷屏、DDoS 攻擊）可能會拖垮 Telegram 伺服器，影響數百萬用戶的正常通訊。

因此，限流是 Telegram 的一種「交通管制」。你的 Bot 在以下行為中，最容易觸發限流：

• 短時間內向大量不同用戶發送訊息（典型的群組發行為）。
• 對單一使用者連續發送多個訊息（如自動回覆邏輯過於頻繁）。
• 高頻呼叫非訊息類 API（如更新使用者頭像、取得聊天成員清單）。
• 無視限流錯誤，持續重試（導致懲罰升級）。

理解這一點，你就能把限流當作一個正常的系統回饋訊號，而不是 Bug。接下來，我們來看看具體的規則邊界。

Telegram API 限流的核心規則詳解

Telegram 官方並未公佈所有限流閾值的精確數字（部分規則是動態的），但經過大量實踐和社區驗證，以下規則是公認的「紅線」。

訊息發送頻率限制（flood control）

這是最常見的限流類型。核心規則可概括為：

• 每秒訊息數：大多數 Bot 在向不同使用者發送訊息時，上限約為 30 條/秒。超過此閾值，會立即回傳 429 錯誤。
• 每分鐘群組訊息：在同一個群組或頻道中，Bot 的訊息發送頻率限制更嚴，通常為 20 條/分鐘。頻繁在群組內發公告容易觸發此限制。
• 對單一使用者訊息的間隔：雖然沒有嚴格的每秒限制，但 Telegram 會偵測「洪水攻擊」模式。如果在幾秒鐘內向同一用戶連續發送 4-5 則訊息，很可能會觸發針對該用戶的臨時限制。

當觸發限流時，API 會傳回類似 {"ok":false, "error_code":429, "description":"Too Many Requests: retry after 35"} 的回應。其中的 retry after 35 表示你需要等待 35 秒才能進行下一次請求。

群發與廣播的特殊限制

當你進行群發（主動發送訊息給大量無直接互動的使用者）時，Telegram 會啟動一套更嚴格的「廣播限制」（broadcast limit）。

• 核心邏輯是：Bot 對使用者的「影響力」是動態的。如果用戶最近與你的 Bot 有互動（例如發送了訊息、點擊了按鈕），你的 Bot 對該用戶的訊息發送「權重」就高，限制較鬆。
• 如果使用者從未與 Bot 互動，或超過 24 小時沒有互動，Bot 對該使用者的訊息發送就會被視為「廣播」。此時，在 1 分鐘內對超過 30 個這樣的用戶發送訊息，極大機率觸發限流。
• 更糟的是，如果你無視錯誤繼續發送，Telegram 會指數級增加 retry-after 時間，從幾十秒提升到幾分鐘甚至幾小時。

錯誤代碼與重試策略

處理 429 錯誤的正確方式，不是立刻重試，而是尊重 Retry-After 響應頭。

錯誤代碼	意義	標準處理方式
429	Too Many Requests	讀取回應頭中的 retry_after 欄位（單位：秒），等待對應時間後再重試。如果繼續無視，限流時間會加倍。
420	Flood Wait	與 429 類似，但通常由高頻訊息觸發。處理方式同上。

客服場景下的限流風險與應對

在即時客服場景中，Bot 是連結客戶與坐席的橋樑。看似無害的操作，如自動回覆、翻譯，也可能觸發限流。

避免高頻自動回復

這是最常見的「坑」。當客戶連續發送多條訊息時，如果 Bot 的自動回覆邏輯是“來回一條”，則很容易在幾秒鐘內對同一用戶發送多個訊息，觸發 flood control。

• 因應策略：在 Bot 邏輯中加入訊息去重與合併。例如，使用者 1 秒內連續發送了 3 則訊息，Bot 可以將它們合併為一則訊息，或只回覆最後一則。 TG-Staff 的 Web 控制台在處理即時訊息時，會自動合併使用者短時間內的連續輸入，減少 Bot 的無效回應。

合理分配翻譯要求

當你啟用自動翻譯功能時，每個翻譯要求都會呼叫翻譯 API（如 DeepL、Google 翻譯）。雖然翻譯 API 本身有限制，但 Bot 需要同時處理「接收訊息 → 呼叫翻譯 → 傳送翻譯結果」的整個連結。如果翻譯回應慢，而 Bot 又在等待結果，可能會在短時間內堆積大量請求。

• 應對策略：為翻譯請求設定訊息佇列。不要「同步」等待翻譯結果，而是將翻譯任務放入隊列，Bot 從隊列中按順序處理並發送。 TG-Staff 專業版內建了翻譯隊列與延遲發送機制，確保在翻譯高峰期不會因請求堆積而觸發 Telegram 限流。

使用會話標籤與優先權管理

並非所有客戶訊息都需要 Bot 即時回覆。透過會話標籤（如「緊急」、「一般諮詢」、「投訴」），可以區分優先順序。

• 應對策略：對於「一般諮詢」類訊息，Bot 可以延遲 1-2 秒再回复，或僅回復一條引導訊息（如「您好，已收到您的諮詢，坐席將盡快回复」），從而將寶貴的 API 配額留給緊急訊息或坐席的人工回复。

群發場景下的限流規避最佳實踐

群發是運作利器，但操作不當極易被封。請遵循以下步驟，確保安全且有效率。

1. 檢視使用者活躍度：在群發前，先篩選出最近 24 小時內有互動的使用者。對這些「活躍用戶」的群發限制較寬鬆。對於超過 24 小時無互動的用戶，將其歸類為“廣播清單”，並採用更保守的策略。
2. 訊息內容合規：避免發送包含敏感字詞、外部連結或明顯行銷性質的內容。 Telegram 會對這類訊息的 Bot 進行重點監控。
3. 規劃發送時間：避免在用戶活躍高峰期（如晚上 8-10 點）進行大規模群發。選擇用戶活躍度較低的時段（如凌晨 4-6 點）進行分批發送。
4. 分批發送，間隔執行：這是最關鍵的一步。不要一次性向 1000 個用戶發送。

5. 動態調整速度：在傳送過程中，持續監控 API 回傳的錯誤碼。如果開始出現 429，立即暫停傳送，等待 retry-after 指定的時間，然後以較慢的速度繼續。

如何利用 TG-Staff 自動化應對限流

手動處理上述所有策略非常繁瑣。 TG-Staff 作為面向 Telegram Bot 的客服與營運 SaaS 平台，將限流規避邏輯內建在了產品核心中。

• 智慧訊息佇列：TG-Staff 的所有訊息發送（包括客服回覆、自動翻譯、群發）都經過一個內建的訊息佇列。此佇列會自動偵測 Telegram API 的回應狀態，當偵測到 429 錯誤時，會自動將後續訊息暫存，並依照官方建議的 Retry-After 時間重試，無需你寫任何程式碼。
• 群發速度控制：在「訊息批量群發」功能中，你可以精確設定每分鐘發送量（如設定為 10-15 條/分鐘），平台會自動控制發送節奏，確保不觸發廣播限制。
• 活躍度篩選：群發前，TG-Staff 的專業版使用者畫像功能可依「最後互動時間」篩選使用者。你可以輕鬆創建一個「過去 24 小時活躍用戶」的分群，針對他們進行更有效率的群發。
• 自動翻譯的限流感知：TG-Staff 的自動翻譯功能同樣經過優化。它會將翻譯任務排隊，並控制發送頻率，確保翻譯場景下不會因請求堆積而觸發 Telegram 限流。

透過使用 TG-Staff，你可以將精力集中在營運策略和客戶溝通上，而不是與 API 限流規則鬥智斗勇。

常見問題與檢查清單

常見問題 FAQ

**Q：Bot 被限流後，要等多久才能恢復？ ** A：這取決於錯誤的嚴重程度。如果是輕微的 429 錯誤，等待 retry-after 指定的時間（通常幾十秒）即可恢復。如果無視錯誤持續重試，限流時間可能從幾分鐘延長到幾小時。在最嚴重的情況下，Telegram 可能會暫時封鎖 Bot 的發送權限長達 24 小時。

**Q：如何判斷是限流還是 Bot 故障？ ** A：查看 Bot 的 API 請求日誌。如果錯誤碼是 429 或 420，表示是限流。如果是 400 Bad Request 或 403 Forbidden，則可能是訊息格式錯誤或 Bot 權限不足。 TG-Staff 的控制台提供了清晰的 API 請求日誌，可以幫你快速定位問題。

**Q：年付套餐是否影響限流門檻？ ** A：不影響。 Telegram API 的限流閾值是針對 Bot 本身的，與你使用何種第三方平台或方案無關。 TG-Staff 的所有方案（標準版、專業版）都使用相同的限流規避邏輯，但專業版提供了更多工具（如使用者畫像、數據統計）來幫助你主動規劃，從而減少觸發限流的可能性。具體套餐功能詳見官網套餐頁。

客服與群發檢查清單

在開始任何客服或群發操作前，請對照以下清單進行檢查：

• **是否設定了訊息間隔？ ** 確保 Bot 對相同使用者的回覆間隔 ≥ 2 秒。
• **是否啟用了自動重試？ ** 確保你的系統（或 TG-Staff）能正確解析 Retry-After 頭並自動等待。
• **是否評估了使用者活躍度？ ** 群發前，是否篩選了最近 24 小時有互動的使用者？
• **是否規劃了分批發送？ ** 群發時，每批用戶數是否 ≤ 30人？批次間隔是否 ≥ 15 秒？
• **是否配置了翻譯隊列？ ** 如果使用自動翻譯，是否啟用了訊息佇列來平滑要求？
• **是否監控了 API 錯誤？ ** 是否有工具（如 TG-Staff 控制台）即時監控 429 錯誤？

掌握 Telegram API 限流 規則，是高效率運作 Bot 的基礎。透過合理的策略和工具，你完全可以在遵守規則的前提下，安全、穩定地完成客服與群發任務。