Proxy-Timeout: Verhindern Sie, dass WebSockets nach einer Minute abgebrochen werden

Ihre WebSocket-Anwendung wird lokal ausgeführt. Beim Staging hinter Nginx scheint alles in Ordnung zu sein – auf die Minute genau: Die Verbindung wird geschlossen, der Client versucht, die Verbindung wiederherzustellen, der Benutzer sieht einen „getrennten“ Blitz. Die Anwendungsprotokolle zeigen keine Ausnahmen. Nur der Proxy hat entschieden, dass die Sitzung inaktiv war.

Dieses Muster – genau 60 Sekunden – ist eine der schnellsten Diagnosen im Webhosting. Bestimmen Sie vor der Optimierung des onMessage-Handlers den Zeitpunkt des Ausfalls: Die Anzahl der Sekunden gibt häufig Aufschluss über den Übeltäter.

WebSocket hinter einem Reverse-Proxy

Der Browser sendet eine HTTP-Anfrage mit „Upgrade: websocket“. Der Proxy muss die Header „Upgrade“ und „Connection“ übertragen, kein klassisches HTTP-Timeout auf eine langlebige Verbindung anwenden und bidirektionale Frames ohne Pufferung auf unbestimmte Zeit passieren lassen.

WebSocket ist keine „lange“ HTTP-Anfrage – es ist nach dem Upgrade ein separates Protokoll. Der Proxy sollte es als solches behandeln.

Typische Nginx-Konfiguration

„Nginx Karte $http_upgrade $connection_upgrade { Standard-Upgrade; '' schließen; }

Standort /ws/ { Proxy_Pass http://backend; Proxy_http_version 1.1; Proxy_set_header Upgrade $http_upgrade; Proxy_set_header Verbindung $connection_upgrade; Proxy_read_timeout 3600s; Proxy_send_timeout 3600s; }

Passen Sie „3600s“ an Ihren Fall an – abgestimmt auf den Herzschlag der Anwendung, nicht auf Unendlichkeit. Überprüfen Sie außerdem, ob das Backend lange Verbindungen akzeptiert und dass die Zwischen-Firewall kein eigenes Leerlauflimit vorgibt.



:::Hinweis

**Zur Erinnerung.** Proxy-Timeout plus kein Ping = vorhersehbare Verbindungsunterbrechung. Stellen Sie beides ein: großzügiger Proxy und Heartbeat häufiger als das kürzeste Timeout in der Kette.

:::



## Anwendungs-Heartbeat: in der Produktion obligatorisch



Senden Sie selbst bei hohen Zeitüberschreitungen alle 30 bis 45 Sekunden einen WebSocket-Ping – oder eine leichte JSON-Nachricht –, wenn ein Glied in der Kette nach 60 oder 100 Sekunden unterbrochen wird. Auf der Seite der Node- (WS), Python- (Websockets) oder Phoenix-Kanäle: Aktivieren Sie natives Ping/Pong oder implementieren Sie es explizit.



Testen Sie **absichtlich** auf eine Minute Benutzerinaktivität – nicht nur auf kontinuierlichen Datenverkehr. Eine Sitzung, die während eines Videoanrufs ohne Anwendungsnachricht geöffnet bleibt, offenbart schnell die Grenzen des Proxys oder CDN.



## CDN und verwaltetes Hosting



Wenn der WebSocket über Cloudflare oder eine WAF läuft, aktivieren Sie WebSockets im Dashboard, überprüfen Sie die Dauer oder Nachrichtenlimits pro Plan und pingen Sie weiterhin häufiger als die Timeout-Grenze. Bei direktem Ursprung ohne CDN reduziert sich das Problem oft auf Nginx oder HAProxy.



Lesen Sie bei PaaS (Clever Cloud, Railway, Heroku) die Dokumentation zu langen Verbindungen – einige Router legen feste Obergrenzen fest. Vergleichen Sie passende Angebote über unser [Verzeichnis](/de/verzeichnis/), wenn Echtzeitverbindungen für Ihr Produkt von zentraler Bedeutung sind.



## Oben: Der Fehler liegt nicht in Ihrem onMessage-Handler



:::Höhepunkt

**Wenn der Ausfall in einem festen Intervall (60s, 100s, 3500s) auftritt, vermuten Sie die Transportschicht vor dem Geschäftscode.** Wochen können durch die „Optimierung“ des WebSocket-Servers verloren gehen, wenn eine Proxy_read_timeout-Zeile ausreicht – oder ein fehlender Ping auf der Clientseite.

:::



## Entscheide dich und gehe ohne blinden Fleck voran



Ermitteln Sie zunächst das genaue Trennungsintervall und korrelieren Sie es mit den dokumentierten Zeitüberschreitungen jedes Links (Nginx, Load Balancer, CDN, PaaS). Korrigieren Sie dann die Upgrade-Header und Proxy-Timeouts und fügen Sie dann ein häufigeres Ping/Pong als das kürzeste Timeout hinzu. Testen Sie die Produktion mit einer Minute freiwilliger Inaktivität – localhost verbirgt oft die mittlere Schicht. Dokumentieren Sie die endgültige Konfiguration im Bereitstellungs-Runbook, um zu verhindern, dass eine erneute Nginx-Bereitstellung die Standardeinstellungen zurücksetzt.



## Häufig gestellte Fragen



### Why 60 seconds exactly?



Standard-Nginx-Proxy_read_timeout und aktueller Wert auf Load Balancern. Ein festes Intervall verweist auf die Transportschicht und nicht auf eine zufällige Anwendungsausnahme.



### What nginx directives for WebSocket?



HTTP/1.1, Upgrade, Verbindungs-Upgrade, hoher Proxy-Lese-/Send_Timeout, Zuordnung $http_upgrade für gemischte HTTP- und WebSocket-Verbindungen.



### Unterstützt Cloudflare WebSockets mit langer Laufzeit?



Ja bei kompatiblen Plänen; Für stille oder sehr lange Sitzungen wird weiterhin ein Anwendungs-Ping empfohlen.



### Sollten wir das Timeout unbegrenzt erhöhen?



Nein – kombinieren Sie ein Timeout, das auf den Herzschlag abgestimmt ist, und einen regelmäßigen Ping häufiger als das strengste Glied in der Kette.



---



Wenn Ihr WebSocket sofort abstürzt, debuggen Sie die Meldung nicht – debuggen Sie, wer die Verbindung schließt und nach wie vielen Sekunden genau.