error fix
n8n Webhook Not Working: Test vs Production URLs and Reverse Proxy Fixes
Webhook problems usually come from using the wrong test or production URL, not activating the workflow, or exposing a self-hosted instance without the correct public webhook base URL.
Independent third-party notes. n8n is a trademark of its owner and is referenced only for compatibility and troubleshooting context.
Quick Answer
Webhook problems usually come from using the wrong test or production URL, not activating the workflow, or exposing a self-hosted instance without the correct public webhook base URL.
Problem Pattern
The user has a webhook that appears correct inside n8n but fails when called by an external app, usually because the wrong URL mode, activation state, public base URL, or proxy route is being used.
Key Facts
- Two URL modes
- The Webhook node has test and production URLs.
- Test URL
- Useful while the editor is waiting for one manual test call.
- Production URL
- Used by active workflows for real incoming requests.
- Self-hosting variable
- WEBHOOK_URL sets the public base URL for generated webhook URLs.
Recommended Steps
- Check whether the external service is calling the test URL or production URL.
- Activate the workflow before using the production webhook URL.
- For self-hosted instances, set WEBHOOK_URL to the public domain that receives webhook traffic.
- Confirm any reverse proxy forwards the webhook path to n8n.
- Send a small test request and inspect the execution result.
Verification
- The generated webhook URL uses the public domain.
- A request from outside the server reaches the workflow.
- The workflow execution history shows the incoming payload.
Warnings
- A test webhook URL will not behave like a long-running production endpoint.
- If WEBHOOK_URL points to localhost, external services cannot reach the instance.
Best For
- Webhook nodes that work in the editor but fail from an external service.
- Self-hosted deployments where generated webhook URLs show the wrong domain.
- Production workflows that receive no execution even though the external app says it sent a request.
Not For
- General HTTP Request node failures where n8n is the caller rather than the receiver.
- Credential errors inside downstream app nodes.
- Workflows that are intentionally inactive.
Common Mistakes
- Putting a test webhook URL into a production third-party integration.
- Forgetting to activate the workflow before using the production webhook URL.
- Leaving WEBHOOK_URL unset on a reverse-proxied self-hosted instance.
- Testing from the server itself but never testing from outside the network.
Examples
Expected:
https://automation.example.com/webhook/customer-created
Suspicious:
http://localhost:5678/webhook/customer-created
http://n8n:5678/webhook/customer-createdcurl -X POST https://automation.example.com/webhook/customer-created \
-H 'Content-Type: application/json' \
-d '{"test":true,"source":"manual-smoke-test"}'FAQ
Why does the test webhook work but production does not?
The production webhook usually requires the workflow to be active, while the test URL is meant for editor-time testing.
Why does the external app get a timeout?
Common causes are a private localhost URL, reverse proxy routing failure, missing HTTPS, blocked firewall, or a workflow that takes too long before responding.
Should I use Respond to Webhook?
Use it when the caller needs a specific response body, status code, or timing behavior. Otherwise the default response behavior may be enough.