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 Type | Most Likely Cause |
|---|---|
| Behind nginx/Apache reverse proxy | Missing WebSocket headers |
| Behind Cloudflare | Proxy timeout settings |
| Docker with default config | Wrong N8N_PUSH_BACKEND setting |
| Corporate network | Firewall killing idle connections |
| Recent n8n upgrade | Version-specific bug |
| Cloud-hosted n8n | Memory 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:
- Bypass Cloudflare for n8n: Set the DNS record to "DNS only" (gray cloud) instead of "Proxied" (orange cloud)
- Use Cloudflare Tunnel: Configure a tunnel with increased timeout settings
- 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:
- Check the n8n GitHub issues for your specific version
- Consider downgrading temporarily while a fix is released
- 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:
- Restart n8n completely (docker-compose down && docker-compose up -d)
- Clear browser cache or use incognito mode
- Open browser dev tools > Network > WS filter
- Watch for stable WebSocket connection
- 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.