At Hostna, we provide specialized environments for automation, and we often see technical users encounter routing issues when deploying self-hosted instances. When n8n returns a 404 error for a webhook despite the workflow being active, the problem usually lies in the distinction between the test and production environments, a mismatch in the internal database state, or a misconfigured reverse proxy that is stripping necessary headers. Because n8n handles routing dynamically based on active workflows, any interruption in the chain between the external request and the internal Node.js listener results in a standard Not Found response.
| Symptom | Probable Cause | Resolution |
|---|---|---|
| 404 on Production URL | Workflow not saved or activated | Click ‘Execute Workflow’ or toggle ‘Active’ and save |
| 404 on Test URL | Test execution not currently running | Click ‘Listen for Test Event’ in the UI |
| 404 on all URLs | N8N_WEBHOOK_URL env var mismatch | Match N8N_WEBHOOK_URL to your public domain |
| 404 after Migration | Database lock or zombie process | Clear database.sqlite locks or restart container |
The Distinction Between Test and Production Webhooks
The most frequent cause of a 404 error is using the wrong URL for the current state of the workflow. In n8n, a webhook node has two distinct endpoints. The Test URL is only active when you have manually clicked the ‘Listen for Test Event’ button in the editor. This endpoint is designed for one-time use during development and expires immediately after receiving a single request or after a short timeout. The Production URL, conversely, only becomes active when the workflow is toggled to ‘Active’ and saved to the database.
If you attempt to hit the production URL while the workflow is inactive, the application will not have registered that specific path in its internal memory-mapped router. This is a security and resource-saving measure. To verify the registration, you can inspect the internal state. If your instance is under heavy load, a TLS 1.3 one-RTT handshake can help speed up the initial connection, but it will not fix a 404 if the path itself is missing from the application’s registry.
Verifying the Internal Database State
Sometimes the UI indicates that a workflow is active, but the underlying database has not correctly updated the webhook_entity table. This can happen due to database.sqlite file locking issues or if the application process was interrupted during a save operation. You can manually check if n8n has registered your webhook by querying the database directly. Use the following command inside your server terminal or container:
sqlite3 ~/.n8n/database.sqlite "SELECT * FROM webhook_entity;"If you are using PostgreSQL, you would query the same table name. If the path you are calling does not appear in this table, n8n will never respond to the request, regardless of the ‘Active’ toggle in the browser. This often happens if the N8N_ENCRYPTION_KEY was changed, preventing the application from correctly reading the workflow definitions from the workflow_entity table. The infrastructure at Hostna is designed to handle high-IOPS tasks, but a software-level lock on the database will still prevent routing updates.
Reverse Proxy and Header Configuration
When running n8n behind a reverse proxy like Nginx or Traefik, the proxy must pass the exact Host header and path to the n8n container. If your proxy is configured to strip path segments or is rewriting the URL, n8n will receive a request for a path it does not recognize. For example, if your proxy receives a request at /webhook/my-flow but forwards it to the container as /my-flow, the internal router will return a 404.
Ensure your Nginx configuration includes the following directives within the location block:
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;A common mistake is failing to set the WEBHOOK_URL environment variable. If N8N_WEBHOOK_URL is not set to your public domain (e.g., https://n8n.example.com), the application might generate internal links that do not match the external request structure. This is particularly relevant when dedicated automation environment settings are migrated between servers. When configuring these variables, remember that n8n uses HTTP callback mechanisms to trigger workflows, and these rely entirely on precise URL matching.
Memory Constraints and Zombie Processes
An n8n instance restricted by cgroup memory limits may experience silent failures where the main process stays alive, but the worker threads responsible for updating the routing table crash. If the memory pressure on your machine is high, the Linux OOM killer might target sub-processes. This is similar to how a PHP-FPM pool with pm.max_children set too high can exhaust a system; n8n’s Node.js environment requires sufficient overhead to manage its internal event loop.
To isolate whether the issue is at the application layer or the network layer, you can use the n8n CLI to execute a workflow locally. This bypasses the network listener and verifies that the workflow logic itself is sound. Run the following command to test a specific workflow ID:
n8n execute --id=YOUR_WORKFLOW_IDIf the workflow executes successfully via the CLI but still 404s on the webhook, the issue is strictly in the routing layer (the proxy, the environment variables, or the webhook_entity table registration). For more details on the specific variables required for routing, refer to the official n8n environment variable documentation.
DNS Propagation and Host Header Mismatches
If you have recently moved your n8n instance or changed its domain, DNS TTL and propagation can cause intermittent 404 errors. If the request is routed to an old IP address where an n8n instance is still running but doesn’t have the new workflow active, you will receive a 404. Even if the IP is correct, if the Host header sent by the client does not match what the reverse proxy or n8n expects, the request may be dropped or misrouted.
Checking your managing your own Linux server logs is the next logical step. Use docker logs -f n8n_container_name to watch incoming requests in real-time. If you do not see the request hitting the logs when you fire the webhook, the 404 is being generated by your reverse proxy or a firewall, not by n8n itself. If you see the request in the logs with a 404 status code, then n8n is receiving the request but cannot find a matching active workflow. This confirms the issue is within the n8n configuration or database state.
Clustered Environments and Orphaned Workers
In a clustered setup with multiple workers, a “zombie” process might be holding onto an old version of the routing table. If your virtual dedicated server options include multiple CPU cores and you are running n8n in queue mode, ensure that the Redis instance used for communication between the main process and workers is not full. If the workers cannot receive the signal that a new workflow has been activated, they will continue to return 404 for the new production URL.
You should also verify that your machine has a correctly configured rDNS record, as some external webhook providers perform basic validation on the receiving server’s identity before sending payloads. While an rDNS mismatch usually results in a timeout or connection reset rather than a 404, it is a critical part of a shared security model when exposing webhooks to the public internet. If you are still stuck, consulting the technical documentation for your specific deployment method (Docker, npm, or binary) is recommended.
When contacting support about webhook issues, please include the output of the sqlite3 query mentioned above, your N8N_WEBHOOK_URL value, and the last 50 lines of your n8n logs. This information allows us to quickly determine if the routing failure is happening at the edge of our platform or within the application’s internal logic.
This article was drafted with AI assistance from Hostna’s own research pipeline and published without individual review. Tell us if anything here is wrong.