← 所有文章
指南

Telegram 機械人收不到群組訊息?先檢查私隱模式

如果 Telegram 機械人收到私訊或明確指定它的指令,卻收不到普通群組訊息,先檢查私隱模式,不要急於更換 webhook。Telegram 預設開啟私隱模式,限制非管理員機械人可接收的群組訊息範圍。私訊測試成功,不代表機械人能讀取整個群組對話。先確認機械人身份、群組角色及更新篩選設定,再由真人帳戶發送新訊息測試。

重點

  • 群組訊息的可見範圍與更新傳送是兩回事。
  • 開啟私隱模式的機械人可接收相關指令及回覆,並非普通群組對話的完整訊息串流。
  • Telegram 要求關閉私隱模式後,將機械人重新加入群組,設定才會生效。
  • 只在工作流程確有需要時擴大存取範圍;不要為排查傳送問題而直接授予管理員權限。

Telegram 私隱模式控制甚麼

Telegram 官方機械人功能文件指出,開啟私隱模式的機械人可收到明確指定它的指令,例如 /command@this_bot,以及對發給該機械人的訊息的回覆。一般指令另有情境條件,不適合作為唯一診斷樣本。

官方文件將私訊、服務訊息及普通群組對話分開處理。因此,收到一則群組服務訊息,不代表機械人也應收到所有真人發送的文字。

官方文件說明,擔任群組管理員或關閉私隱模式的機械人,可見的群組訊息範圍較廣。這是存取權的決定,不是傳送效能優化。如果指令與回覆已足夠,應保留私隱模式,讓用戶明確與機械人互動。

本文針對部分群組訊息不可見。若仍在選擇機械人或帳戶層級收件方案,可先閱讀 Telegram Bot API webhook 與統一入站 webhook 比較

分層排查群組訊息缺失

觀察到的情況可能方向下一步
私訊正常,普通群組文字缺失群組訊息可見範圍受限檢查私隱模式及該群組內的角色
指定群組指令正常,普通文字缺失接收路徑至少能處理一類訊息確認是否確實需要完整群組內容
私訊和指定指令都沒有私隱模式不足以解釋故障檢查 token 身份、篩選設定及接收器
原始更新已到達,應用程式沒有顯示應用程式篩選或處理問題檢查處理條件及佇列紀錄
更改私隱設定後沒有差異現有群組成員狀態需要處理重新加入機械人,再發送新訊息

這些是診斷方向,不是確定原因。先記錄原始接收器收到甚麼,再修改權限或程式碼。

1. 確認機械人身份及群組角色

在可信的 API 用戶端呼叫 getMe,確認部署中的 token 屬於哪個機械人。Bot API 參考文件can_read_all_group_messages 定義為只由 getMe 回傳的選用欄位;值為 true 表示私隱模式已關閉。

這個欄位不是個別群組的角色報告。仍須在受影響群組確認機械人是否為成員、是否具管理員身份。不要將 token 放進截圖、共用請求紀錄或支援工單。

2. 採用最小必要的可見範圍

如果機械人只回應明確請求,測試指定其實際用戶名稱的指令,以及對機械人訊息的回覆。Telegram 亦建議不少流程使用強制回覆互動,而不是關閉私隱模式。

如確實需要處理真人發送的普通群組內容,由機械人擁有人檢查 BotFather 的 /setprivacy。擴大收集範圍前,先向群組管理員及成員說明。關閉私隱模式後,按官方指示安排移除並重新加入機械人,再核對群組角色。

不要在同一次測試中更改私隱模式、提升管理員權限和遷移接收器,否則無法分辨哪項更改有效。

3. 檢查更新篩選,不要先切換傳送方式

Bot API 的 allowed_updates 按更新類型篩選。測試文字訊息時,確認預期設定包含 message。Telegram 文件說明,省略 allowed_updates 會沿用之前設定,不代表重設。

篩選器不會授予機械人原本沒有的群組存取權;擴大群組存取範圍亦不會修正排除了目標更新的篩選設定。

如果所有傳送都失敗,請使用獨立的 getUpdates 與 setWebhook 切換排障流程,不要把切換傳送方式當作私隱模式測試。

進行受控驗收測試

在參與者知情的測試群組,由真人帳戶執行以下步驟。這是建議測試計劃,不是正式環境的實測結果:

  1. 私訊機械人發送文字,確認基本接收路徑。
  2. 在群組發送包含機械人實際用戶名稱的指定指令。
  3. 回覆機械人發出的一則訊息。
  4. 發送不含指令、也不是回覆的普通群組文字。
  5. 在獲批的可見範圍更改前後,比較原始傳送與應用程式紀錄。

私隱模式開啟時,指定互動能到達而普通文字缺失,符合文件描述。取得預期的較廣存取範圍後,再測試普通文字,將餘下問題分別交由傳送及處理邏輯排查。請使用新訊息;這不是歷史紀錄復原方法。不要用另一個機械人當發送者,機械人之間的訊息行為須另外驗證。

UnifyPort 的適用範圍

UnifyPort 不是 BotFather 設定,也不是現有 Bot API webhook 的修復工具。它透過非官方介面連接訊息帳戶,輸出標準化事件。如果真正需要的是現有帳戶的收件箱,而非公開機械人,先閱讀 Telegram 授權文件再決定架構。

在這條獨立路徑中,message.received 表示觀察到一則訊息;判斷是否入站前,需檢查 data.message.direction。結構以事件文件為準。設定 signing_secret 後,按 webhook 傳送文件進行 HMAC-SHA256 簽署驗證。

標準化結構不會授予任意群組的存取權,也不保證找回漏收訊息。UnifyPort 沒有讀取訊息歷史的 REST API,亦不保證重播。收到已授權事件時立即儲存,不要把群組內容傳送到不需要這些資料的下游系統。

常見問題

為何私訊正常,卻收不到群組文字?

私訊傳送與群組可見範圍遵循不同規則。先檢查私隱模式及群組角色,再檢查更新與應用程式篩選。

必須將機械人設為管理員嗎?

指令與回覆流程不需要。採用最小必要權限;管理員角色還有接收訊息以外的責任。

已關閉私隱模式,為何沒有變化?

Telegram 要求重新將機械人加入群組。確認機械人與群組正確,再由真人發送新文字,檢查原始接收器。

改用 getUpdates 能收到更多群組訊息嗎?

不能。更改傳送方式不會改變私隱模式或群組權限,可見範圍應獨立排查。

來源及下一步

官方資料核對日期:2026-09-16。

帳戶層級收件方案從 Telegram 授權文件開始;機械人專用方案則繼續使用官方 Bot API,先完成群組訊息驗收。

UnifyPort API

令訊息接入變成一條穩定嘅產品管線。

先用統一嘅 API 跑通發送,再用標準事件將所有入站訊息接返去業務系統。