How to Fix n8n Webhook Returning 404 (Every Cause and Fix)

A 404 from an n8n webhook means n8n did not find a workflow listening at that URL. It is one of the most common errors people hit, and the fix is almost always one of eight specific things. Here is the full list, ordered by how often each one is the culprit.

1. Using the Test URL When the Workflow Is Inactive

This is the number one cause by a wide margin. n8n has two URLs for every webhook: a test URL that only listens when you have clicked "Execute workflow" and are watching the editor, and a production URL that listens whenever the workflow is activated. The test URL expires after receiving one request or when you close the editor.

Fix: activate the workflow via the toggle in the top-right of the editor, then copy the production URL (path starts with /webhook/, not /webhook-test/).

2. The Workflow Is Not Activated

Even with the production URL, n8n returns 404 if the workflow toggle is off. Toggling it on tells n8n to register the webhook path as a listener. An inactive workflow's production URL is not bound, hence 404.

Fix: open the workflow and click the Active switch at the top.

3. Path Changed After the URL Was Shared

If you edit the webhook path in the node settings after already copying the URL, external services still point at the old path. The old URL now returns 404 because no workflow listens there anymore.

Fix: copy the new URL from the webhook node and update every external service pointing at n8n. Alternatively, revert the path to what it was.

4. HTTP Method Mismatch

The webhook is configured to accept POST but you are calling it with GET, or vice versa. n8n returns 404 for method mismatches instead of 405. Check the webhook node's HTTP method field and match your caller's method.

5. Duplicate Webhook Path

Two active workflows cannot share the same webhook path. If you duplicate a workflow and forget to change the path in the new one, n8n either refuses to activate the second workflow or binds the path inconsistently. The fix is to give each webhook a unique path, or better, use the auto-generated UUID path and only customize for routes you truly need to remember.

6. Reverse Proxy Rewriting the Path

If you are self-hosting behind nginx, Cloudflare, or another reverse proxy, the proxy might be stripping or rewriting the /webhook/ path before it reaches n8n. This shows up as a 404 from n8n because the rewritten path does not match any registered webhook.

Fix: check your nginx location blocks or Cloudflare transform rules. The full path including /webhook/uuid must reach n8n intact. Use curl with -v to see what path n8n is actually receiving.

7. N8N_EDITOR_BASE_URL or WEBHOOK_URL Misconfigured

On self-hosted n8n, the WEBHOOK_URL environment variable determines the public URL n8n advertises for webhooks. If this is set wrong (pointing at localhost, or at an old domain), n8n shows the wrong URL in the editor even though the actual listener is fine. Users copy the wrong URL and hit 404 externally.

Fix: set WEBHOOK_URL to your actual public URL, including https://. Restart n8n. Re-copy the webhook URL from the editor.

8. Webhook Is Looking for a Path Parameter

If the webhook node uses a path parameter like /booking/:id, and the caller is hitting /booking/ without an id, n8n returns 404. The fix is to match the parameter in your caller, or remove the parameter requirement from the webhook config.

Quick Diagnosis Steps

Step 1: open the workflow. Is it activated? Step 2: copy the URL from the webhook node. Does it start with /webhook/ (not /webhook-test/)? Step 3: curl the URL with the correct HTTP method. Does it return 404 or succeed? Step 4: if curl succeeds but your external caller gets 404, the issue is between your caller and n8n (DNS, proxy, firewall). Step 5: if curl also 404s, the issue is in n8n config.

Preventing 404s in Production

Once the webhook is fixed, harden against future 404s. Use the production URL everywhere from the start; never share test URLs outside the editor. Pin critical webhook paths to named slugs rather than UUIDs so you do not accidentally break them when cloning workflows. Monitor webhook success rates; a sudden spike of 404s usually means someone updated a workflow without activating it.

Add a health check workflow at a known path like /webhook/health that always returns 200. Hit it from an external monitor every 5 minutes. If it 404s, you know n8n is down or misconfigured before users notice.