n8nのWebhookが動かない原因と対処法｜テストURLと本番URLの罠

n8nのWebhookが動かないときは、原因のほとんどが「本番URL（/webhook/）とテストURL（/webhook-test/）の取り違え」と「ワークフローが有効化（Active）になっていない」の2つに集約されます。外部アプリからPOSTしても反応がない、`The requested webhook is not registered` という404が返る――そんな症状を、2026年時点のn8nの仕様にもとづいて症状別に切り分け、対処法を手順つきで解説します。

この記事は「Webhookが起動しない・登録されないエラー」の切り分けに特化しています。n8nそのものの導入や基本操作から確認したい場合は、n8nの使い方入門（業務自動化ワークフローの作り方）をあわせてご覧ください。

n8nのWebhookが動かないときにまず確認する2つのURL

n8nのWebhookノードは、テスト用と本番用でURLが分かれているのが最大のつまずきポイントです。ここを取り違えると、どれだけ設定を見直しても動きません。まずは自分がどちらのURLを使っているかを確認してください。

テストURL（/webhook-test/）は「1回だけ」動く

テストURLは、エディタ画面で「Listen for test event」または「Execute workflow」を押した直後の1回だけリクエストを受け付ける仕様です。ボタンを押さずに外部から送信しても反応しませんし、1回受信するとリスニングは解除されます。動作確認のときに便利な反面、実運用のアプリ連携にテストURLを使うと必ず途中で止まります。

本番URL（/webhook/）はワークフローが有効なときだけ動く

本番URLは、ワークフローをActive（有効）にしている間だけ常時リクエストを受け付けます。逆に言えば、ワークフローがInactiveのままだと本番URLに送信しても登録されておらず、404が返ります。実際のアプリやサービスと連携するときは、必ず本番URLを使い、ワークフローを有効化しておく必要があります。

テストURLと本番URLの違い【比較表】

編集部で混同しやすいポイントを一覧にまとめました。まずは自分の使い方がどちらに当てはまるかを確認してください。

出典: n8n公式ドキュメント（Webhookノード）

「The requested webhook is not registered」が出る主な原因

Webでもっとも多く相談される404エラーが `The requested webhook is not registered` です。このメッセージは「そのURLに対応するWebhookが今は待ち受けていない」という意味で、原因は次の3つに絞られます。

ワークフローが有効化されていない

本番URLを使っているのにワークフローがInactiveのままだと、このエラーが返ります。エディタ右上のActiveトグルをオンにするのが基本の対処です。トグルを切り替えた瞬間に本番Webhookが登録されます。

本番URLなのに「Execute workflow」頼みになっている

本番URL（/webhook/）を使いながら、動作確認のときと同じく「Execute workflow」を押した時だけ動く状態になっているケースです。この場合、ボタンを押さずにライブでリクエストを送ると同じ404が出ます。本番URLは有効化で常時待ち受けさせるもの、と切り替えて考える必要があります。

テストURLを外部アプリに登録してしまっている

連携先のアプリ側に、うっかりテストURL（/webhook-test/）を貼り付けているパターンです。テストURLは1回きりの待ち受けなので、アプリからの定期的な通知はほぼ失敗します。連携先に登録するURLは、必ず本番URLに差し替えてください。

症状別・n8n Webhookトラブル早見表

ここまでの原因を、実際の症状から逆引きできる形で整理しました。まずは自分の症状に近い行を確認し、対処の当たりをつけてください。編集部が実際に詰まりやすい順に並べています。

本番運用で動かないときのチェックリスト

有効化しても本番Webhookが届かない場合は、URLそのものや環境側の設定を疑います。次の観点を順に確認すると、原因を早く特定できます。

URL・メソッド・パスの不一致を確認する

• URLの種別：連携先に登録したのが/webhook/（本番）になっているか
• HTTPメソッド：WebhookノードのメソッドとリクエストのメソッドがGET/POSTで一致しているか
• パス（path）：ノードで指定したパス文字列と送信先URLの末尾が完全一致しているか
• 認証設定：Webhookノードに認証（Basic認証やヘッダー）を付けた場合、送信側にも同じ認証情報を渡しているか

セルフホスト特有の設定を確認する

Docker等でセルフホストしている場合、n8nが生成するWebhook URLは環境変数の設定に依存します。外部からアクセスできない・URLがlocalhostになってしまうときは、次を確認してください。

• WEBHOOK_URL（またはN8N_HOST／N8N_PROTOCOL）に、外部からアクセスできる公開URLを設定しているか
• リバースプロキシ（Nginx等）が、Webhook用のパスを正しくn8nへ転送しているか
• ファイアウォールやセキュリティグループで、対象ポートが開放されているか

出典: n8n公式ドキュメント（Webhook URLの設定）

よくあるn8n Webhookの失敗例と回避策

設定自体は正しくても、運用の思い込みでつまずくケースが少なくありません。編集部で実際に見聞きした失敗例を挙げておきます。

失敗例1：テストで動いたから本番も動くと思い込む

もっとも多いのがこれです。エディタで「Execute workflow」を押してテストURLが通ったので完了したつもりになり、ワークフローを有効化しないまま連携先へURLを渡してしまう。結果、本番リクエストがすべて404になります。テスト成功と本番稼働は別物と覚えておくと防げます。

失敗例2：ワークフローを編集後に保存・再有効化していない

Webhookノードのパスや設定を変更したあと、保存や再有効化を忘れると、古い設定のまま登録が残ったり、新しいパスが登録されなかったりします。設定を変えたら保存し、必要に応じてトグルを一度オフ→オンにし直すと、登録が確実に更新されます。

失敗例3：同じパスのWebhookを複数作って競合させる

同一パスのWebhookノードを複数のワークフローで有効化すると、どちらが受けるか競合し、意図しない方が反応することがあります。パスはワークフローごとに一意になるよう命名しておくと、切り分けが楽になります。

それでも動かないときの切り分け手順

ここまでを試しても解決しない場合は、次の順で切り分けると原因を絞り込めます。

• まずエディタでテストURL＋「Execute workflow」を試し、n8n内部でノードが正しく動くか確認する（ここで動けばワークフロー自体は正常）
• 次にワークフローを有効化し、ブラウザやcurlから本番URLを直接叩いて、Executions一覧に記録が残るか確認する
• 本番URLが通るなら、最後に連携先アプリのURL・メソッド・認証を実機の設定と突き合わせる

この「内部→本番URL単体→連携先」の順で見ていくと、問題がn8n側にあるのか、送信元アプリ側にあるのかを切り分けられます。n8n以外の自動化ツールと使い分けたい場合は、トリガーの考え方が近いMakeとZapierの違いと業務自動化の始め方も参考になります。DifyのAIワークフローからn8nを呼び出して連携させたい場合は、Difyとn8nを連携する手順（API・Webhookの設定）で具体的な繋ぎ方を解説しています。

まとめ｜n8n Webhookは「本番URL×有効化」が基本

n8nのWebhookが動かない原因は、ほとんどが「テストURLと本番URLの取り違え」と「ワークフローの未有効化」に集約されます。実運用では本番URL（/webhook/）を使い、ワークフローをActiveにしておく――この2点を押さえるだけで、`The requested webhook is not registered` の多くは解決します。それでも届かないときは、URL種別・メソッド・パス・認証、そしてセルフホストなら公開URLとプロキシ設定を順に確認してください。本記事の早見表で症状から原因を切り分ければ、多くのケースは数分で復旧できます。