Webhook 未收到來自 Google Chat API 的請求（直接 HTTP 呼叫運作正常）

問題
1

描述问题/错误/问题

我有一个已发布的工作流，使用 Webhook 节点（配置为
“响应：使用 Respond to Webhook Node”）作为
Google Chat 应用的后端。
问题：

  • 当我手动向我的生产 webhook URL 发送 POST 请求
    （通过 PowerShell/Invoke-RestMethod），工作完美：
    执行显示在
2

嗨 @Octa-004 歡迎！
這幾乎肯定是你的 Webhook 節點的驗證問題，而不是邊緣或 Cloudflare 阻止。Google Chat 用自己的 Authorization: Bearer <JWT>（由 chat@system.gserviceaccount.com 發出，User-Agent Google-Dynamite）簽署每個請求，因此無法攜帶你的 webhook 期望的任何認證。當 Webhook 節點啟用 Header、Basic 或 JWT 驗證時，n8n 會拒絕任何令牌不匹配的請求，並且永遠不會建立執行，這正是為什麼你用正確認證的 PowerShell 呼叫可以工作，Google Chat 不行，而且 Google 日誌記錄「沒有回應或其回應無效」。
將 Webhook 節點的驗證設定為 None 並重新發佈；Google 的請求將接著到達工作流程並記錄執行。若要在沒有 n8n 等級驗證的情況下保持安全，請改為在工作流程內驗證 Google 的 JWT：一個 Code 節點檢查發行者 chat@system.gserviceaccount.com 和受眾（你的應用程式的專案編號或端點 URL），拒絕任何失敗的項目。
針對你的兩個問題：n8n Cloud 在這裡不是選擇性地阻止 Google 的伺服器，而且執行前邊緣日誌不會向使用者公開，所以那是純支援檢視。你不需要它們，因為關閉驗證並重新測試可在一步內確認原因。
一旦交付有效，請確保「回應 Webhook」節點快速返回有效的 Chat JSON，如 {"text":"..."} ，這樣你就不會觸發程式碼 3 以取得真正無效的回應。
Verify requests from Google Chat  |  Google for Developers

3

來自 @Anshul_Namdev 的良好診斷——身份驗證不匹配正是為什麼你的手動 PowerShell 呼叫會建立執行，但 Google Chat 卻永遠不會。Google 使用自己的 Bearer JWT 簽署每個請求，所以 Webhook 節點上的任何 Header/Basic/JWT 身份驗證都會在執行建立前拒絕它。

值得補充的部分：一旦你將 Webhook 節點身份驗證設定為「無」以讓 Chat 通過，你就不會想讓端點完全開放。改為在流程內驗證 Google 自己的權杖。在 Webhook 後面放一個 Code（或 IF）節點，並檢查傳入的 Authorization Bearer JWT：

  • 發行者（iss）必須是 Google 的 Chat 系統服務帳戶（chat@system.gserviceaccount，簽署 Chat 請求的帳戶）
  • 對象（aud）必須等於你的 Chat 應用程式的數字專案編號
  • 根據該同一服務帳戶 Google 發布的 x509 憑證驗證簽名

如果任何檢查失敗，停止工作流程。只有真正的 Google Chat 流量會攜帶通過驗證的權杖，所以 Webhook 節點保持開放（Chat 的請求最終會建立執行），而隨機呼叫者會被過濾出去。這給你與節點身份驗證試圖提供的相同保護，而不會阻止你想要的傳送者。

4

我的自架 n8n 2.2.4 也出現相同症狀，而且身份驗證說明不符合我的情況。

問題

  • 手動 POST 到我的生產 webhook URL（curl、PowerShell）可行：執行出現、執行、返回預期回應。HTTP 200。
  • Google Chat 發送到同一 URL，但沒有建立執行。此 webhook 曾有的每個執行都具有 curl/8.5.0 或 PowerShell 的使用者代理。沒有任何 Google 來源的請求出現過，包括失敗的請求。
  • Google Cloud Logging：代碼 13，「由於內部錯誤，Chat 無法處理 bot 回應」，18 個項目。
  • Webhook 節點身份驗證不是原因。我的手動 POST 根本不發送授權標頭，仍然返回 200，所以該節點未強制執行憑證。工作流程未設定身份驗證——節點只是：

{ “httpMethod”: “POST”, “path”: “my-path”, “responseMode”: “responseNode”, “options”: {} }

typeVersion: 2，無身份驗證金鑰。回應 Webhook 是 respondWith: json，返回 hostAppDataAction.chatDataAction.createMessageAction 信封。

已檢查

  • 端點 URL 在 Chat API 控制台中逐字驗證，/webhook/ 而非 /webhook-test/。
  • 「建置為工作區附加元件」已勾選，應用程式狀態為 LIVE，互動功能開啟，所有觸發器的通用 HTTP 端點 URL。
  • 在三個新的 Google Cloud 專案中從頭重建 Chat 應用程式三次。每次結果相同。

問題

  1. 在自架 n8n 上，到達程序但從不建立執行的請求在哪裡出現？N8N_LOG_LEVEL=debug 是否會記錄 POST 到未登錄的路徑，或者還有其他方式確認到達？區分「Google 從未發送」與「n8n 在執行前捨棄」是阻礙。
  2. 生產 webhook 路徑在工作流程啟用且 URL 對手動呼叫返回 200 後是否無法登錄——導入後或重複工作流程後？此工作流程是透過 REST API 導入的，帶有人類可讀的 webhookId 字串而非 UUID。
  3. 在 Chat API 控制台中，此應用程式的服務帳戶電子郵件欄位根本不呈現——不存在、不是空白，頁面中任何地方都沒有 gsuiteaddons 字串。有人看過這種情況嗎，它是否表示附加元件部署從未登錄調度目標？
5

既然 @JGCoder 已確認 Webhook 節點不使用身分驗證且手動未驗證的 POST 有效，我會在變更 JWT 設定前分割診斷：

  1. 在傳送 Google Chat 測試事件時檢查反向代理/入口存取日誌。如果未出現 Google 來源請求，故障在 n8n 上游：驗證聊天應用程式的確切生產 URL、POST 方法、部署/可用性和測試使用者存取。
  2. 如果請求出現 30x 或 403，修正重新導向、WAF 或 TLS/代理規則。
  3. 如果到達 n8n 但未建立執行，驗證已發佈的 webhook 註冊以及確切的路徑和方法。

進行一次測試，將工作流程縮減至 Webhook (POST、生產 URL) -> 回應 Webhook，並在幾秒內以 {"text":"ok"} 傳回 HTTP 200。然後將 Google Cloud Logging 中顯示的 URL 和狀態與代理日誌進行比較。這樣可以確定故障是在 Google Chat 傳送、邊緣/代理還是 n8n 本身。