Telegram Bot 限流 429 錯誤全解：退避策略與群發/坐席並發應對方案

運營 Telegram Bot 的團隊，無論做客服、社群管理還是批量群發，遲早會撞上一個 HTTP 狀態碼：429 Too Many Requests。這個錯誤意味著你的 Bot 在指定時間內發送了太多請求，觸發了 Telegram Bot API 的速率限制（Rate Limit）。如果處理不當，輕則訊息延遲，重則群發中斷、客服響應停滯，直接影響用戶體驗和業務轉換。

本文將從 429 錯誤的觸發原理講起，提供從基礎退避策略到群發排程、多坐席並發峰值的完整應對方案，並附上檢查清單與常見問題，幫助你的團隊高效規避 Telegram Bot 限流，保障客服與群發鏈路穩定。

什麼是 Telegram Bot API 限流（429 Too Many Requests）

429 錯誤的本質是 Telegram 伺服器為了保護自身穩定性，對每個 Bot Token 施加的請求頻率與並發數限制。這不是懲罰，而是一種保護機制——防止單個 Bot 的異常流量拖垮整體服務。

觸發 429 的典型場景包括：

• 高頻群發：短時間內通過 /sendMessage 發送大量訊息。
• 多坐席並發：多個客服人員同時回覆用戶，聚合請求量遠超單坐席場景。
• Webhook 回調風暴：Webhook 配置不當導致重複回調，或用戶群體性觸發命令（如 /start）。
• 媒體訊息堆積：發送圖片、檔案等媒體訊息的配額通常低於純文字訊息。

需要特別注意的是：限流不是全局統一的固定值。Telegram 會根據 Bot 的活躍度、訊息類型、頻道訂閱數等動態調整配額。因此，靠猜測或硬編碼等待時間是行不通的。

理解 429 錯誤：常見觸發場景與影響

群發場景下的限流風險

當你通過批量群發向 1000 個用戶推送活動通知時，如果腳本在幾秒內連續呼叫 /sendMessage 1000 次，極大概率會觸發 429。此外，不同訊息類型的配額差異明顯：

訊息類型	典型配額（經驗值，非官方承諾）	風險等級
純文字訊息	約 30 條/秒	中
圖片/檔案	約 20 條/秒	高
按鈕/Inline Keyboard	約 20 條/秒	高
媒體組（sendMediaGroup）	約 10 組/秒	極高

群發場景下，429 的直接後果是部分用戶收不到訊息，且重試機制不當可能導致重複發送或進入「限流黑洞」（連續重試 → 連續 429 → 請求徹底失敗）。

多坐席並發場景下的限流風險

使用 TG-Staff 這類多坐席客服平台時，多個坐席通過同一個 Bot Token 發送訊息。假設三個坐席同時回覆用戶，每個坐席每秒發 10 條訊息，聚合後就是 30 條/秒，很容易觸及限流閾值。

更隱蔽的風險點包括：

• 會話轉移：坐席 A 將會話轉移給坐席 B，雙方同時發送訊息（A 發結束語，B 發開場白）。
• 自動歡迎訊息：新用戶進入 Bot 時觸發 /start 命令和歡迎訊息，與坐席回覆疊加。
• 命令響應：用戶頻繁點擊 Bot 選單或命令，產生大量 API 呼叫。

限流對客服體驗的影響是立竿見影的：用戶看到訊息延遲、重複發送、甚至 Bot 停止響應，導致投訴增加。

基礎退避策略：從指數退避到抖動（Jitter）

應對 429 的最核心手段是指數退避（Exponential Backoff）與抖動（Jitter）。簡單說，就是收到 429 後先等待一段時間，如果仍然失敗則延長等待時間，並加入隨機抖動避免所有請求同時重試。

偽代碼邏輯參考：

import time
import random

MAX_RETRIES = 5
BASE_DELAY = 2  # 初始等待 2 秒
MAX_DELAY = 60  # 最大等待 60 秒

def send_message_with_backoff(bot_token, chat_id, text):
    for attempt in range(MAX_RETRIES):
        response = call_telegram_api(bot_token, chat_id, text)
        if response.status_code == 200:
            return response
        elif response.status_code == 429:
            # 优先读取 Retry-After 头部
            retry_after = response.headers.get('Retry-After')
            if retry_after:
                wait_time = int(retry_after)
            else:
                # 指数退避 + 抖动
                wait_time = min(BASE_DELAY * (2 ** attempt), MAX_DELAY)
                wait_time += random.uniform(0, 1)  # 添加 0-1 秒抖动
            time.sleep(wait_time)
        else:
            # 其他错误（如 400、500）直接退出
            raise Exception(f"API error: {response.status_code}")
    raise Exception("Max retries exceeded")

關鍵要點：

• 始終讀取 Retry-After 頭部：這是 Telegram 明確告訴你的等待時間，優先級最高。
• 初始等待建議 2-3 秒，最大退避時間建議 60 秒。超過 60 秒仍收到 429，應停止發送並檢查 Token 是否被限制或訊息內容是否違規。
• 抖動（Jitter）：加入隨機值（0-1 秒）防止多個請求同時重試造成「驚群效應」。

高級應對策略：群發排程與請求合併

對於群發場景，僅靠退避策略是不夠的，必須從排程層面控制請求節奏。

1. 使用訊息佇列 + 分批發送

不要直接循環呼叫 API，而是將訊息推入佇列，由 Worker 按固定間隔消費。例如：

• 每秒從佇列取出 1-2 條訊息發送。
• 如果收到 429，暫停佇列消費一段時間（根據 Retry-After 調整）。
• 記錄失敗訊息，後續輪次重試。

2. 合併媒體訊息

對於圖片+文字的組合，使用 /sendMediaGroup 一次性發送最多 10 張圖片（含 caption），而不是逐一發送。這能顯著減少 API 呼叫次數。

3. 預估時間窗口

群發前計算總訊息量：1000 條訊息 ÷ 2 條/秒 = 500 秒（約 8 分鐘）。提前告知運營團隊預計完成時間，避免焦慮。

多座席並發場景下的限流規避方案

多座席共享 Bot Token 時，最忌諱的是「各自為戰」——每個座席獨立發送請求，彼此不知道對方已消耗了多少配額。解決方案是統一控制請求出口。

1. 座席端請求佇列

在 TG-Staff 這類平台中，所有座席發送的訊息先進入一個集中化佇列，由佇列按固定速率（如每秒 20 條）向 Telegram API 發送。座席看到的訊息是即時發送的，但實際請求被平滑處理了。

2. 限速令牌桶（Token Bucket）

在服務端維護一個令牌桶，每秒鐘生成固定數量的令牌。座席發送訊息時必須消耗一個令牌，令牌耗盡則等待下一輪。這樣可以精確控制每秒最大請求數。

3. 集中式請求代理

所有 API 呼叫透過一個代理層轉發，代理層負責記錄配額消耗、處理 429 重試、並返回統一回應。座席端無需關心底層限流邏輯。

利用會話分流降低瞬時並發

TG-Staff 的會話分流功能（特別是「線上優先」模式）可以將用戶諮詢均勻分配給線上座席，避免所有請求湧入同一座席或同一時間窗口。配合分流連結（Diversion Link），你可以在廣告活動中控制流量進入 Bot 的節奏，例如：

• 設定分流規則為「線上優先」，確保只有線上座席能接到新會話。
• 高峰期手動調整座席線上數量，或啟用輪流分配模式。

配置內容風控減少無效請求

專業版的內控管理（內容風控）可在座席發送前進行合規檢查。例如，檢測到座席試圖發送違規收款地址時，系統會阻止該訊息並彈出二次確認，避免因錯誤發送後被撤回（需要額外 API 呼叫）或導致用戶投訴。減少無效請求 = 降低限流風險。

監控與預警：如何及時發現限流

1. 日誌監控

在 API 呼叫層列印詳細日誌，包括每次請求的狀態碼、回應時間、Retry-After 標頭。使用 ELK、Splunk 或簡單的日誌檔案分析，統計每分鐘 429 次數。

2. Webhook 錯誤回呼

如果使用 Webhook 模式，Telegram 會在發送失敗時透過 onError 回呼通知你。記錄這些回呼，並設定閾值告警。

3. 第三方監控工具

使用 Prometheus + Grafana 或 Datadog 等工具，繪製 429 錯誤率曲線，並設定告警規則（如 10 分鐘內 429 次數超過 50 次時通知營運團隊）。

4. TG-Staff 控制台統計

專業版的控制台提供用戶畫像與數據統計功能，可幫助排查限流時段與高頻會話分佈。如果發現某個時間窗口集中出現 429，應分析該時段的座席線上人數和群發任務安排。

常見問題

問： Telegram Bot API 的 429 限流具體是多久重置？

答： 限流窗口通常為 1 秒，但具體配額取決於訊息類型和 Bot 活躍度。官方建議始終讀取 Retry-After 回應標頭，其值通常是秒數。不要在未讀取標頭的情況下硬編碼等待時間。

問： 多坐席共享 Bot Token 時，429 風險會成倍增加嗎？

答： 是的。如果三個坐席同時回覆，可能三倍於單坐席的請求速率。建議使用 TG-Staff 這類統一管理平台，其後台會做請求排隊與限速，避免每個坐席獨立發送請求導致超限。

問： 群發 1000 條訊息時，應該設置多長的間隔？

答： 安全做法是每秒 1-2 條（即 500-1000 秒完成）。如果訊息包含媒體或按鈕，建議更慢（每秒 1 條）。可先以每秒 3 條測試，若返回 429 則立即降速。

問： 指數退避的最大等待時間設為多久？

答： 建議設為 60 秒。超過 60 秒仍收到 429 時，應停止發送並檢查是否有其他問題（如 Token 被限制、訊息內容違規）。不要無限等待。

問： 使用分流連結（Diversion Link）會觸發限流嗎？

答： 分流連結本身是一個短鏈跳轉，不直接呼叫 Bot API。但用戶透過連結進入 Bot 後觸發的歡迎訊息或自動回覆會消耗 API 配額。因此，高流量廣告活動期間，建議配合會話分流與分批歡迎訊息來降低瞬時壓力。

---

總結與下一步行動

規避 Telegram Bot 限流（429 錯誤） 的核心思路是：理解配額 → 退避重試 → 調度控制 → 監控預警。對於群發場景，重點在於分批與合併；對於多坐席場景，重點在於統一請求出口與平滑限速。

如果你正在使用或計劃使用多坐席客服系統，TG-Staff 內建了群發調度、坐席請求佇列和會話分流功能，能在很大程度上降低 429 風險。建議：

1. 註冊免費試用：https://app.tg-staff.com/ 體驗 3 天全功能。
2. 查閱官方文件：https://docs.tg-staff.com/ 獲取分流規則、內容風控配置等詳細教學。
3. 聯繫客服 Bot：@tgstaff_robot 諮詢具體限流應對方案，我們的團隊會根據你的業務場景給出建議。

---

本文內容基於 Telegram Bot API 官方文件與 TG-Staff 實際產品功能撰寫。套餐價格與功能以官網最新資訊為準。