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 切換排障流程,不要把切換傳送方式當作私隱模式測試。
進行受控驗收測試
在參與者知情的測試群組,由真人帳戶執行以下步驟。這是建議測試計劃,不是正式環境的實測結果:
- 私訊機械人發送文字,確認基本接收路徑。
- 在群組發送包含機械人實際用戶名稱的指定指令。
- 回覆機械人發出的一則訊息。
- 發送不含指令、也不是回覆的普通群組文字。
- 在獲批的可見範圍更改前後,比較原始傳送與應用程式紀錄。
私隱模式開啟時,指定互動能到達而普通文字缺失,符合文件描述。取得預期的較廣存取範圍後,再測試普通文字,將餘下問題分別交由傳送及處理邏輯排查。請使用新訊息;這不是歷史紀錄復原方法。不要用另一個機械人當發送者,機械人之間的訊息行為須另外驗證。
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,先完成群組訊息驗收。
令訊息接入變成一條穩定嘅產品管線。
先用統一嘅 API 跑通發送,再用標準事件將所有入站訊息接返去業務系統。