n8nのWebhookが本番で動かない原因7選｜確認順

このページが合う人：Test URLでは動くのに、Production URLではn8nへ届かない、または送信元だけtimeoutになる人。

分かること：未送信、n8nへ未到達、ワークフロー内部の失敗を分け、確認する区間を1つに絞れる。

先に用意するもの：送信元の配信時刻、HTTPメソッド、URLのホスト名とパス、HTTPステータスコード、同時刻のn8n実行履歴の有無。トークン、署名、Authorizationヘッダー、実データは記録しない。

次の行動：同時刻の実行履歴を開き、「記録なし」「記録あり・失敗」「記録あり・成功」のどれかを確認する。

入力から先に絞る：n8n Webhook本番化チェックは、実URLへ通信せず、公開状態・実行履歴・HTTPステータスから最初に見る区間を約3分で返す。

結論：送信元からn8nへ1区間ずつ確認する

「本番で動かない」を、送信されていない、n8nへ届かない、Webhookは受けたが後続で失敗した、の3つへ分ける。Executionsに対象時刻の記録がなければ入口側、記録があれば失敗ノード側を調べる。

観測結果	最初に確認	次の場所
送信履歴なし	送信元の発火条件・公開状態	送信元サービス
送信済み・n8n実行履歴なし	URL、メソッド、認証、プロキシ、パス	Webhookの入口
実行履歴あり・失敗	Webhookの出力と失敗ノード	ワークフロー内部
送信元だけtimeout	Webhookの応答方式と処理時間	応答経路

原因1：送信元にTest URLが残っている

n8nはWebhookノードごとにTest URLとProduction URLを生成する。Test URLはListen for test eventを選んだ後の120秒だけ待ち受ける。Production URLはワークフローを公開している間、待ち受ける。

外部サービスのWebhook設定へProduction URLを登録し直す。URLを目視だけで比べず、ホスト名、/webhook/または/webhook-test/、末尾のパスを分けて記録する。Production URLから届いたデータは編集画面へ直接表示されず、実行履歴（Executions）で確認する。

原因2：ワークフローが公開されていない

Production URLはワークフローを公開すると登録され、公開を解除すると待受を止める。保存済みでも未公開なら同じではない。対象ワークフローを開き、現在の公開状態と、送信元が呼んだ時刻を照合する。

公開し直す前に、同じ入力が再送されても重複処理しないか確認する。メール送信、顧客登録、請求、在庫更新を含む場合、送信元の再試行や手動再送で副作用が重なる。

原因3：HTTPメソッド・パス・認証が一致しない

Webhookノードで選んだGET・POSTなどのHTTPメソッドと、送信元のメソッドを一致させる。パスだけでなく、Basic認証、Header認証、JWT認証の有無も確認する。秘密値を一時的に無効化して試すのではなく、合成データと検証用の認証情報で経路を分ける。

送信元がHMAC署名を付ける場合、解析後のJSONではなく受信した本文そのものを使う。署名は届くが一致しないときは、n8nでraw bodyからHMAC署名を確認する手順へ進む。

安全な検証先なら、送信元と同じHTTPメソッド・Content-Type・最小の合成データで1回だけ呼ぶ。HTTPステータスコード、応答本文、時刻を記録し、同じ時刻の実行履歴（Executions）を照合する。

curl --request POST 'https://n8n.example.com/webhook/example-path' \
  --header 'Content-Type: application/json' \
  --data '{"probe":"synthetic"}'

上のURLは例。実際のproduction URL、必要な認証、送信元が要求する署名方式へ置き換える。公開中の第三者Webhookへ無断で送らない。

原因4：リバースプロキシ後の公開URLが誤っている

セルフホストでn8nをNginx、Caddy、Cloudflare Tunnelなどの後ろに置くと、n8n内部の5678番と外部のHTTPS URLが異なる。現行のn8n公式手順は、公開URLをN8N_WEBHOOK_URLへ設定し、プロキシ段数をN8N_PROXY_HOPSへ設定する。旧WEBHOOK_URLは非推奨の別名で、起動時に警告対象。

最後段のリバースプロキシからX-Forwarded-For、X-Forwarded-Host、X-Forwarded-Protoが渡る構成も確認する。環境変数を変える前に現行設定を保存し、再起動後にWebhookノードへ表示されるProduction URLと外部URLを比較する。

原因5：同じパスとメソッドを別のワークフローが使っている

n8nが登録できる本番Webhookは、同じパスとHTTPメソッドの組合せにつき1つ。競合メッセージが出る場合、古いワークフローを非公開にするか、一方のパスまたはメソッドを変更する。

ワークフローを複製した後は特に確認する。古い方を削除する前に、送信元がどちらのURLを参照しているか、過去の実行履歴を残す必要があるかを判断する。

原因6：プロキシ・ロードバランサーがWebhookのパスをn8nへ渡していない

通常の本番Webhookは/webhook/*、手動テストは/webhook-test/*。キューモードでWebhook処理を分ける場合も、本番用とテスト用で転送先が異なる。プロキシの転送先、ファイアウォール、TLS証明書、DNSの順に外側から確認する。

編集画面が開く事実だけではWebhookの到達を証明しない。編集画面用のパスと/webhook/*が同じ接続先へ渡るか、プロキシのアクセスログとn8nログの同時刻を照合する。

原因7：Webhookは動いたが応答が間に合わない

Webhookノードは即時応答、最後のノード完了後、Respond to Webhookノードなどの応答方式を選べる。送信元の待ち時間が短い場合、長いAPI処理の完了を待たせず、受付応答と後続処理を分ける。

n8n CloudはWebhookが100秒以内に応答しない場合、Cloudflareの524で失敗するという公式制約がある。これはn8n Cloudの条件。セルフホストは利用中のプロキシ、ロードバランサー、送信元の待ち時間を個別に確認する。

5分で残す確認表

送信元の配信時刻、HTTPメソッド、HTTPステータスコードを記録。
登録URLがProduction URLか、ホスト名とパスで比較。
ワークフローが送信時刻に公開済みだったか確認。
同時刻の実行履歴に記録があるか確認。
セルフホストなら公開URL、プロキシ段数、転送ヘッダーを確認。
同一パス・メソッドの競合を確認。
実行履歴があるなら応答方式、所要時間、失敗ノードを確認。

変更前に戻せる状態を作る

環境変数、プロキシ設定、ワークフローの公開状態を同時に変えない。変更前の値、設定ファイル、n8nのバージョン、対象ワークフローのエクスポートを安全な場所へ保存し、1項目ずつ検証する。VPS移設や更新直後なら、暗号化キー・DB・DNSを含む切戻し手順も先に確認する。

実行履歴はあるが後続ノードで止まる場合、Webhookの入口は通過済み。n8nエラーの5段階切り分けへ移り、入力、エラー、HTTPステータスコードを確認する。

よくある質問

Production URLをブラウザで開けば確認できる？

WebhookノードがGET以外、認証あり、特定の入力データ前提なら同じ試験にならない。送信元と同じメソッド、ヘッダー、本文を、安全な合成データで再現する。

Test URLは公開運用に使える？

使わない。公式仕様ではListen for test event後の120秒だけ待ち受ける開発用URL。本番はワークフローを公開し、Production URLを送信元へ登録する。

Webhookを受けたのに画面へデータが出ない

Production URLの受信データは編集画面へ直接表示されない。ワークフローまたはOverviewの実行履歴（Executions）から該当実行を開く。

公式情報

広告・更新履歴

本ページにアフィリエイト広告なし。n8n公式ドキュメントと公式GitHub上の現行docsに照合し、個別環境の原因特定や復旧を保証しない。

初稿・公式手順確認：2026-08-13 / 個別障害の実測なし / N8N_WEBHOOK_URLの現行表記へ照合済み