Connection lost in n8n: cause in reverse proxy and WebSocket

When the n8n interface reports "Connection lost", it is usually not the workflow itself that is affected, but the WebSocket connection between browser and backend, which is interrupted for example by a reverse proxy. An active workflow generally keeps running, even if the interface no longer shows this at first. As of: August 2026.

What usually causes it?

A look at the n8n community shows a recurring pattern: the vast majority of "Connection lost" reports affect self-hosted instances behind a reverse proxy, for example deployments on DigitalOcean, behind a Cloudflare Tunnel with Docker, behind Nginx with a non-standard SSL port, behind Apache, or in Kubernetes environments with an Envoy proxy. In several of these threads, the message is explicitly linked to incorrectly forwarded WebSocket connections, in one case specifically as an "Invalid Origin" error from n8n version 1.87 onward behind a Cloudflare Tunnel. n8n itself usually keeps running, only the live display in the interface breaks off.

How is n8n correctly configured behind a reverse proxy?

According to n8n documentation the last proxy in the chain must correctly forward the headers X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto so that n8n interprets the original request correctly. In addition, the variable N8N_PROXY_HOPS should be set to 1 if exactly one proxy sits in front of n8n. If these headers are missing or the number of proxy hops is wrong, this can lead to exactly the connection drops most commonly described in the community.

What role does N8N_WEBHOOK_URL play?

According to the documentation, the webhook URL must be set manually via the environment variable N8N_WEBHOOK_URL so that n8n displays it correctly in the editor interface and registers it with external services. The older variant WEBHOOK_URL is still recognized, but triggers a deprecation warning. This variable primarily affects incoming webhooks, but it is part of the same basic configuration as the proxy headers, which is why it is often mentioned together with the connection problems in the same community threads.

When does switching to Server-Sent Events help?

By default, according to n8n documentation n8n uses WebSockets for live communication between backend and interface, controlled via the variable N8N_PUSH_BACKEND with the default value websocket. Alternatively, the value can be set to sse, in which case Server-Sent Events are used instead of WebSockets. This can help if a network environment, a proxy, or a firewall generally hinders or blocks WebSocket connections, while simple HTTP connections pass through without issues. A test with sse is one of the measures that can be tried quickly without major infrastructure changes, before going deeper into the proxy configuration.

How do you proceed systematically?

It makes sense to first check whether the error only occurs in the interface while the workflow completes successfully in the background, which can be verified via the execution list. Next comes checking the three Forwarded headers as well as N8N_PROXY_HOPS, then checking N8N_WEBHOOK_URL, and only after that trying N8N_PUSH_BACKEND=sse. Anyone running n8n as part of an n8n introduction should document these four points directly when setting up the reverse proxy, which saves later troubleshooting under time pressure.

Frequently asked questions about Connection lost in n8n

Does the workflow abort when the interface shows "Connection lost"?

Usually not. The message usually only affects the live connection between browser and n8n backend; a workflow that has already started keeps running in the background and can be verified via the execution list.

Which headers does my reverse proxy need to forward?

According to n8n documentation, that is at least X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto. In addition, N8N_PROXY_HOPS should be set to the actual number of proxies in front, usually 1.

What does N8N_PUSH_BACKEND do?

This variable determines whether n8n uses WebSockets or Server-Sent Events for the live update of the interface. The default value is websocket; for persistent connection issues behind restrictive proxies or firewalls, sse can be a working alternative.

Is WEBHOOK_URL still valid, or do I need to switch?

WEBHOOK_URL is still recognized according to the documentation, but triggers a deprecation warning. The current form is N8N_WEBHOOK_URL; switching is recommended to avoid future compatibility issues.