Artur
Artur
Founder

n8n Connection Lost Error: Causes and Fixes

April 26, 2026

n8n-connection-lostn8n-websocket-errorn8n-troubleshootingself-hosted-n8n

The "Connection Lost" error in n8n usually means your browser lost its WebSocket connection to the n8n backend. This happens for six distinct reasons - and forum threads mix them all together, making diagnosis frustrating.

Here's how to identify which cause applies to you and fix it.

Quick Diagnosis

Before diving into fixes, identify your setup:

Setup TypeMost Likely Cause
Behind nginx/Apache reverse proxyMissing WebSocket headers
Behind CloudflareProxy timeout settings
Docker with default configWrong N8N_PUSH_BACKEND setting
Corporate networkFirewall killing idle connections
Recent n8n upgradeVersion-specific bug
Cloud-hosted n8nMemory constraints

As the n8n community notes: "'Connection Lost' messages usually indicate a temporary issue with your network connection, server performance, or the n8n backend timing out."

Cause 1: Missing WebSocket Headers in Reverse Proxy

The most common cause. Your reverse proxy isn't forwarding WebSocket upgrade requests properly.

For nginx, add these headers to your n8n location block:

location / {
    proxy_pass http://localhost:5678;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    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;
    proxy_read_timeout 86400;
}

The critical lines are proxy_set_header Upgrade and proxy_set_header Connection "upgrade". Without these, WebSocket connections fail silently.

For Apache, the n8n community solution requires enabling mod_proxy_wstunnel and configuring WebSocket proxying.

Verification: Open browser dev tools, go to the Network tab, filter by WS (WebSocket). You should see an active WebSocket connection to your n8n instance. If it shows failed or keeps reconnecting, your proxy config is wrong.

Cause 2: Wrong N8N_PUSH_BACKEND Setting

n8n supports two push backends: Server-Sent Events (SSE) and WebSocket. Some reverse proxy configurations work better with one over the other.

In your docker-compose.yml or environment variables:

environment:
  - N8N_PUSH_BACKEND=websocket

If you're getting connection issues with websocket, try switching to SSE:

environment:
  - N8N_PUSH_BACKEND=sse

The community found that replacing SSE with WebSocket (or vice versa) resolved their issues depending on their reverse proxy setup.

Cause 3: N8N_PROXY_HOPS Misconfiguration

If n8n sits behind multiple proxies (load balancer + nginx, for example), n8n needs to know how many proxy layers exist to correctly read client IP addresses and handle connections.

Set this environment variable to match your proxy depth:

environment:
  - N8N_PROXY_HOPS=1  # Adjust based on your setup

One proxy = 1. Two proxies (like Cloudflare + nginx) = 2.

Getting this wrong causes n8n to misinterpret connection headers, leading to dropped connections.

Cause 4: Firewall and Network Timeouts

Corporate firewalls and network appliances often kill idle WebSocket connections. According to GitHub issue #13542: "If you are trying to use n8n inside a corporate network and that is trying to do content inspection and maybe blocking web sockets."

Fixes:

Increase nginx keepalive timeout:

proxy_read_timeout 86400;
proxy_send_timeout 86400;
keepalive_timeout 86400;

If your firewall has configurable timeouts, set WebSocket/HTTP connection timeouts to at least 3600 seconds.

For corporate environments where you can't change firewall rules, the SSE backend sometimes works better since it uses standard HTTP connections.

Cause 5: Cloudflare Proxy Timeout

Cloudflare's default proxy timeout is 100 seconds for WebSocket connections on free plans. Long-running workflows or idle editor sessions will get disconnected.

Options:

  1. Bypass Cloudflare for n8n: Set the DNS record to "DNS only" (gray cloud) instead of "Proxied" (orange cloud)
  2. Use Cloudflare Tunnel: Configure a tunnel with increased timeout settings
  3. Upgrade Cloudflare plan: Enterprise plans allow longer timeouts

If bypassing Cloudflare, ensure you have other security measures in place since traffic will hit your server directly.

Cause 6: Version-Specific Bugs

Some n8n versions have introduced connection stability issues. Users in community forums reported problems with version 1.79.3 that resolved after downgrading to 1.78.1.

If your connection issues started immediately after an upgrade:

  1. Check the n8n GitHub issues for your specific version
  2. Consider downgrading temporarily while a fix is released
  3. Test with the latest version - fixes often ship quickly

Environment Variables Checklist

Ensure these are set correctly for your domain:

environment:
  - N8N_HOST=n8n.yourdomain.com
  - N8N_PORT=5678
  - N8N_PROTOCOL=https
  - N8N_EDITOR_BASE_URL=https://n8n.yourdomain.com
  - WEBHOOK_URL=https://n8n.yourdomain.com
  - N8N_PUSH_BACKEND=websocket
  - N8N_PROXY_HOPS=1

Mismatched values between N8N_HOST, N8N_EDITOR_BASE_URL, and your actual domain cause connection issues that are hard to diagnose.

Verification Steps

After making changes:

  1. Restart n8n completely (docker-compose down && docker-compose up -d)
  2. Clear browser cache or use incognito mode
  3. Open browser dev tools > Network > WS filter
  4. Watch for stable WebSocket connection
  5. Leave the editor open for 5+ minutes to test timeout issues

If the WebSocket shows "101 Switching Protocols" and stays connected, you're good.

FAQ

Why does the connection lost error appear randomly?

Usually firewall or proxy timeouts killing idle connections. The connection works initially but drops after a period of inactivity. Increase your proxy_read_timeout values.

Can I use n8n without WebSocket?

Yes. Set N8N_PUSH_BACKEND=sse to use Server-Sent Events instead. This uses standard HTTP connections which pass through more firewalls and proxies without configuration.

Will this affect my running workflows?

No. The "Connection Lost" error only affects the editor UI connection. Your workflows continue executing on the server regardless of whether your browser is connected.

How do I know if it's a memory issue?

If you're on n8n Cloud or a small VPS, check your memory usage during workflow execution. The GitHub community notes that running out of memory causes crashes that show as connection lost errors.

Should I upgrade n8n to fix this?

Check the release notes first. Some versions introduced connection issues, others fixed them. Don't assume newer is better for stability.


Dealing with persistent n8n connection issues or need help optimizing your self-hosted setup? n8n Logic provides automation services and n8n infrastructure support to keep your workflows running reliably.


n8n Connection Lost Error: Causes and Fixes | n8nlogic