Tradovate-WebSocket schließt sich genau nach 5 Minuten
Der Socket streamt 300 Sekunden lang einwandfrei und bricht dann ohne Fehler und ohne Warnung ab. Hier erfahren Sie, was ihn wirklich schließt, welcher Heartbeat-Takt ihn verlängert und welches Reconnect-Muster den Abbruch zum Nicht-Ereignis macht.
On This Page
- Was „WebSocket schließt sich genau nach 5 Minuten“ bedeutet
- Die häufigsten Ursachen für das 5-Minuten-Schließen des WebSockets 2026
- 1. Heartbeat-Frames kommen verspätet oder fehlen ganz
- 2. Timer-Drosselung im Browser (setInterval / setTimeout)
- 3. Serverseitiges Leerlauf- oder Sitzungs-Timeout
- 4. Senden auf einem Socket, der nicht OPEN ist (readyState 0)
- 5. Token-Ablauf und langlebige Verbindungen
- So beheben Sie das 5-Minuten-Schließen des WebSockets: Schritt für Schritt
- Lösung 1: Etwa alle 2,5 Sekunden einen Heartbeat-Frame senden
- Lösung 2: setInterval durch eine Zeitstempelprüfung oder einen Web Worker ersetzen
- Lösung 3: Jedes Senden mit einer readyState-Prüfung absichern
- Lösung 4: Reconnect-, Re-Authorize- und Resubscribe-Logik hinzufügen
- Tabelle zur Fehlerbehebung
- Verhindern Sie das mit PickMyTrade
Beim Automatisieren schneller Werte wie ES oder NQ ärgert wenig mehr als ein Tradovate-WebSocket, der nach einem Timer stirbt. Sie verbinden sich, autorisieren, abonnieren Marktdaten, und alles streamt wunderbar, bis genau zu den 300 Sekunden, wenn der Socket ohne Fehler, ohne Close-Grund und ohne Warnung abbricht. Es ist jedes Mal dieselbe Geschichte: Die Verbindung schließt sich genau nach 5 Minuten, selbst wenn Ihre Heartbeats korrekt zu feuern scheinen. Meist treten zwei verwandte Fehler auf, eine Ausnahme WebSocket is not open: readyState 0 (CONNECTING), wenn Ihr Code auf einen halb offenen Socket schreibt, und ein nackter Close-Code 1006 (abnormaler Abbruch) von der Gegenstelle. Hier erfahren Sie, was das 5-Minuten-Schließen 2026 tatsächlich bedeutet, die wirklichen Ursachen dahinter und das genaue Heartbeat-plus-Reconnect-Muster, das die Verbindung am Leben hält, außerdem, wie PickMyTrade diese Infrastruktur für Sie betreibt, sodass ein abgebrochener Socket Sie nie einen Fill kostet.
Kurze Checkliste für das 5-Minuten-Schließen des WebSockets
- Senden Sie etwa alle 2,5 Sekunden einen Heartbeat, einen Frame, dessen Text ein leeres JSON-Array ist,
[]. Lassen Sie ihn aus, und Tradovate schließt den Socket wegen Inaktivität. - Vertrauen Sie setInterval in einem Browser-Tab nicht, Hintergrund-Tabs werden gedrosselt, Ihr Heartbeat rutscht über 2,5 s hinaus, und der Server legt auf.
- Senden Sie Ihre eigenen Heartbeats, sobald Echtzeitdaten fließen, hört der Server auf, welche zu senden, der Client muss den Rhythmus also selbst halten.
- Sichern Sie jedes Senden mit einer readyState-Prüfung ab, schreiben Sie nur, wenn der Socket OPEN (1) ist, niemals solange er noch CONNECTING (0) ist.
- Protokollieren Sie das Close-Ereignis,
ws.addEventListener('close', e => console.log(e))zeigt den Code (oft 1006) und einen etwaigen Grund. - Gehen Sie davon aus, dass Abbrüche vorkommen, und verbinden Sie sich neu, kapseln Sie den Socket so, dass ein Schließen automatisch neu autorisiert und neu abonniert.
Was „WebSocket schließt sich genau nach 5 Minuten“ bedeutet
Die Echtzeit-API von Tradovate ist eine WebSocket-Verbindung: Sie öffnen sie, senden einen Autorisierungs-Frame und abonnieren dann die Daten und Ereignisse, die Sie interessieren. Damit die Verbindung offen bleibt, ist der Client dafür verantwortlich, Heartbeats zu senden, kleine Keep-Alive-Frames in einem festen Takt. Hören Sie damit auf, betrachtet Tradovate den Socket als im Leerlauf und schließt ihn serverseitig.
Dass der Ausfall so oft genau auf die 5-Minuten-Marke fällt, liegt daran, dass Timeouts entlang des Netzwerkpfads, beim Server, einem Load Balancer oder einem Proxy dazwischen, tendenziell in runden Zahlen durchgesetzt werden. Die Verbindung trennt sich genau alle 5 Minuten (300 Sekunden) ohne Meldung, und bezeichnenderweise erfolgt der Abbruch ohne Heartbeats stattdessen nach etwa 2 Minuten. Heartbeats verlängern also die Lebensdauer des Sockets, aber ein verspäteter oder ausgefallener Heartbeat oder ein unabhängiger Leerlauf-Timer irgendwo auf dem Pfad kann ihn dennoch bei 300 Sekunden guillotinieren. Es gibt keine veröffentlichte Grundursache für den exakten 5-Minuten-Fall, die dauerhafte technische Antwort lautet also nicht, jedes Schließen zu verhindern, sondern es zu überleben.
Die beiden Fehlermeldungen, die Sie sehen, sind Symptome desselben zugrunde liegenden Problems. WebSocket is not open: readyState 0 (CONNECTING) bedeutet, dass Ihr Code versuchte, send() aufzurufen, bevor der Handshake abgeschlossen war, häufig in einer Heartbeat-Funktion, die mitten in einer Neuverbindung feuert. Close-Code 1006 ist die Art von Browser oder Bibliothek zu sagen: “Die Verbindung ist abnormal abgebrochen”, ohne sauberen Close-Handshake, genau das, was Sie erhalten, wenn ein serverseitiger Leerlauf-Timer die Leitung kappt.
Die häufigsten Ursachen für das 5-Minuten-Schließen des WebSockets 2026
1. Heartbeat-Frames kommen verspätet oder fehlen ganz
Das ist die Ursache Nummer eins. Tradovate erwartet etwa alle 2,5 Sekunden einen Heartbeat-Frame mit dem Textinhalt [], um zu belegen, dass der Client lebt. Verpassen Sie dieses Fenster, startet der Server den Countdown zum Schließen. Und hier der Haken: Sobald Sie Echtzeitkurse streamen, hört der Tradovate-Server auf, eigene Heartbeats zu senden, Sie können sich also nicht auf den eingebauten Verkehr der Verbindung verlassen, um sie offen zu halten. Ihr Client muss den Frame mit den leeren Klammern nach eigenem Zeitplan senden.
2. Timer-Drosselung im Browser (setInterval / setTimeout)
Wenn Sie Heartbeats mit setInterval() oder setTimeout() in einem Browser planen, sind Sie der Priorität des Tabs ausgeliefert. Verliert der Tab den Fokus, senken Chrome (und die meisten Browser) die Priorität dieser Timer, sodass sich ein “2,5-Sekunden”-Intervall unbemerkt auf mehrere Sekunden dehnen kann. Der Heartbeat verpasst die Frist und der Socket schließt sich, oft rund um die 5-Minuten-Marke, sobald genügend Verzögerung aufgelaufen ist.
3. Serverseitiges Leerlauf- oder Sitzungs-Timeout
Selbst ein perfekt getakteter Heartbeat kann ein vorgelagert durchgesetztes Timeout nicht außer Kraft setzen. Ein Proxy, ein Gateway oder die Tradovate-Sitzung selbst kann die Leerlauf- oder Gesamtverbindungszeit begrenzen, weshalb der Abbruch auf die verdächtig runde 300-Sekunden-Grenze fällt. Da dies außerhalb Ihrer Kontrolle liegt, ist die Lösung die Wiederverbindung, nicht die Vorbeugung.
4. Senden auf einem Socket, der nicht OPEN ist (readyState 0)
Ein WebSocket hat vier Zustände: CONNECTING (0), OPEN (1), CLOSING (2) und CLOSED (3). Ruft Ihre Heartbeat-Schleife oder Ihr Order-Code send() auf, während der Socket noch bei readyState 0 ist, erhalten Sie WebSocket is not open: readyState 0 (CONNECTING) und oft direkt dahinter eine Meldung “Disconnected from Tradovate Market WebSocket”. Das trifft am härtesten im Augenblick nach einem Abbruch, wenn Ihre Neuverbindung einen neuen Socket gestartet hat, der seinen Handshake noch nicht abgeschlossen hat.
5. Token-Ablauf und langlebige Verbindungen
Ein Tradovate-Zugriffstoken hat eine begrenzte Lebensdauer, und diese Verbindungen sind nicht dafür gebaut, ewig zu leben, halten Sie einen einzelnen Socket sehr lange offen (über einen Tag), bricht er tendenziell ab. Läuft Ihr Token mitten in der Sitzung ab oder altert die Verbindung aus, schließt sich der Socket und jede erneute Autorisierung mit dem alten Token schlägt fehl. Token-Laufzeiten variieren und ändern sich im Lauf der Zeit, bestätigen Sie also die aktuellen Werte in der API-Dokumentation von Tradovate und erneuern Sie proaktiv, statt auf einen Fehler zu warten.
So beheben Sie das 5-Minuten-Schließen des WebSockets: Schritt für Schritt
Lösung 1: Etwa alle 2,5 Sekunden einen Heartbeat-Frame senden
Der Heartbeat ist die Grundlage. Senden Sie im Takt von etwa 2,5 Sekunden einen Frame, dessen Text ein leeres JSON-Array ist:
Die Keep-Alive-Routine starten
Starten Sie nach dem Öffnen des Sockets und der Autorisierung eine Keep-Alive-Routine.
Den Frame mit den leeren Klammern senden
Rufen Sie bei jedem Takt ws.send('[]') auf, der Frame mit den leeren Klammern ist der Heartbeat von Tradovate.
Das Intervall unter 2,5 s halten
Halten Sie das Intervall deutlich unter dem Limit (2,5 Sekunden ist das Ziel, etwas häufiger ist sicherer als etwas seltener).
Nie auf Server-Pings vertrauen
Gehen Sie nie davon aus, dass der Server Sie anpingt, nachdem Daten zu streamen begonnen haben, tut er es nicht.
Lösung 2: setInterval durch eine Zeitstempelprüfung oder einen Web Worker ersetzen
Da Browser-Timer gedrosselt werden, verlassen Sie sich nicht allein auf setInterval, weder in einem Vordergrund- noch in einem Hintergrund-Tab. Zwei bewährte Alternativen:
- Zeitstempelgesteuerte Heartbeats. Speichern Sie bei jeder empfangenen Nachricht einen Zeitstempel (
new Date()). Vergleichen Sie ihn mit dem Zeitpunkt, an dem Sie zuletzt einen Heartbeat gesendet haben; sind mehr als 2500 ms vergangen, senden Sie sofort[]. Das reagiert auf echten Verkehr statt auf einen Timer, den der Browser aushungern kann. - Den Timer vom Hauptthread verlagern. Führen Sie den Heartbeat in einem Web Worker aus oder betreiben Sie die gesamte Verbindung als Node.js-Dienst. Beides umgeht die Tab-Drosselung des Browsers vollständig, ein Node-Prozess unterliegt der Hintergrund-Tab-Strafe überhaupt nicht.
Lösung 3: Jedes Senden mit einer readyState-Prüfung absichern
Beseitigen Sie den readyState-0-Fehler, indem Sie nie auf einen Socket schreiben, der nicht offen ist:
readyState vor jedem Senden prüfen
Prüfen Sie vor jedem send(), ob Heartbeat oder Order, if (ws.readyState === WebSocket.OPEN) (das ist Zustand 1).
Überspringen und die Reconnect-Logik übernehmen lassen
Ist er noch CONNECTING (0) oder bereits CLOSING/CLOSED, überspringen Sie das Senden und lassen Sie Ihre Reconnect-Logik übernehmen.
Listener für alle Zustandsübergänge anhängen
Hängen Sie Listener für open, message, error und close an, damit Zustandsübergänge explizit sind, und protokollieren Sie das Close-Ereignisobjekt, um Code und Grund zu erfassen.
Lösung 4: Reconnect-, Re-Authorize- und Resubscribe-Logik hinzufügen
Da einige 5-Minuten-Abbrüche vorgelagert erzwungen werden und nicht verhindert werden können, behandeln Sie jeden Abbruch als behebbaren Fehler und bauen Sie automatisch neu auf:
Den Socket kapseln
Kapseln Sie den Socket in einer Klasse oder Funktion, die seinen Lebenszyklus besitzt, sodass eine einzige Stelle für Erzeugung und Abbau verantwortlich ist.
Beim Schließen neu verbinden
Verbinden Sie sich beim Schließen neu, öffnen Sie einen frischen Socket, statt zu versuchen, den toten wiederzubeleben.
Den neuen Socket neu autorisieren
Autorisieren Sie den neuen Socket mit einem gültigen Token neu (erzeugen Sie das Token vor Ablauf neu, damit immer ein frisches bereitsteht).
Alles neu abonnieren
Abonnieren Sie alles neu, was Sie hatten, senden Sie Ihren user/syncrequest erneut und abonnieren Sie jeden Marktdaten-Feed neu, denn ein neuer Socket beginnt ohne Abonnements.
Vor dem Senden auf OPEN warten
Warten Sie auf OPEN, bevor Sie irgendetwas auf dem neuen Socket senden, und fügen Sie ein kurzes Backoff hinzu, damit eine flatternde Verbindung den Server nicht bombardiert.
Tabelle zur Fehlerbehebung
| Fehler / Signal | Was es bedeutet | Lösung |
|---|---|---|
| Socket schließt sich genau nach 300 s | Ein Leerlauf- oder Sitzungs-Timeout auf dem Pfad hat die Verbindung gekappt | Heartbeats etwa alle 2,5 s senden und beim Schließen automatisch neu verbinden |
| Abbruch nach ca. 2 Minuten | Es werden überhaupt keine Heartbeats gesendet | Eine Keep-Alive-Routine starten, die den []-Frame im 2,5-s-Takt sendet |
| WebSocket is not open: readyState 0 (CONNECTING) | Code hat send() aufgerufen, bevor der Handshake abgeschlossen war | Nur senden, wenn readyState === OPEN (1); sonst überspringen |
| Close-Code 1006 | Abnormaler Abbruch ohne sauberen Handshake | Beim Schließen neu verbinden, neu autorisieren und neu abonnieren |
| „Disconnected from Tradovate Market WebSocket“ | Der Socket ist mitten im Stream abgebrochen | Den Socket neu aufbauen und Ihre Abonnements wiederherstellen |
| Heartbeats in Ordnung, aber Tab war inaktiv | Browser hat setInterval/setTimeout gedrosselt | Zeitstempelbasierte Heartbeats oder einen Web Worker / Node.js verwenden |
| Abbruch nach sehr langer Laufzeit | Token abgelaufen oder Verbindung gealtert | Das Token vor Ablauf erneuern und planmäßig neu verbinden |
Verhindern Sie das mit PickMyTrade
PickMyTrade sitzt zwischen Ihren TradingView-Alarmen und Tradovate und betreibt die WebSocket-Schicht als verwalteten, serverseitigen Dienst, sodass das 5-Minuten-Schließen behandelt wird, bevor es Sie überhaupt erreicht:
- Verwaltete Heartbeats, sendet den Keep-Alive-Frame in einem zuverlässigen serverseitigen Takt, ohne Browser-Tab, der den Timer drosseln könnte.
- Auto-Reconnect & Re-Auth, erkennt einen abgebrochenen Socket, öffnet einen neuen, autorisiert mit einem gültigen Token neu und abonniert automatisch neu.
- Verbindungszustands-Schutz, sendet nur, wenn der Socket tatsächlich offen ist, und eliminiert damit readyState-0-Sendefehler.
- Multi-Account Sync, hält den Stream jedes verbundenen Kontos gesund, sodass ein einzelner Reconnect nie ein Konto zurücklässt.
Handeln Sie ohne Ablehnungen
Starten Sie Ihre kostenlose 7-Tage-Testphase, verknüpfen Sie heute Ihre Alarme und handeln Sie ohne Ablehnungen.
Starten Sie Ihre kostenlose 7-Tage-TestphaseHäufig gestellte Fragen
Der Socket wird durch ein Leerlauf- oder Sitzungs-Timeout auf dem Verbindungsweg geschlossen, das gerne bei runden Zahlen wie 300 Sekunden greift. Heartbeats verlängern die Verbindung, doch wenn ein Heartbeat sich verspätet oder ein vorgelagerter Timer trotzdem auslöst, bricht der Socket dennoch ab. Die verlässliche Lösung sind Heartbeats plus automatische Wiederverbindung.
Etwa alle 2,5 Sekunden. Der Heartbeat ist ein Frame, dessen Text ein leeres JSON-Array ist, []. Etwas häufiger als alle 2,5 Sekunden zu senden ist sicherer, als einen verspäteten Frame zu riskieren.
Nur [], ein leeres JSON-Array, das als WebSocket-Nachrichtentext gesendet wird. Dieser Frame mit den leeren Klammern wird von Tradovate als Keep-Alive gelesen.
Ihr Code hat send() aufgerufen, während der Socket noch im Handshake war (Zustand 0) und noch nicht OPEN (Zustand 1). Prüfen Sie vor jedem Senden den readyState und überspringen Sie das Schreiben, bis der Socket OPEN meldet, damit Ihre Reconnect-Logik zuerst abschließen kann.
Nicht, sobald Echtzeitdaten streamen. Der Server hört auf, Heartbeats zu senden, nachdem der Datenfluss begonnen hat, daher muss der Client seine eigenen im 2,5-Sekunden-Takt senden. Sie können sich nicht auf Serververkehr verlassen, um die Verbindung offen zu halten.
Browser drosseln setInterval und setTimeout in inaktiven Tabs und dehnen Ihren 2,5-Sekunden-Heartbeat über das Limit hinaus. Verwenden Sie zeitstempelbasierte Heartbeats, die an empfangene Nachrichten gekoppelt sind, oder betreiben Sie die Verbindung in einem Web Worker oder einem Node.js-Prozess, um die Tab-Drosselung ganz zu umgehen.
Code 1006 ist ein abnormaler Abbruch ohne sauberen Close-Handshake, typischerweise eine abgebrochene Verbindung oder ein serverseitiges Timeout. Versuchen Sie nicht, jeden 1006 zu verhindern; kapseln Sie den Socket, verbinden Sie sich beim Schließen neu, autorisieren Sie mit einem frischen Token erneut und abonnieren Sie Ihre Feeds neu.
Dieser Leitfaden dient ausschließlich Bildungs- und Informationszwecken und stellt keine Finanz-, Anlage- oder Handelsberatung dar. Der Handel mit Futures und anderen gehebelten Produkten birgt ein erhebliches Verlustrisiko und ist nicht für jeden Anleger geeignet. PickMyTrade ist eine unabhängige Automatisierungsplattform eines Drittanbieters und steht in keiner Verbindung zu Tradovate, Inc., wird von diesem weder unterstützt noch gesponsert. „Tradovate“ und alle zugehörigen Namen, Logos und Marken sind Eigentum ihrer jeweiligen Inhaber. Plattformfunktionen und Abläufe ändern sich im Laufe der Zeit. Bestätigen Sie daher stets den aktuellen Ablauf in der offiziellen Tradovate-Plattform und -Dokumentation, bevor Sie handeln.