error fix

n8n Webhook 404: Fix Wrong URLs, Inactive Workflows, and Proxy Routes

A 404 on an n8n webhook usually means the request is hitting the wrong URL, the wrong test or production mode, an inactive or unpublished workflow, or a reverse proxy path that does not reach the configured Webhook endpoint.

Match your incident first

Start with the symptom you can prove

Jump to checks

Test URL works, production URL returns 404

First check: Open the Webhook node and compare the active production URL with the external app callback URL.

Wrong fix to avoid: Do not rebuild the whole workflow before proving whether the active production endpoint exists.

Verify: Activate or publish the workflow, send the configured HTTP method to the production URL, and confirm one new production execution appears.

Production URL shows localhost, container hostname, or http instead of public HTTPS

First check: Check the public URL shown in n8n and compare it with WEBHOOK_URL, N8N_PROXY_HOPS, and reverse proxy forwarded headers.

Wrong fix to avoid: Do not paste the internal Docker service name into external SaaS callback settings.

Verify: The Webhook node displays the public HTTPS domain and an external curl reaches n8n without redirect loops.

Browser test returns 404 but the provider says it sends POST

First check: Compare the Webhook node HTTP Method with the method sent by the provider and by your curl test.

Wrong fix to avoid: Do not change the path before proving the HTTP method is the same in n8n and the caller.

Verify: A curl request using the configured method reaches the workflow, while the wrong method fails predictably.

Use when: self-hosted, n8n Cloud, webhooks
First check: Confirm the workflow is active or published and the caller is using the production webhook URL.
Time to check: 5-10 minutes
Next step: Match the symptom, then run the verification checks.

Independent third-party notes. n8n is a trademark of its owner and is referenced only for compatibility and troubleshooting context.

Quick Answer

Does this match your symptom?

Webhook is not reaching production

A test webhook works in the editor, but the production URL returns 404, uses the wrong method, or never creates an execution.

First check: Confirm the workflow is active or published and the caller is using the production webhook URL.

Primary path n8n Test Webhook vs Production URL: Which One Should You Use? Related check n8n Webhook Not Working: Test vs Production URLs and Reverse Proxy Fixes Related check N8N Respond to Webhook Node Cookbook Still blocked? Generate a diagnostic brief

Problem Pattern

The request reaches a URL that does not map to an active Webhook node route, or the reverse proxy never forwards the request to n8n.

Incident gate

Decide whether this is workflow, URL, or infrastructure

Prepare webhook brief

Before changing the workflow, classify the 404 with evidence. This keeps you from rotating credentials or rebuilding containers when the caller is simply using the wrong route.

Gate	Pass condition	Stop if	Proof to keep
Mode	The caller uses the production URL for real traffic; test URLs are only used while the editor is listening.	A provider dashboard stores a test URL, or a production URL is tested before the workflow is active/published.	Screenshot or copied text of the Webhook node production URL and workflow active state.
Method and path	The provider method and path exactly match the Webhook node method and path.	You tested a POST webhook by opening it in the browser, or the provider still has an old path.	A curl command using the same method and sanitized payload.
Route ownership	No other active workflow owns the same method plus path combination.	Two published workflows compete for the same webhook route.	A short note listing the active workflow and Webhook node path.
Public domain	The generated URL uses the same HTTPS domain that the external service can reach.	n8n displays localhost, http, a container name, or an internal reverse proxy hostname.	WEBHOOK_URL/N8N_HOST/N8N_PROTOCOL values with secrets redacted.
Proxy path	Reverse proxy access logs and n8n executions show the same request timestamp.	The proxy returns 404 before the request reaches n8n.	One proxy access log line plus the matching n8n execution or absence of execution.

If the first failing gate is public domain or proxy path, move to the reverse proxy and WEBHOOK_URL pages before editing workflow logic.

Version awareness

Last reviewed 2026-05-25

Applies to: n8n Cloud when using webhooks, self-hosted n8n, Docker, reverse proxy, custom domains
Official docs checked: n8n Webhook Node, n8n Endpoint Environment Variables, n8n Webhook workflow development, n8n Webhooks behind reverse proxy, n8n Save and publish workflows, n8n Webhook common issues
Version-sensitive assumptions: n8n node parameters, credential names, and queue mode defaults can change between releases; confirm against your installed version before changing production.
What may change after upgrades: Node parameter names, credential scopes, webhook behavior, Docker image defaults, and queue worker expectations may shift after n8n upgrades.

Key Facts

Most common cause: The caller is using a URL that does not match an active Webhook node route.
Mode mismatch: Test URLs and production URLs are different operating modes.
Activation dependency: Production webhook URLs require the workflow to be active or published, depending on your n8n version and UI.
Self-hosted dependency: Reverse proxy, WEBHOOK_URL, proxy hop, and forwarded header settings affect generated webhook URLs.
Path plus method: n8n registers one webhook for a path and HTTP method combination, so a saved callback must match both.

Production Diagnostic Matrix

Turn checks into a brief

Exact symptom or log	Likely cause	First check	Wrong fix to avoid	Verification
Test URL works, production URL returns 404	Workflow is inactive/unpublished, the external app stores a stale production URL, the method/path does not match, or the Webhook node path changed after the callback was saved.	Open the Webhook node and compare the active production URL with the external app callback URL.	Do not rebuild the whole workflow before proving whether the active production endpoint exists.	Activate or publish the workflow, send the configured HTTP method to the production URL, and confirm one new production execution appears.
Production URL shows localhost, container hostname, or http instead of public HTTPS	WEBHOOK_URL, N8N_HOST, N8N_PROTOCOL, N8N_PROXY_HOPS, or forwarded proxy headers do not match the public domain.	Check the public URL shown in n8n and compare it with WEBHOOK_URL, N8N_PROXY_HOPS, and reverse proxy forwarded headers.	Do not paste the internal Docker service name into external SaaS callback settings.	The Webhook node displays the public HTTPS domain and an external curl reaches n8n without redirect loops.
Browser test returns 404 but the provider says it sends POST	The route exists for POST, but the browser check used GET, or another workflow owns the path with a different method.	Compare the Webhook node HTTP Method with the method sent by the provider and by your curl test.	Do not change the path before proving the HTTP method is the same in n8n and the caller.	A curl request using the configured method reaches the workflow, while the wrong method fails predictably.
External app times out but n8n logs show no execution	DNS, firewall, Cloudflare, reverse proxy, or path routing blocks the request before it reaches n8n.	Run an external curl smoke test and inspect reverse proxy access logs for the same timestamp.	Do not rotate credentials when the request never reaches n8n.	Proxy access log and n8n execution log both show the same request.
Workflow receives payload but caller gets wrong response or hangs	Respond to Webhook is missing, configured for the wrong response mode, or waits for a branch that does not finish.	Check the Webhook node response mode and the Respond to Webhook node path.	Do not add arbitrary Wait nodes to hide timeout behavior.	Caller receives the intended status code and body within the provider timeout window.
Webhook path works internally but fails through reverse proxy	Proxy location, configured webhook endpoint, base path, body size, TLS termination, or forwarded proto/host headers are wrong.	Compare direct container access with the public reverse proxy route and check forwarded headers.	Do not disable HTTPS verification as a proxy troubleshooting shortcut.	Public HTTPS request preserves method, path, body, and host all the way to n8n.

Still blocked after these checks?

Use the brief to decide whether to keep fixing this setup, move the workload to n8n Cloud, or rebuild the self-hosted path on cleaner infrastructure.

Compare tools

Recommended Steps

Confirm whether the external app is calling the test URL or the production URL; test webhooks are temporary listening endpoints, not production callbacks.
If using the production URL, confirm the workflow is active or published in your n8n version.
Check the Webhook node path and HTTP method.
Confirm no other published workflow already owns the same path and HTTP method combination.
For self-hosted n8n, confirm the public URL generated by n8n matches the real domain, proxy route, and configured webhook endpoint.
Send a small curl request with the configured method to the exact URL and inspect the workflow executions list.

Verification

The exact external URL appears in the Webhook node as the intended URL.
A request from outside the server creates an execution.
The response is no longer 404 for the configured method and path.

First Commands / Checks

Webhook smoke test Use when an external app reports timeout, 404, or wrong response.

curl -i -X POST https://automation.example.com/webhook/example-path \
  -H "content-type: application/json" \
  -d '{"smokeTest":true}'

Secrets note: Use the Webhook node's configured method; POST is only an example. Use a disposable path or non-sensitive payload. Do not paste provider signing secrets into curl examples.
Verification: The response status and body match the Webhook or Respond to Webhook configuration, and one new execution appears when the workflow is active/published.

Check container state Use first when n8n is down, restarting, or behaving differently after a deploy.

docker compose ps

Secrets note: This lists service names and status only; it should not print credential values.
Verification: n8n, database, Redis, and worker services are running or the failing service is obvious.

Read recent n8n logs Use when the editor, webhook, or startup path fails.

docker compose logs n8n --tail=100

Secrets note: Review before sharing; remove tokens, private hostnames, and customer payloads.
Verification: The log contains a timestamped error, migration message, or clean startup line.

Check public URL variables only Use when webhook URLs show localhost, http, or the wrong domain.

docker compose exec n8n printenv WEBHOOK_URL N8N_HOST N8N_PROTOCOL N8N_EDITOR_BASE_URL N8N_PROXY_HOPS

Secrets note: Do not run a full env dump in public channels; print only these non-secret routing names.
Verification: Values point to the intended HTTPS public domain.

Safe Copyable Config

Reverse proxy webhook URL baseline Use as an .env shape check when n8n is behind a reverse proxy and generated production webhook URLs show localhost, http, or the wrong host.

WEBHOOK_URL=https://automation.example.com/
N8N_PROXY_HOPS=1
N8N_HOST=automation.example.com
N8N_PROTOCOL=https

What to change: Replace automation.example.com with the public HTTPS hostname that external services call. Set N8N_PROXY_HOPS to the number of reverse proxies in front of n8n; 1 is only correct for a single proxy hop. Keep your proxy forwarding X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto to n8n.
Secrets to keep private: Do not paste the full environment file, credential values, provider signing secrets, database URLs, or private hostnames into support tickets.
Verification: The Webhook node displays the public HTTPS domain. An external curl request to the production URL creates one execution. The proxy access log and n8n execution timestamp line up for the same request.
Common mistakes: Leaving WEBHOOK_URL on localhost or an internal Docker service name. Setting N8N_PROXY_HOPS without forwarding the matching X-Forwarded headers. Forgetting to restart or redeploy n8n after environment changes.

Warnings

Do not fix a webhook 404 by switching to a test URL in a production integration.
If a reverse proxy strips or rewrites paths, the request may never reach the Webhook node route.
Do not validate a POST-only webhook by opening it in a browser; that usually sends a GET request and can make a method mismatch look like a missing route.

Common Mistakes

Copying the test URL into a third-party production setting.
Forgetting to activate the workflow.
Testing a POST webhook with a browser GET request and treating the 404 as proof the route is gone.
Changing the Webhook node path after the external service already stored the old URL.
Publishing two webhook workflows that need the same path and HTTP method.
Leaving WEBHOOK_URL pointed at localhost on a self-hosted instance.

Examples

404 triage checklist Walk this in order before changing workflow logic.

URL copied from production tab: yes
Workflow active/published: yes
HTTP method matches node: yes
Webhook path unchanged: yes
No other workflow owns the same path + method: yes
External app callback updated after path/domain changes: yes
Public domain reaches n8n: yes
Reverse proxy forwards configured webhook endpoint, default /webhook/*: yes

FAQ

Why does the browser show 404 but the editor test works?

The editor test may be using the test URL while the browser or external app is using the production URL. Confirm mode, activation, method, and path.

Can a reverse proxy cause webhook 404s?

Yes. If the proxy does not forward the webhook path to n8n, the request can return 404 before it reaches the workflow.

Sources

n8n Webhook Node Accessed 2026-05-08 n8n Endpoint Environment Variables Accessed 2026-05-24 n8n Webhook workflow development Accessed 2026-05-24 n8n Webhooks behind reverse proxy Accessed 2026-05-24 n8n Save and publish workflows Accessed 2026-05-24 n8n Webhook common issues Accessed 2026-05-25