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.

The reason a 404 is so confusing is that the URL looks correct. Nothing about the address tells you whether a workflow is actually bound to it, whether the workflow is active, or whether a proxy quietly rewrote the path in transit. So instead of guessing, work down this list from the most common cause to the least, and use the quick diagnosis steps near the end to confirm exactly where the request is failing. If you are new to n8n webhooks in general, our guide to using webhooks in n8n to trigger workflows covers the fundamentals this post assumes.

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. If you are self-hosting, most reverse-proxy and WEBHOOK_URL problems trace back to the deployment setup, so it is worth getting that right once: see our guide to deploying n8n on Docker in production. And to fail loudly instead of silently when a webhook workflow does break, wire up a proper n8n error workflow.

Fixing the webhook is the easy part. The harder part is selling the automations you build, which is where a live, personalized demo does the convincing for you. See how Ciela turns a prospect's website into a working AI demo you can send before the first call.