n8nのWebhookでテストURLと本番URLを取り違えて動かないとき

まず症状から見当をつける

次の表は、症状から原因候補を絞るための早見表です。公式の仕様から導ける組み合わせを、編集側で整理しました。

• エディタでは動くが、外部サービスからだと動かない、疑う原因：送信元にテストURLを登録している、最初にやること：送信元の登録URLを本番URLに変える
• 外部サービスからは動くのに、エディタに何も表示されない、疑う原因：本番URLが動いていて、エディタには出ない仕様、最初にやること：Executions タブを見る
• 本番URLに送っても届かない、疑う原因：ワークフローが未公開、または公開処理が終わっていない、最初にやること：公開状態を確認する
• テストURLに送っても届かない、疑う原因：待ち受け中でない、または待ち受け時間が切れた、最初にやること：もう一度「Listen for Test Event」を押してから送る
• どのURLでも届かない、疑う原因：メソッド不一致、パス違い、自分のn8nのURL設定の誤り、最初にやること：後述のチェックリスト4〜6

特に2行目は「動いていないのではなく、見る場所が違う」ケースです。本番URLの実行結果はエディタ上のノードに流れてこないため、Executions を見ずに「反応がない」と判断してしまいがちです。

テストURLと本番URLの違いを押さえる

テストURL

• 「Listen for Test Event」を押した後に待ち受ける用途です。
• Webhookノードのよくある問題のページには、待ち受け時間が120秒と書かれています。ボタンを押してから送信元で操作するまでに時間が空くと、受け付けなくなります。
• 送信元が「テスト送信」ボタンを持っていない場合、待ち受け中にこちらから別途リクエストを送る必要があります。

本番URL

• ワークフローを公開している間、継続して受け付けます(公開を取り消すまで)。
• 公開は非同期です。公開に関する公式ドキュメントには、変更のあったトリガーだけをバックグラウンドで反映すると書かれており、公開ボタンが「Publishing」と表示されている間は反映の途中です。
• 本番の実行は「公開済みのバージョン」を使います。公開後にエディタで編集しても、再公開するまでは本番に反映されません。「直したのに挙動が変わらない」ときは、再公開し忘れを疑います。

なお、同じドキュメントでは「公開」と「有効化(activate)」を区別せず、公開という言葉で説明しています。古い解説記事やUIで「Active」と書かれているものは、公開と同じ意味で読み替えて問題ありません。ただし、お使いのn8nのバージョンによって画面の表記は異なる可能性があります。

動かないときの確認順チェックリスト

上から順に確認します。各項目は、前の項目で問題がないことを前提に進みます。

1. どちらのURLを使っているかを特定する。 Webhookノードを開き、上部のURL表示を「Test URL」と「Production URL」で切り替えて、送信元に登録している文字列と見比べます。URLの途中が違うことが多いはずですが(多くの環境で webhook-test と webhook の違いとして現れます)、まずは文字列全体を比較してください。
2. テストか本番か、目的を決める。 開発中の確認ならテストURL、外部サービスから自動で動かしたいなら本番URLです。送信元に残すのは本番URLです。
3. 状態を合わせる。 テストURLなら「Listen for Test Event」を押した直後(120秒以内)に送ります。本番URLならワークフローが公開済みで、「Publishing」の表示が消えていることを確認します。
4. HTTPメソッドを合わせる。 Webhookノードの既定では受け付けるメソッドが1つです(同じよくある問題のページに記載)。ノードがPOSTなのに送信元がGETだと一致しません。必要なら「Allow Multiple HTTP Methods」を有効にします。
5. パスの重複や打ち間違いを確認する。 同じパスと同じメソッドのWebhookを複数登録するとエラーになります。重複している側のワークフローを公開停止するか、パスかメソッドを変えます。
6. URLの「ホスト部分」が外から届くものか確認する。 自分でn8nを運用していてリバースプロキシを使う場合、WEBHOOK_URLの公式ページによると、n8nは既定ではプロトコル・ホスト・ポートからURLを組み立てるため、プロキシ越しだと外部から届かないURLが表示されることがあります。同ページでは、WEBHOOK_URL から N8N_WEBHOOK_URL への置き換えが案内されているので、お使いのバージョンに合う変数名を確認してください。
7. Executions を見る。 本番URLの場合、受信できていれば Executions に実行が残ります。残っていればURLは正しく、問題はその後のノードです。残っていなければ、リクエストがn8nまで届いていません。
8. 送信元側のログを見る。 送信元に配信履歴(送信ステータスやHTTPコード)があれば、404などのコードを確認します。404は「そのURLは今は登録されていない」ことを疑う手がかりになります。

送信元に登録したURLを確認する手順

送信元(例:フォームサービス、決済、チャットツールなど)の画面は、サービスごとに異なります。ここでは共通して使える手順を示します。

1. n8nのWebhookノードで「Production URL」を表示し、コピーします。
2. 送信元のWebhook設定画面を開き、登録済みURLを表示します。
3. 2つの文字列を、メモ帳などに貼り付けて並べ、先頭から末尾まで比べます。見るのは、https か http か、ホスト名、パス、末尾のスラッシュ、クエリ文字列の有無です。
4. 一致しなければ、n8n側のProduction URLに置き換えて保存します。
5. 送信元に「テスト送信」があれば実行し、n8nの Executions に実行が増えることを確認します。ない場合は、実際に1件だけ操作して発火させます。
6. 動作確認が終わったら、テストURLが他の連携先に残っていないかも確認します。

外から届くかを手元で確認する(説明用の例)

次のコマンドは、本番URLが受け付けるかを確かめる簡単な例です。URLはダミーで、お手元のProduction URLに置き換えてください。このコマンド自体は、記事執筆時に実行していません。

curl -i -X POST "https://n8n.example.com/webhook/sample-path" \
  -H "Content-Type: application/json" \
  -d '{"test":"hello","source":"manual-check"}'

• ワークフローが公開済みで、ノードのメソッドがPOSTなら、Executions に実行が1件増えるはずです。
• 増えずに404系の応答なら、チェックリストの3〜6に戻ります。
• テストURLを試すときは、先に「Listen for Test Event」を押し、URLだけをテスト用に差し替えます。

AIに任せる部分と、人が確認する部分

ChatGPTやClaudeなどのAIに相談する場合は、次の依頼文が使えます。URLのホスト名やトークンは、必ずダミーに置き換えてから貼ってください。パス部分に秘密の文字列が含まれることもあります。

n8nのWebhookが動きません。次の情報で、原因候補を可能性の高い順に3つ、
確認方法つきで挙げてください。断定せず、確認が必要な点も書いてください。

- n8nの種類: セルフホスト(リバースプロキシあり) / Cloud のどちらか
- Webhookノードの設定: メソッド=POST、パス=sample-path
- 送信元に登録したURL: https://n8n.example.com/webhook-test/sample-path
- ワークフローの状態: 公開済み / 未公開
- 症状: 送信元では「送信済み」だがExecutionsに何も出ない
- 送信元の配信ログのHTTPコード: 404

AIに任せるのは、貼り付けた情報からの原因候補の整理までです。実際に登録されているURL、公開状態、Executionsの有無は、人が画面で確認します。AIは画面を見ていないため、答えに含まれるURLの形式やバージョン固有の設定は、公式ドキュメントで裏取りしてください。

直らないときの切り分け

チェックリストをすべて確認しても届かない場合は、範囲を分けます。

• 本番URLでcurlが成功し、送信元からは失敗する: 送信元側の設定(登録URL、署名検証、送信条件)の問題です。送信元の配信ログを確認します。
• curlも失敗する: n8n側(公開状態、メソッド、パス、ホスト設定)か、ネットワーク(プロキシ、ファイアウォール)を疑います。
• Executionsに実行はあるが失敗している: Webhookの取り違えではなく、後続ノードの問題です。実行詳細のエラー内容を見ます。
• Cloudで長い処理が失敗する: 公式のよくある問題には、n8n Cloudでは100秒を超えるリクエストが失敗する(524)と書かれています。先に即時応答を返し、結果は別のWebhookで取得する構成が案内されています。

運用の目安としては、開発中はテストURL、運用に入ったら送信元の登録を本番URLに1回だけ切り替え、その後は公開済みの状態を保つ、という流れにすると取り違えを減らせます。