n8n “Connection lost”

What you see, what causes it, what fixes it

n8n 2.41.3, installed from npm on Node 24 and run with NODE_ENV=production like the official image, behind nginx 1.31.3 on 30 September 2026. Messages are copied from the editor and the n8n log; the editor strings match n8n’s own i18n keys pushConnection.error.message, pushConnection.error.tooltip and workflowRun.noActiveConnectionToTheServer.

Cause 1 — the proxy drops the WebSocket upgrade

This is the most common setup: an nginx location with a proxy_pass and nothing else. nginx’s docs explain why it fails. “Upgrade” and “Connection” are hop-by-hop headers and “are not passed from a client to proxied server”, so they have to be set explicitly. Without them, the editor’s WebSocket request reaches n8n as an ordinary GET. n8n answers it with 401, which makes it look like a login problem when it is not. Our nginx access log, with the editor retrying on its backoff schedule:

"GET /rest/push?pushRef=bjqwbcf7kp HTTP/1.1" 401 12   12:01:31
"GET /rest/push?pushRef=bjqwbcf7kp HTTP/1.1" 401 12   12:01:32
"GET /rest/push?pushRef=bjqwbcf7kp HTTP/1.1" 401 12   12:01:34
"GET /rest/push?pushRef=bjqwbcf7kp HTTP/1.1" 401 12   12:01:38
"GET /rest/push?pushRef=bjqwbcf7kp HTTP/1.1" 401 12   12:01:46
"GET /rest/push?pushRef=bjqwbcf7kp HTTP/1.1" 401 12   12:02:01

In the editor nothing looks wrong until you run something. There is no banner, because the editor only shows “Connection lost” after a connection that had succeeded drops. On a first attempt that never succeeds, its state stays “connecting”. Clicking Execute workflow then produced:

Problem running workflow
Lost connection to the server

The server log showed no execution: the editor does not start a manual run it cannot follow. n8n’s own docs describe the related symptom, test events stuck on “listening”, as happening “when you run n8n behind a reverse proxy without configuring websocket proxying.” The fix is the three lines at the top of the working config below. Upgrade and Connection are required; proxy_http_version 1.1 only on nginx older than 1.29.7, per the nginx docs.

Cause 2 — “Origin header does NOT match the expected origin”

With the upgrade headers added but Host left alone, the WebSocket now connects — and is closed straight away. In production mode n8n compares the browser’s Origin with the host the request was sent to. In the 2.41.3 source it takes that host from Forwarded, then X-Forwarded-Host, then Host. nginx’s default Host is the upstream name, so the check fails:

warn | Origin header does NOT match the expected origin.
(Origin: "http://localhost:8082" -> "localhost:8082",
 Expected: "n8n" -> "n8n", Protocol: "http")
{"scopes":["push"],"headers":{"host":"n8n","origin":"http://localhost:8082"}}

This time the banner does show, and stays: each reconnect opens, gets closed with “Invalid origin!”, and tries again. Either of these fixed it on our instance, with no warnings in the log afterwards:

proxy_set_header Host $host;                 # or $host:$server_port on a non-standard port
# — or, if Host has to stay as it is —
proxy_set_header X-Forwarded-Host $host:$server_port;

Cause 3 — the banner flashes on and off

Something between browser and server is closing idle connections. The n8n server pings every open editor every 60 seconds, and the editor sends its own heartbeat every 30. We set nginx’s proxy_read_timeout to 20 seconds and recorded the editor’s state:

  0.3 s  connected  — no banner
 28.8 s  disconnected — “Connection lost”
 29.8 s  connected  — no banner
 49.8 s  disconnected — “Connection lost”
 50.8 s  connected  — no banner
 76.8 s  disconnected — “Connection lost”
 77.8 s  connected  — no banner

About one second of banner each time, because the first reconnect comes after one second. With nginx’s default timeout (60 seconds) the same connection stayed up for four minutes without a drop, so the default was not the problem in our test. Look instead for a shorter idle timeout on a load balancer, tunnel or CDN in front of n8n, and raise it well past 60 seconds. Caddy passes WebSockets without extra configuration. Its docs note that “WebSocket connections are forcibly closed … when the config is reloaded”, so each Caddy reload will flash the banner once too.

Cause 4 — n8n really is down

We stopped the n8n process with an editor open and restarted it 15 seconds later. The header switched to “Connection lost” the moment the process died, then to “Offline” (“No network connection. Workflow changes will be saved once the connection is restored.”) about 10 seconds later, once the editor’s other requests were failing too. The server was healthy again at 09:17:20. “Offline” cleared a few seconds after that, and the push channel reconnected at 09:17:35 on the editor’s next retry, at which point the banner disappeared. Expect up to 15 seconds of banner after the server is back, because of the retry schedule. If this is your pattern, the proxy is fine. Look at why the process stopped: a container restart policy, a deploy, or the out-of-memory killer during a large execution.

A working nginx config

location / {
    proxy_pass http://127.0.0.1:5678;
    proxy_http_version 1.1;                    # needed before nginx 1.29.7
    proxy_set_header Upgrade $http_upgrade;    # carry the WebSocket upgrade
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;               # keep the public host for n8n's origin check
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_read_timeout 3600s;                  # idle WebSockets are normal in the editor
}

This is the configuration that ran cleanly on our instance, with the upstream set to n8n’s default port. Add TLS as usual. If you also forward X-Forwarded-For, set N8N_PROXY_HOPS=1. If webhook URLs still show localhost, set N8N_WEBHOOK_URL.

When the proxy cannot carry WebSockets: N8N_PUSH_BACKEND=sse

Some hosting layers will not pass an upgrade however you configure them. n8n can push over server-sent events instead: the docs list N8N_PUSH_BACKEND as choosing “whether the n8n backend uses server-sent events (sse) or WebSockets (websocket) to send changes to the UI”, default websocket. We restarted 2.41.3 with N8N_PUSH_BACKEND=sse behind the same broken proxy from cause 1. The editor connected, and the test workflow ran with both nodes green. n8n’s SSE responses carry X-Accel-Buffering: no, so nginx streams them rather than buffering. Recreate the container after changing the variable, and reload open editor tabs so they pick up the new backend.

Check it in two minutes

• BrowserDevTools → Network → filter push. A healthy WebSocket shows status 101. A 401 on /rest/push is cause 1. A 101 that closes immediately is usually cause 2.
• n8n logSearch for Origin header does NOT match. The “Expected” value tells you which host n8n saw.
• ProxyLook for an idle or read timeout below 60 seconds. With nginx, also check that the location serving n8n has the Upgrade / Connection lines. A server-wide block that is overridden per location does not count.

Sources and last verified

Reproduced on n8n 2.41.3 behind nginx 1.31.3 on 30 September 2026; every doc quote was read the same day. Editor behaviour (when the banner shows, the reconnect schedule, the 30- and 60-second heartbeats) was read from the 2.41.3 build and checked against the running editor. If n8n’s docs and this page disagree, n8n wins. Write to support@flowtemplates.app and we will re-verify.

• n8n Docs — Deployment environment variables (N8N_PUSH_BACKEND) — checked 2026-09-30
• n8n Docs — Telegram Trigger common issues (“run n8n behind a reverse proxy without configuring websocket proxying”) — checked 2026-09-30
• nginx docs — WebSocket proxying — checked 2026-09-30
• Caddy docs — reverse_proxy (WebSocket support and config reloads) — checked 2026-09-30
• n8n source — packages/cli/src/push (push endpoint and origin validation) — checked 2026-09-30
• n8n source — editor strings (pushConnection.error.*, workflowRun.noActiveConnectionToTheServer) — checked 2026-09-30