Telegram Bot 429 限流怎麼辦？重試策略與業務層應對完整指南

運行 Telegram Bot 時，你是否遇到過 429 Too Many Requests 錯誤？這個錯誤意味著你的 Bot 在短時間內向 Telegram API 發送了過多請求，觸發了限流機制。如果不正確處理，輕則訊息延遲、群發中斷，重則 Bot 被臨時封禁。

本文將從限流原理、退避重試、請求佇列，到業務層優化，為你提供一套完整的 Telegram 429 限流 應對方案。無論你是獨立開發者還是運營團隊，都能從中找到可落地的解決步驟。

什麼是 Telegram 429 限流？理解 API 請求限制

Telegram Bot API 為了保護服務穩定性，對每個 Bot 的請求頻率做了限制。當你的 Bot 在單位時間內超過這個閾值，API 就會回傳 HTTP 狀態碼 429，並在響應體或響應頭中附帶 retry_after 欄位，指示你需要等待多少秒才能再次請求。

不同 Bot 類型的預設配額（近似值）：

Bot 類型	預設每秒請求上限	備註
普通 Bot	~30 次/秒	適用於大多數客服、通知 Bot
Game Bot	~1 次/秒	專門用於遊戲互動，嚴格限制
群組內 Bot	受群組訊息頻率影響	發送訊息至同一群組時，有額外限制

注意：這些數值是 Telegram 官方未明確公開的近似經驗值，實際閾值可能因伺服器負載、Bot 歷史行為而動態調整。最穩妥的方式是始終處理 retry_after 欄位。

429 錯誤的典型觸發場景

了解限流原理後，我們來看看實際運營中哪些操作最容易觸發 429。

批量群發訊息時的高併發請求

假設你運營一個電商 Bot，需要向 10,000 名用戶發送促銷通知。如果你用一個迴圈 for user in users: send_message(user, text) 直接發送，瞬間就會產生大量併發請求。即使每秒只有 30 次限制，10,000 條訊息也需要至少 333 秒（約 5.5 分鐘）才能發完——但如果你沒有限流控制，前 1 秒內發出的 30 個請求就會觸發 429。

輪詢 getUpdates 時的頻率控制

許多開發者使用輪詢方式獲取用戶訊息（getUpdates）。如果輪詢間隔過短（比如 0.1 秒），或者沒有使用長輪詢（timeout 參數設為 0），極易觸發 429。長輪詢允許一次請求保持連線最多 30 秒，直到有新訊息才回傳，能大幅減少請求次數。

基礎應對：退避重試策略

收到 429 後，最直接的應對方式是退避重試。核心原則是：尊重 retry_after 欄位。

標準退避流程

1. 捕獲 429 響應，解析 retry_after 欄位（通常為秒數）。
2. 等待 retry_after 秒數（建議額外增加 1-2 秒緩衝）。
3. 重試請求。
4. 如果再次收到 429，重複上述步驟，並可考慮指數退避（即每次等待時間翻倍，但以 retry_after 為準）。

偽代碼示例

function send_message_with_retry(chat_id, text, retry_count=0):
    response = api_call("sendMessage", chat_id=chat_id, text=text)
    if response.status == 429:
        retry_after = response.json.get("retry_after", 5)  // 默认 5 秒
        wait(retry_after + 1)  // 加 1 秒缓冲
        send_message_with_retry(chat_id, text, retry_count + 1)
    elif response.status == 200:
        return success
    else:
        // 处理其他错误

重要：不要忽略 retry_after 直接重試，這會導致限流時間延長甚至封禁。

進階方案：請求佇列與併發控制

退避重試是被動應對，更主動的做法是控制請求速率，從源頭避免觸發 429。

令牌桶演算法在 Bot 中的應用

令牌桶演算法非常適合控制 Bot 的請求速率。你可以設定一個桶，每秒向桶中添加固定數量的令牌（例如 30 個）。每次發送請求前，從桶中取出一個令牌；如果桶為空，則等待直到有新令牌加入。

實現要點：

• 桶容量 = 最大突發請求數（例如 30）。
• 每秒恢復令牌數 = 目標速率（例如 30 次/秒）。
• 群發時，從桶中取令牌，取不到就排隊等待，而不是直接回傳錯誤。

請求優先級調度

不是所有請求都同等重要。即時聊天訊息（用戶問客服）優先級遠高於批量群發（促銷通知）。你可以將請求分為兩個佇列：

• 高優先級佇列：用戶主動發起的訊息回覆、命令處理。這些請求應盡量快速執行，即使稍微超過速率限制，也應優先處理（但依然要遵守 retry_after）。
• 低優先級佇列：批量群發、後台資料同步。這些請求可以被限流、延遲甚至降級。

透過優先級調度，確保核心客服功能不受限流影響，同時群發任務在後台平穩執行。

業務層應對：減少請求量的設計模式

除了控制請求速率，你還可以從業務架構上減少 API 呼叫次數。

利用 Telegram 批量 API 減少請求

Telegram 提供了多個批量介面，可以一次請求發送多條內容：

• sendMediaGroup：一次發送最多 10 張圖片/影片/檔案。
• sendAlbum：同上，專用於相簿。
• sendMessage 不支援批量文字，但你可以將多條訊息合併為一條長訊息（Markdown 格式），或者使用 reply_to_message_id 實現分組效果。

場景示例：如果群發通知包含 3 張圖片和一段說明，使用 sendMediaGroup 一次發送，比分開呼叫 sendPhoto 和 sendMessage 減少 3 次請求。

用戶畫像本地快取

每次需要用戶資訊（如語言、時區、用戶名）時，呼叫 getChat 或 getUserProfilePhotos 都會產生一次 API 請求。更好的做法是：

1. 首次獲取用戶資訊後，儲存在本地資料庫或快取中（如 Redis）。
2. 設定快取過期時間（例如 1 小時）。
3. 後續需要時，優先從快取讀取，僅當快取過期或明確需要最新資料時再調 API。

這種方式能大幅減少 getUser 類請求，尤其適用於客服場景——坐席頻繁查看用戶畫像時。

使用 TG-Staff 等平台自動管理限流

如果你不想手動實現上述所有策略，可以考慮使用專業的客服與營運平台。例如 TG-Staff 內建了請求佇列、退避策略和並發控制，讓你無需關心底層限流邏輯。

• 即時雙向聊天：自動管理訊息傳送佇列，確保使用者訊息優先，群發任務排隊執行。
• 批次群發：內建令牌桶演算法，自動控制傳送速率，避免觸發 429。
• 可視化命令流程：透過拖曳式編輯器建構 Bot 互動，平台自動處理 API 呼叫頻率。

常見問題 (FAQ)

Q: 429 後多久能恢復？

A: 取決於 retry_after 欄位。通常 Telegram 會指定 1-30 秒的等待時間。如果你嚴格按照該欄位等待，恢復後即可繼續請求。如果忽略該欄位持續重試，限流時間可能延長至數分鐘甚至數小時。

Q: 限流會影響所有 Bot 嗎？

A: 是的，每個 Bot 獨立限流。一個 Bot 的限流不會影響其他 Bot。但如果你在同一個伺服器上運行多個 Bot，總請求量可能會影響伺服器網路，但 API 限流是 Bot 層級的。

Q: 如何測試 Bot 的限流閾值？

A: 你可以編寫一個測試腳本，逐步增加每秒請求數，觀察何時出現 429。建議在測試環境或非生產 Bot 上進行，避免影響正式用戶。也可以使用 Telegram 官方測試伺服器（api.telegram.org 的測試節點），但注意其限流規則可能與生產環境不同。

Q: 群發時如何避免觸發限流？

A: 使用請求佇列控制速率（如每秒 20 次），並處理 retry_after。另外，將用戶分批次發送，每批之間留出間隔。TG-Staff 的批量群發功能已內建這些邏輯。

總結與最佳實踐

應對 Telegram Bot 429 限流，關鍵是從被動退避到主動控制。以下是可落地的檢查清單：

1. 理解限制：確認你的 Bot 類型和大致配額，避免盲目請求。
2. 退避重試：始終解析 retry_after，嚴格等待後再重試。
3. 佇列控制：使用令牌桶或滑動視窗演算法，主動限制請求速率。
4. 優先級排程：區分即時訊息與群發任務，確保核心功能優先。
5. 減少請求：用批量 API、快取用戶數據、合併訊息等方式降低請求量。
6. 藉助工具：如果團隊資源有限，考慮使用 TG-Staff 等平台自動處理限流。

下一步行動：

• 立即註冊 TG-Staff 試用（app.tg-staff.com），體驗內建的限流管理。
• 查閱完整文件（docs.tg-staff.com）了解進階配置。
• 如有問題，聯繫客服 Bot @tgstaff_robot 獲取技術支援。

正確處理 Telegram 429 限流，不僅能讓你的 Bot 穩定運行，還能提升用戶體驗和運營效率。從今天開始，優化你的請求策略吧。