Webhook 測試工具報告「webhook_url is not valid (500)」，儘管生產環境的 webhook 可公開存取且能用 curl 正常運作

[usmangulzar2]

描述問題/錯誤/問題

我正在進行 n8n Academy N8N102 第 2 節（Webhook 評估），但無法通過第一個 Webhook 驗證。
Academy Webhook 測試工具報告：
「webhook_url is not valid. Please ensure your hostname resolves and is publicly accessible. Status Code: 500」（webhook_url 無效。請確保你的主機名解析並可公開訪問。狀態代碼：500）
但是，我的 Webhook 可公開訪問，並且使用 curl 手動測試時運行正常。
我已驗證以下內容：
正在使用生產 Webhook URL（而不是測試 URL）。
工作流已發布。
n8n 在公開 VPS 上運行，位於 Nginx 後面，使用 HTTPS。
DNS 和 SSL 正在運行。
重新使用了第 1 節中的相同 n8n Academy API 金鑰認證。
Webhook 認證設定為標頭認證。
curl 成功連接到 Webhook。
當 Webhook 配置為立即回應時，我收到：
{
“message”: “Workflow was started”
}
當配置為使用「回應至 Webhook 節點」回應時，我收到：
{
“code”: 0,
“message”: “No Respond to Webhook node found in the workflow”
}
Academy 測試工具仍將 Webhook URL 報告為無效。
有人在使用 Academy Webhook 測試工具時遇到過這個問題嗎，或者測試工具是否需要特定的東西，與普通 Webhook 不同？

錯誤訊息是什麼（如果有的話）？

請分享你的工作流

分享最後一個節點返回的輸出

n8n 設定的相關資訊

• n8n 版本： 2.31.6
• 資料庫（預設值：SQLite）：不適用
• n8n EXECUTIONS_PROCESS 設定（預設值：own, main）： 預設值
• 透過以下方式運行 n8n（Docker、npm、n8n cloud、桌面應用程式）： Docker on Ubuntu VPS behind Nginx
• 作業系統： Ubuntu 24.04 LTS

[zautomation]

curl 螢幕截圖是這裡的關鍵線索。這看起來不再像是 DNS、SSL 或 Nginx，因為請求已到達 n8n，而 n8n 才是傳回 500 的一方。

具體的錯誤訊息是：「在工作流程中找不到 Respond to Webhook 節點」。

這通常表示 Webhook 節點被設定為「使用 Respond to Webhook Node 進行回應」，但對於此次執行，n8n 無法從該 Webhook 路徑到達任何 Respond to Webhook 節點。

如果您的實際工作流程包含超過所分享的節點數量，我會檢查 Respond to Webhook 節點是否已連接，以及對於此 POST 請求是否總是被到達。若要進行快速驗證，在 Webhook 之後直接新增一個 Respond to Webhook 節點，並傳回簡單的 200 回應，然後再次執行 curl。一旦 curl 傳回 200 而非 500，Academy 測試器應該就會停止將該 URL 視為無效。

[Byte_Nova]

測試者的主機名訊息在此處具有誤導性：HTTP 500 和 No Respond to Webhook node found 回應證明請求已經通過 DNS、TLS、Nginx 和 Webhook 節點。如果標頭身份驗證是問題所在，您通常會看到 401/403，而不是這個工作流程層級的 500。

使用 Using Respond to Webhook Node 時，必須在每條可能的執行路徑上都可以到達 Respond 節點。斷開連線、已停用或僅存在於另一個 IF 分支上的 Respond 節點等同於該請求沒有任何節點。

我會用一條臨時路徑來隔離它：

Webhook（相同的 POST + 標頭身份驗證）-> Respond to Webhook（固定 JSON，狀態 200）

移除所有 IF/資料庫分支以進行此測試，並傳送與 Academy 測試者的方法、標頭和正文相符的 curl 請求。確認執行可見地到達 Respond 節點，且 curl 收到 200。然後恢復驗證邏輯，並使用其自己的可到達回應結束每個成功/錯誤分支。如果 Academy 測試者在最小路徑返回 200 後仍報告 500，請將測試者時間戳記與 Nginx 存取日誌進行比較，以確認它是否命中相同的生產 URL。