WhatsApp 觸發器無法接收事件及 Webhook 訂閱衝突(自託管 n8n)

大家好,
我仍在經歷此問題,一直無法解決。
我進行了額外測試:

  • 驗證了 OAuth 認證資料。
  • 驗證了 HTTPS/SSL。
  • 測試了測試 URL 和生產 URL。
  • 發佈了工作流程。
  • 確認 Meta 收到了 webhook 事件。
  • 工作流程仍然失敗,錯誤訊息為:
    「The WhatsApp App ID already has a webhook subscription.」
    有人之前經歷過這個問題嗎?或者能否建議我如何刪除現有的 webhook 訂閱或重設 WhatsApp Trigger?
    任何幫助都將不勝感激。
    謝謝。

環境

  • n8n 版本: 最新自託管版本
  • 部署方式: Docker
  • 託管供應商: Hostinger VPS
  • 作業系統: Ubuntu
  • 網域: https://n8n-teep.srv1761962.hstgr.cloud
  • HTTPS/SSL: 已啟用且正常運作
  • WhatsApp 整合: Meta WhatsApp Cloud API (OAuth)
  • AI 節點: OpenAI Chat Model

問題描述

我正在嘗試建立一個簡單的 AI 驅動型 WhatsApp 自動回覆工作流程。
工作流程:

WhatsApp Trigger
      ↓
AI Agent
      ↓
OpenAI Chat Model

AI Agent 永遠不會執行,因為 WhatsApp Trigger 從未收到傳入事件。

能正常運作的部分

  • WhatsApp OAuth 認證資料已成功連接。
  • OAuth 連接測試成功。
  • HTTPS 網域可以存取。
  • Meta WhatsApp Cloud API 測試號碼運作正常。
  • 我可以從 Meta Developer Dashboard 成功發送範本訊息。
  • Meta Developer Dashboard 在檢查測試 Webhooks 下顯示傳入的 webhook 事件。

無法正常運作的部分

當我點擊 WhatsApp Trigger 上的執行步驟時,它進入:

Listening for test event

我隨後向測試號碼發送一條 WhatsApp 訊息。
Trigger 從未收到事件,並持續無限期等待。
未建立執行。
AI Agent 從未啟動。

額外錯誤

當我發佈或執行工作流程時,我收到以下錯誤:

The WhatsApp App ID already has a webhook subscription.
Delete it or use another App before executing the trigger.
Due to WhatsApp API limitations, you can have just one trigger per App.

我已嘗試過的方法

  • 重新建立 WhatsApp OAuth 認證資料。
  • 驗證 OAuth 認證資料有效。
  • 測試了測試 URL 和生產 URL。
  • 發佈了工作流程。
  • 驗證了 SSL 憑證。
  • 確認 Meta 接收 webhook 事件。
  • 從頭重建工作流程。
  • 僅使用 WhatsApp Trigger 節點進行測試。
  • 從測試中移除了 AI Agent。
  • 驗證該問題與 OpenAI 節點無關。

其他資訊

我在另一個 Hostinger VPS 上運行著另一個自託管的 n8n 實例。
該相同的 Meta WhatsApp App 可能之前連接到該實例。
我不確定舊的 webhook 訂閱是否阻止此新實例註冊其 webhook。

問題

  1. 我如何識別目前為我的 WhatsApp App 註冊的 webhook?
  2. 有沒有辦法在不建立新 Meta App 的情況下移除或取代現有的 webhook 訂閱?
  3. WhatsApp Trigger 會自動取消註冊舊 webhooks 嗎?
  4. 是否有任何指令或 API 端點可用於手動重設 webhook 註冊?
  5. 我應該檢查自託管 n8n 實例上的哪些日誌來診斷 webhook 註冊失敗的原因?

預期行為

傳入的 WhatsApp 訊息應立即觸發工作流程。

實際行為

Trigger 保持「Listening for test event」狀態無限期,發佈工作流程會產生 webhook 訂閱衝突錯誤。
任何指導都將不勝感激。
謝謝。
以下是完整詳情:

@Hussain_Farooq 那個錯誤的原因就是,n8ns trigger 會檢查你的應用程式現有的 webhook 訂閱,當它的 callback_url 與 trigger 想要的 url 不符時就會退出,而 meta 每個應用程式只允許一個 webhook。所以 meta 是把你的事件傳送到那個其他的/舊的 callback url,這就是為什麼儀表板顯示有事件但 trigger 卻收不到的原因。修復方法:在你的 meta 應用程式儀表板中進入 WhatsApp > Configuration,刪除現有的 webhook callback(或將它設定為 n8n trigger node 上顯示的確切 url),然後啟動工作流程讓 n8n 註冊它的生產 url,並確保 messages 欄位已訂閱。每個應用程式只有一個 trigger,所以如果另一個流程或實例已經在那裡註冊了 callback,那就是你的衝突所在。

若要查看已註冊的內容,您必須使用 Meta Graph API Explorer 或 curl。訂閱發生在 WhatsApp Business Account (WABA) 層級,而不僅是應用程式層級。

**檢查方法:**向下列端點執行 GET 請求:https://graph.facebook.com/v21.0/{your-waba-id}/subscribed_apps (將 {your-waba-id} 替換為在 Meta Business Settings 中找到的您的 WhatsApp Business Account ID)。

如果回應包含您的應用程式 ID,表示該應用程式目前已訂閱以接收該帳戶的事件,這就是 n8n 被封鎖的原因。

若要「清除路徑」以供新的 n8n 實例使用,您需要取消該應用程式對 WABA 的訂閱。

透過 Graph API 修復:

  1. 前往 Meta Graph API Explorer。
  2. 選擇您的應用程式,並確保您具有 System User Token 或具有 whatsapp_business_management 權限的 Page Access Token。
  3. 將方法更改為 DELETE。
  4. 輸入端點:/{your-waba-id}/subscribed_apps
  5. 執行請求。這將移除該應用程式對 WABA 的訂閱,並解除「鎖定」。

不會,不會在不同實例之間可靠地執行此操作。 雖然該節點在您在 同一 實例上啟動工作流程時會嘗試更新 Webhook,但它無法知道由 不同 伺服器/VPS 建立的訂閱。當您遷移到新的 Hostinger VPS 時,Meta API 仍然記得舊 VPS 的回調 URL。

如果您偏好使用終端機,可以使用這些 curl 命令(替換佔位符):

檢查目前訂閱:

curl -X GET "https://graph.facebook.com/v21.0/<WABA_ID>/subscribed_apps?access_token=<YOUR_TOKEN>"

移除訂閱:

curl -X DELETE "https://graph.facebook.com/v21.0/<WABA_ID>/subscribed_apps?access_token=<YOUR_TOKEN>"

如果 API 清理後錯誤仍然存在,請檢查您的 Docker 日誌以查看來自 Meta 的確切原始錯誤回應:

docker logs -f <your-n8n-container-name>

查找包含 whatsapp 或 webhook registration 的條目。如果您看到來自 Meta 的具有特定錯誤代碼的 400 Bad Request,它將確認問題是「重複訂閱」還是「驗證失敗」(如果您的 WEBHOOK_URL 環境變數不正確,就會發生這種情況)。

如果您想立即解決此問題,請按照以下確切順序進行:

  1. **清理 Meta:**如上所述,對 /{waba-id}/subscribed_apps 執行 DELETE 請求。
  2. 清除 n8n 內部狀態:
    • 開啟您的工作流程。
    • 完全刪除 WhatsApp Trigger 節點。
    • 保存工作流程。
    • 重新整理瀏覽器頁面。
    • 從頭重新新增 WhatsApp Trigger 節點。(這會強制 n8n 忘記任何快取的註冊 ID)。
  3. 驗證環境變數: 確保您的 Docker 環境變數 WEBHOOK_URL 恰好是 https://n8n-teep.srv1761962.hstgr.cloud。
  4. 發佈: 先 「發佈」 工作流程,而不是點擊「執行步驟」。啟動工作流程是 n8n 註冊生產 URL 最可靠的方式。