Connection lost in n8n: Ursache bei Reverse Proxy und WebSocket

Wenn die n8n-Oberfläche "Connection lost" meldet, ist meistens nicht der Workflow selbst betroffen, sondern die WebSocket-Verbindung zwischen Browser und Backend, die etwa durch einen Reverse Proxy unterbrochen wird. Ein aktiver Workflow läuft dabei in aller Regel weiter, auch wenn die Oberfläche das im ersten Moment nicht mehr anzeigt. Stand: August 2026.

Woran liegt es meistens?

Ein Blick in die n8n-Community zeigt ein wiederkehrendes Muster: Die weit überwiegende Zahl der "Connection lost"-Meldungen betrifft selbst gehostete Instanzen hinter einem Reverse Proxy, etwa bei Deployments auf DigitalOcean, hinter einem Cloudflare Tunnel mit Docker, hinter Nginx mit nicht standardmäßigem SSL-Port, hinter Apache oder in Kubernetes-Umgebungen mit Envoy-Proxy. In mehreren dieser Threads wird die Meldung ausdrücklich mit fehlerhaft weitergeleiteten WebSocket-Verbindungen in Zusammenhang gebracht, in einem Fall konkret als "Invalid Origin"-Fehler ab n8n Version 1.87 hinter einem Cloudflare Tunnel. n8n selbst läuft dabei meist weiter, nur die Live-Anzeige in der Oberfläche bricht ab.

Wie ist n8n hinter einem Reverse Proxy korrekt konfiguriert?

Nach n8n-Dokumentation muss der letzte Proxy in der Kette die Header X-Forwarded-For, X-Forwarded-Host und X-Forwarded-Proto korrekt weiterreichen, damit n8n die ursprüngliche Anfrage richtig interpretiert. Zusätzlich sollte die Variable N8N_PROXY_HOPS auf 1 gesetzt werden, wenn genau ein Proxy vor n8n steht. Fehlen diese Header oder stimmt die Anzahl der Proxy-Hops nicht, kann das zu genau den Verbindungsabbrüchen führen, die in der Community am häufigsten beschrieben werden.

Welche Rolle spielt N8N_WEBHOOK_URL?

Die Webhook-URL muss laut Dokumentation manuell über die Umgebungsvariable N8N_WEBHOOK_URL gesetzt werden, damit n8n sie korrekt in der Editor-Oberfläche anzeigt und bei externen Diensten registriert. Die ältere Variante WEBHOOK_URL wird zwar weiterhin erkannt, löst aber eine Deprecation-Warnung aus. Diese Variable betrifft in erster Linie eingehende Webhooks, sie ist aber Teil derselben Grundkonfiguration wie die Proxy-Header und wird deshalb in denselben Community-Threads häufig gemeinsam mit den Verbindungsproblemen genannt.

Wann hilft der Wechsel auf Server-Sent Events?

Standardmäßig nutzt n8n für die Live-Kommunikation zwischen Backend und Oberfläche laut n8n-Dokumentation WebSockets, gesteuert über die Variable N8N_PUSH_BACKEND mit dem Standardwert websocket. Alternativ lässt sich der Wert auf sse setzen, dann kommen Server-Sent Events statt WebSockets zum Einsatz. Das kann helfen, wenn eine Netzwerkumgebung, ein Proxy oder eine Firewall WebSocket-Verbindungen grundsätzlich erschwert oder blockiert, während einfache HTTP-Verbindungen problemlos durchgehen. Ein Test mit sse ist eine der Maßnahmen, die sich ohne größere Infrastrukturänderung schnell ausprobieren lässt, bevor man tiefer in die Proxy-Konfiguration einsteigt.

Wie geht man systematisch vor?

Sinnvoll ist es, zuerst zu prüfen, ob der Fehler nur in der Oberfläche auftritt, während der Workflow im Hintergrund erfolgreich durchläuft, das lässt sich über die Ausführungsliste nachvollziehen. Danach folgt die Kontrolle der drei Forwarded-Header sowie von N8N_PROXY_HOPS, anschließend die Prüfung von N8N_WEBHOOK_URL, und erst danach der Versuch mit N8N_PUSH_BACKEND=sse. Wer n8n im Rahmen einer n8n-Einführung betreibt, sollte diese vier Punkte direkt beim Aufsetzen des Reverse Proxys dokumentieren, das erspart spätere Fehlersuche unter Zeitdruck.

Häufige Fragen zu Connection lost in n8n

Bricht der Workflow ab, wenn die Oberfläche "Connection lost" zeigt?

In der Regel nicht. Die Meldung betrifft meist nur die Live-Verbindung zwischen Browser und n8n-Backend, ein bereits gestarteter Workflow läuft im Hintergrund weiter und lässt sich über die Ausführungsliste nachvollziehen.

Welche Header muss mein Reverse Proxy weiterreichen?

Nach n8n-Dokumentation sind das mindestens X-Forwarded-For, X-Forwarded-Host und X-Forwarded-Proto. Zusätzlich sollte N8N_PROXY_HOPS auf die tatsächliche Anzahl vorgeschalteter Proxys gesetzt sein, meist 1.

Was bewirkt N8N_PUSH_BACKEND?

Diese Variable legt fest, ob n8n WebSockets oder Server-Sent Events für die Live-Aktualisierung der Oberfläche nutzt. Der Standardwert ist websocket, bei hartnäckigen Verbindungsproblemen hinter restriktiven Proxys oder Firewalls kann sse eine funktionierende Alternative sein.

Ist WEBHOOK_URL noch gültig oder muss ich umstellen?

WEBHOOK_URL wird laut Dokumentation weiterhin erkannt, löst aber eine Deprecation-Warnung aus. Die aktuelle Schreibweise lautet N8N_WEBHOOK_URL, ein Umstellen ist empfehlenswert, um zukünftige Kompatibilitätsprobleme zu vermeiden.