404はURL登録、405は依頼種別と応答元、200空は実行記録から確認します。
まず送信・更新を行わない専用テストworkflowを用意し、curlで合成データを1件送ります。返ったHTTP番号と本文、受信データの目印IDを照合します。 開発用URLは待受中だけ、本番用URLは保存・公開後だけ使います。本番は保存・閲覧できる実行記録も照合し、2xxだけで処理成功とは判断しません。
「届いた」は、応答とExecutionを分けて確認します。
Webhookは、外部サービスからn8nへHTTPリクエストを送ってworkflowを始める入口です。呼び出し側に200が返っても、狙ったworkflowが実行されたとは限りません。
逆にProduction URLは、受信データをEditorのキャンバスへ表示しません。画面が動かないだけで失敗と決めず、Executionsに新しい行があるかを確認します。
HTTPメソッドはGETやPOSTなど依頼の種類、PublishはProduction URLを有効にする公開操作、Executionはn8nに残る1回の実行記録です。probe_idは、送信とExecutionを結ぶため自分で付ける合成データの目印です。
依頼、URL登録、Execution、応答の4点を左から照合します。
- REQUEST同じURL・methodで送ったかcurlのstatus・本文→
- REGISTERそのURLは今、登録中かTest待受／Production Publish→
- EXECUTEExecutionが作られたかExecutions・probe_id→
- RESPONDどの本文を返す設定かRespond・body・所要時間
図は診断順を簡略化したものです。HTTP応答と、Testの受信データ／本番の保存・閲覧できるExecutionを照合し、どこまで進んだか確認します。
同じ送信時刻の1件を追います。実行記録は保存設定や権限で見えないことがあるため、一覧0件だけで未受信とは決めません。
Test URLとProduction URLを混ぜないことが、最初の分岐です。
n8nは1つのWebhook nodeに2つのURLを用意します。Test URLは開発中の一時入口、Production URLは公開済みworkflowの継続入口です。
TEST URL
/webhook-test/…Listen for test event後、120秒だけ待ち受けます。受信データはEditorで確認します。
PRODUCTION URL
/webhook/…workflowを保存・Publishして登録します。受信結果はEditorではなくExecutionsで確認します。
2026年9月21日にn8n公式資料で確認。画面名やPublishの表示は導入版で照合してください。
n8n公式の開発手順では、テスト中はTest URLをコピーし、Listen for test eventを押してから送ります。120秒を過ぎた場合は、同じURLでも登録が切れるため、もう一度待受を開始します。
本番確認ではProduction URLをコピーし、公開済み版を確認してから送ります。古いタブや別workspaceのURLを再利用せず、対象nodeからその場でコピーしてください。
現行の保存・公開手順では、編集は自動保存されますが、Productionが動かすのは公開済み版です。pathや応答を編集しただけなら、本番は以前の版のまま。公開前に差分と後続処理を確認します。workflow settingsのみの変更は自動再公開されるため、診断中の変更も慎重に行います。
curlで、送った内容と返った内容を1件に固定します。
外部サービスの管理画面には、再送、署名、独自のmethodが加わります。先にcurlで最小の1件を送れば、「n8nの入口」と「外部サービス固有の設定」を分けられます。
最初は「受け取って返すだけ」の2ノードで試します。
必要なのは、編集できるn8n環境とcurlが動くターミナルです。以下はmacOS・Linux・WSL向けの例です。既存の業務workflowを使わず、空のworkflow「Webhook診断」を作ります。メール、Slack、DB更新、購入などのnodeは接続しません。
- 01Webhookを追加する
HTTP MethodはPOST、Pathは初期生成された値を使い、RespondをUsing 'Respond to Webhook' Nodeにします。Only Run If等の追加条件は付けません。
- 02Respond to Webhookをつなぐ
Webhookの出力から直接接続し、Respond WithはFirst Incoming Item、Response Codeは200にします。受け取ったJSONを返すだけの構成です。
- 03Test URLで待ち受ける
この練習ではPublishせず、Listen for test eventを押してTest URLをコピーします。新しい練習用nodeのAuthenticationがNoneの場合のcurl例です。既存workflowの認証は外さず、認証付きの場合は管理者指定の認証情報を付けます。
- curl合成JSONを1件
- WebhookTest URL・POST
- Respond入力を200で返す
Test URLにも後続処理は動きます。「Testだから安全」ではなく、送信・更新nodeを接続しないことが前提です。
PROBE_WEBHOOK_URL='ここへ専用テストworkflowのTest URLを貼る'
curl --silent --show-error --include \
--max-time 20 \
--request POST "$PROBE_WEBHOOK_URL" \
--header 'Content-Type: application/json' \
--data '{"probe_id":"diagnostic-001","message":"synthetic"}'- 01対象nodeからURLをコピーする
TestかProductionかを先に書き、host、prefix、pathを省略せず使います。
- 02nodeと同じHTTPメソッドへ直す
例はPOSTです。GET、PATCH、PUT等を選んだnodeへPOSTを送らないでください。
- 03statusと本文を保存する
--includeでHTTP statusを表示し、秘密値を除いた応答本文も残します。 - 04Executionとprobe_idを照合する
TestではEditorのWebhook出力JSON、本番では同じ時刻のExecutionを開き、
body.probe_idがdiagnostic-001か確認します。
期待する結果は、HTTP 200と、返ったJSONのbody.probe_idがdiagnostic-001、body.messageがsyntheticになることです。headersなど別の項目が付いても構いません。これは期待値の説明で、当研究所の実測結果ではありません。
404なら待受を開始し直す、200でも本文が空ならRespondへの接続とFirst Incoming Itemを確認する、401／403なら認証・IP制限を確認する、の順で戻ります。再送時はprobe_idの末尾を002などに変え、どの1件かを分けます。
--max-time 20はcurl側の20秒の待ち時間です。n8n Cloud側の100秒とは別です。curlが止まってもサーバー側の処理停止を意味しません。Test URLも外部に共有せず、機密データは送らないでください。
専用テストで入口を確認した後に、既存workflowのURL・method・公開済み版と比較します。Productionへの送信は後続処理を把握してから行い、結果はキャンバスではなくExecutionsで確認します。
同じ「届かない」でも、statusとExecutionで入口が変わります。
次の表は原因の確定表ではなく、最初に見る場所を絞る表です。proxyや外部サービスが返したstatusもあるため、応答本文と送信先hostを一緒に確認します。
| 見えた症状 | 残す証拠 | 最初の確認 |
|---|---|---|
| 接続できない | statusを取得できない | host・DNS・TLS・外部到達性。n8nのnode設定より手前 |
| 404 | not registered等の本文 | URL種別、待受、Publish、path。本文がn8n由来かも確認 |
| 405、またはmethodを示す404 | Method Not Allowed／Did you mean POST?等 | Webhook nodeと呼び出し側のGET／POST等が一致するか |
| 401 / 403 | 認証・拒否 | Basic／Header／JWT、IP allowlist、proxyから見える送信元 |
| 2xx・一覧にExecutionなし | 空または短い応答 | 保存設定・絞り込み・権限を先に確認。その後に別URL、Only Run If |
| 2xx・Executionあり | 本文が空・想定外 | Respond、No Response Body、最後に通ったnodeの出力 |
| 524 / timeout | 呼び出し側が待ち切れない | 応答までの処理時間。処理済みか照合してから再送 |
404は、URLの種類と「今その入口が登録中か」を確認します。
Test URLなら、/webhook-test/を使い、Listen for test eventから120秒以内かを確認します。Production URLなら、/webhook/を使い、対象workflowが保存・Publish済みかを確認します。
待受前、120秒経過、Production URLとの取り違え、pathの欠落を確認します。
未Publish、古いURL、別workspace、再Publish前の古いpathを確認します。受信結果はExecutionsで見ます。
まず最小の新規Webhookでも再現するかを分けます。self-hostedなら外部URLとproxyも確認します。
n8nではメソッド不一致が404になり、本文でPOST等を提案する例があります。statusだけでなく本文を読みます。
応答本文やhostがn8nのものかを確認します。proxy、別アプリ、古いdomainの404かもしれません。
Publish済み、URL・methodも一致し、最小workflowでも同じ404なら、nodeを何度も作り直す前に版、時刻、応答本文、Execution 0件、Cloudかself-hostedかを記録します。
405では、HTTPメソッドと「誰が返した応答か」を分けます。
HTTPメソッドは「読むGET」「送るPOST」のように依頼の種類を表す値です。n8nのWebhook nodeはGET、POST、PUT、PATCH、DELETE、HEADを選べます。
curlの--request POST、外部サービスの送信method、Webhook nodeのHTTP Methodを横に並べます。pathが同じでもmethodが違えば、同じ入口ではありません。
ブラウザのアドレスバーでURLを開く操作はGETです。POSTに設定したWebhookの確認にはならないため、curlか送信元のテスト機能で同じmethodを再現します。n8nではmethod不一致を説明する404本文が返る場合もあります。
curl --includeでstatusと本文を保存します。n8n由来の説明か、proxyや別アプリのHTMLかを見ます。
閲覧権限がある場合だけ、最終proxyのaccess logとn8nのExecutions／server logを同じ時刻で照合します。
proxyには記録がありn8n側に何もなければ中間層、Executionがあればn8n内のmethod・flowを先に確認します。
originを外部公開したり、認証を外したりして診断しません。管理者が見られる既存ログで応答元を絞ります。
200なのに空なら、Executionの有無を先に見ます。
2xxはHTTPとして依頼を受け付けた範囲の成功です。workflowの処理内容、保存、外部送信まで正しかったことは示しません。
最初に保存設定、選択project、閲覧権限、日時・statusの絞り込みを確認します。記録が見えないことと、実行されなかったことは別です。その後に別URL・別環境・Only Run Ifを確認します。
No Response Body、Respond Immediately、When Last Node FinishesのResponse Dataを確認します。
分岐の全経路がRespond to Webhookへ到達するかを確認します。最初に実行されたRespondだけが返答します。
最後に実行されたnodeの出力か、Respond nodeの入力かを確認します。期待値と実値を別欄へ残します。
Workflow settingsには本番の成功・失敗、手動実行それぞれの保存設定があります。入力が伏せられる設定ではprobe_idも見えません。管理者の保護設定を解除せず、合成データだけの専用テストで観測できる範囲を確認します。
Executions一覧で対象workflowとprojectを選び、日時・statusの絞り込みを見直します。導入版にOnly Run Ifがある場合、条件falseはExecutionを作らず200を返します。ただし式の評価エラー時は通過する仕様なので、認証の代わりには使いません。
応答モードは、呼び出し側が何を待つかで選びます。
| Respond | 向く場面 | 診断時の注意 |
|---|---|---|
| Immediately | 受付を早く返し、後続処理を待たせたくない | 2xxは後続nodeの成功を保証しない。Executionを別に監視 |
| When Last Node Finishes | 最後のnodeの結果をそのまま返したい | 処理時間と、Response Dataに選んだ出力を確認 |
| Using Respond to Webhook | status・header・本文をworkflow内で明示したい | 全分岐がRespond nodeへ到達するか確認 |
具体的な返却形式はWebhook nodeとRespond to Webhookの公式資料で利用版の項目を照合します。
現行のRespond to Webhook公式資料は、Respondを通らず正常終了すると標準の200、最初のRespondより前にエラーになると500、2つ目のRespondは無視すると説明しています。「Respond未到達なら必ず500」ではありません。導入版の挙動は、実際のstatusと本文で確かめます。
self-hostedで表示URLが内向きなら、reverse proxyの設定を確認します。
n8nはprotocol、host、portを組み合わせてWebhook URLを作ります。reverse proxyの内側が5678、外側が443のように異なると、Editorに外部から届かないURLが表示される場合があります。
現行のn8n公式資料は、外部URLをN8N_WEBHOOK_URLで指定し、proxy段数に対応するN8N_PROXY_HOPSと転送headerを設定するよう案内しています。
N8N_WEBHOOK_URL=https://n8n.example.com/のように、利用者が実際に呼ぶscheme・hostを末尾のスラッシュまで指定します。
N8N_PROXY_HOPS=1はn8n直前のproxyが1段の例です。CDNやload balancerを含む実構成を管理者が数えます。
最終proxyからX-Forwarded-For、X-Forwarded-Host、X-Forwarded-Protoをn8nへ渡します。
導入方法に沿って制御された再起動を行い、nodeに表示されるProduction URL、公開URLの応答、Executionを順に再確認します。
WEBHOOK_URLはn8n 2.35.0から非推奨で、N8N_WEBHOOK_URLへ置き換わりました。古い記事の変数名をそのまま使わず、現在の導入版と起動方法に合う設定名を確認します。
環境変数、proxy、TLS、DNSを同時に変えると原因が分からなくなります。表示URL、外部到達性、n8nの登録、Executionを1段ずつ確認し、設定変更は管理者の承認を取ります。
timeout後は、未実行と決めて同じ処理をすぐ再送しません。
n8n Cloudの公式資料は、Webhookが100秒以内に応答しない場合、Cloudflareの524で失敗すると説明しています。長い処理は、受付をすぐ返し、別の入口で状態を確認する構成が候補です。
timeoutは、n8nや外部サービスが処理を終えたのに応答だけ戻らなかった状態も含みます。購入、登録、送信、更新は、Execution IDや外部側の記録を照合するまで自動再送しません。
3点が不明なら、結果を「失敗」ではなく「不明」として止めます。
問い合わせる前に、秘密を除いた診断メモを1枚にします。
「動きません」だけでは、URL登録、method、proxy、応答のどこを直すか決められません。次のひな型へ、1回のprobeに対応する事実だけを書きます。
確認日時（タイムゾーン）:
n8nの版:
Cloud / self-hosted:
URL種別: Test / Production
URLのhost・prefix・path:
Webhook nodeのHTTP Method:
呼び出し側のHTTP Method:
Test: Listen for test eventを押した時刻:
Production: 保存済み版 / 公開済み版:
実行履歴の保存・閲覧設定 / 一覧の絞り込み:
HTTP status:
応答本文（秘密値を除く）:
Execution ID / 有無:
入力にprobe_idがあるか:
応答モード:
reverse proxyの有無:
次に確認する1点:設定画面の全体スクリーンショットより、URL種別、method、status、本文、Execution IDを文字で残す方が比較しやすくなります。URLに秘密値が含まれる場合は、公開用メモから伏せます。
n8n Webhookの入口診断で、最後に残る疑問
Test URLが一度動いたのに、後から404になります。
Test URLの待受は120秒です。Listen for test eventを押し直し、待受中に同じmethodで送ります。継続利用はProduction URLをPublishして確認します。
Production URLへ送ったのに、Editorにデータが出ません。
Productionの受信データはEditorのキャンバスへ表示されません。対象workflowのExecutionsを開き、送信時刻とprobe_idで確認します。
応答モードはどれを選べばよいですか？
受付だけを早く返すならImmediately、最後のnodeの結果を返すならWhen Last Node Finishes、status・header・本文をflow内で組み立てるならRespond to Webhookが候補です。呼び出し側の待ち時間と必要な本文から選びます。
curlで動けば、外部サービスからも必ず動きますか？
必ずではありません。curlはn8n入口の確認です。次に外部サービス固有の署名、認証、送信IP、method、再送条件を同じ診断メモへ追加します。
送信先・登録・実行記録・応答を、同じ1件で照合する。
404なら待受・Publish・path、405ならHTTPメソッドと応答元、200空ならExecutionと応答モードを確認します。self-hostedでは外部URLとreverse proxyを、timeoutでは処理済みの可能性を別に見ます。
最初の一手は、送信・更新のない専用テストworkflowへ合成データを1件送ることです。Testの受信データと返却JSONでprobe_idを照合し、本番では履歴の保存・閲覧条件も確認します。
確認した一次資料と、今回試していないこと
Test／Production URL、120秒のTest待受、Publish、HTTP method、応答モード、Only Run If、reverse proxy、Cloudの100秒timeoutをn8n公式資料で確認しました。
当研究所では、n8n Cloud／self-hostedの登録、Webhook node作成、curl送信、外部サービスの再送、proxy変更を実行していません。図とcurlは診断手順で、n8n実機の画面や実測結果ではありません。
設定を直す前に、workflowをバックアップする
元の構成を残し、戻せる状態で変更します。JSONに含まれる情報と、復元時の確認点を整理しました。
AIを競合本文の調査、n8n公式資料の照合、構成、下書き、HTML図解、React実装に使用しています。検索順位・検索量は未確認です。n8n実機の接続確認とアフィリエイトリンク設置は行っていません。