Tradovate-WebSocket „Connection to Remote Host Lost“

Wenn Ihr Bot rund um die Uhr ES- oder NQ-Kurse streamt, killt nichts eine Strategie schneller als ein Tradovate-WebSocket, der still mit “Connection to remote host was lost.” stirbt. Es ist eines der häufigsten Probleme mit der Tradovate-API: Der Socket läuft stundenlang einwandfrei und bricht dann ab, sehr oft rund um die 24-Stunden-Marke, und nimmt Ihre Live-Marktdaten und das Order-Routing mit. Manchmal sehen Sie es als rohen WebSocket-Abbruch (Code 1006, “abnormal closure”). Manchmal wirkt es wie eine Massentrennung. Manchmal ist es einfach ein toter Feed, der nie eine Ausnahme auslöst.

Es gibt keine einzelne Zauber-Einstellung, die das behebt. Was einen Socket tatsächlich am Leben hält, ist ein Bündel zusammenwirkender Gewohnheiten: 2,5-Sekunden-Heartbeats, automatische Wiederverbindung, Token-Erneuerung und der Wechsel der Verbindung, bevor sie veraltet. PickMyTrade bringt diese Reconnect- und Re-Auth-Logik mit, sodass Ihre TradingView-Alarme Tradovate weiter erreichen, selbst wenn ein selbstgebauter Socket still umgefallen wäre.

Was „Connection to Remote Host Was Lost“ bedeutet

“Connection to remote host was lost” ist die Art von Tradovate, Ihnen mitzuteilen, dass der WebSocket zu seinen Servern geschlossen und nicht mehr nutzbar ist. Es ist ein Ereignis auf Transportebene, keine abgelehnte Order, keine fehlerhafte Anfrage. Die Leitung selbst ist weggefallen. Intern zeigt sich das meist als abnormaler WebSocket-Abbruch (Close-Code 1006), also eine Verbindung, die ohne sauberen Close-Handshake abgebrochen ist, sodass Ihr Client nicht immer genau sagen kann, warum.

Und hier stolpern viele: Eine verlorene Verbindung ist bei einem langlebigen Feed normal und erwartbar. Netzwerke zucken, Load Balancer recyceln, Leerlauf-Sockets werden entfernt, Tokens laufen ab, und sehr lange Sitzungen werden serverseitig gewechselt. Selbst ein vorbildlicher Client, der Live-Daten streamt, kann den Socket nach genügend Stunden Laufzeit verlieren. Das Ziel ist also nicht ein Socket, der nie abbricht, das ist unmöglich. Das Ziel ist ein Client, der den Abbruch sofort bemerkt und sich selbst wiederherstellt, ohne dass Sie ihn überwachen müssen.

Diese Unterscheidung ist für das Risiko wichtig. Stirbt Ihr Feed still und Ihr Code geht weiter davon aus, verbunden zu sein, können Sie Fills verpassen, Stop-Auslösungen verpassen oder Orders in ein veraltetes Marktbild feuern. Behandeln Sie jeden WebSocket als Wegwerfobjekt und jede Trennung als Routineereignis, das zu behandeln ist, nicht als Notfall.

Die häufigsten Ursachen für einen abgebrochenen Tradovate-WebSocket

1. Verpasste Heartbeats (Server-Leerlauf-Timeout)

Das ist die mit Abstand häufigste Ursache. Das WebSocket-Protokoll von Tradovate verlangt, dass der Client alle 2,5 Sekunden einen Heartbeat sendet, einen Frame, dessen Text ein leeres Array ist, [], um zu beweisen, dass er noch lebt. Hört der Server 2,5 Sekunden nichts von Ihnen und streamt Ihnen nicht aktiv Daten, behandelt er den Client als inaktiv und schließt die Verbindung. Und hier der Haken: Solange der Server aktiv Nachrichten pusht (etwa bei einem regen Marktdaten-Abonnement), sendet er keine eigenen Heartbeats, sodass es allein Ihrem Client obliegt, die []-Frames fließen zu lassen.

2. Browser-/Timer-Drosselung

Wenn Sie im Browser entwickeln und Heartbeats mit setInterval oder setTimeout planen, tappen Sie in eine subtile Falle: Browser drosseln Timer in Hintergrund- oder inaktiven Tabs und dehnen Ihr 2,5-Sekunden-Intervall auf mehrere Sekunden. Sobald es das Fenster überschreitet, schließt der Server den Socket. Verlassen Sie sich nicht auf setInterval, sondern takten Sie Ihre Heartbeats ab der zuletzt tatsächlich empfangenen Nachricht.

3. Ablauf des Zugriffstokens

Ihr WebSocket wird einmal mit einem Zugriffstoken autorisiert, und dieses Token hat laut API-Dokumentation von Tradovate eine begrenzte Lebensdauer von etwa 90 Minuten ab Erstellung. Läuft das Token hinter einer aktiven Verbindung ab, ist die Verbindung nicht mehr authentifiziert und kann getrennt werden. Ein langlaufender Client, der sein Token nie erneuert, sieht den Socket in vorhersehbarem Takt sterben.

4. Langlebige Verbindungen über ca. 24 Stunden

Eine Verbindung länger als 24 Stunden aufrechtzuerhalten, ist für sich genommen eine anerkannte Ursache für Abbrüche. Selbst mit perfekten Heartbeats und einem frischen Token ist ein Socket, der seit etwa einem Tag offen ist, ein Hauptkandidat dafür, serverseitig recycelt zu werden. Deshalb stirbt eine rohe Verbindung, die “den ganzen Nachmittag funktionierte”, rätselhaft über Nacht.

5. Reconnect-Stürme und das Sitzungslimit

Bricht ein Socket ab, bombardiert naiver Code den Server oft mit sofortigen, aufeinanderfolgenden Reconnect-Versuchen. Das kann die Anfrage-Ratenlimits von Tradovate auslösen und die Lage verschlimmern, und wiederholtes erneutes Authentifizieren (statt Erneuerung) kann Sie gegen die Obergrenze gleichzeitiger Sitzungen laufen lassen. Das Ergebnis ist ein Client, der in einer Reconnect-Schleife festhängt und sich nie stabilisiert.

So beheben Sie eine verlorene Tradovate-WebSocket-Verbindung: Schritt für Schritt

Den Heartbeat alle 2,5 Sekunden richtig senden

Diese eine Gewohnheit löst die Mehrheit der Meldungen “connection to remote host was lost”, weil sie die Leerlauf-Timeout-Regel des Servers direkt erfüllt.

Automatische Wiederverbindung und Neuabonnement-Logik hinzufügen

Das Zugriffstoken erneuern und den Socket neu autorisieren

Bestätigen, dass der API-Zugriff aktiviert ist und Sie innerhalb des Sitzungslimits liegen

Die Verbindung vor 24 Stunden proaktiv wechseln

Warten Sie nicht, bis der Server einen Tag alten Socket trennt, sondern kommen Sie ihm zuvor. Schließen Sie per Timer, deutlich unter der Obergrenze von ca. 24 Stunden, Ihren bestehenden WebSocket sauber und öffnen Sie einen neuen mit einem frisch erneuerten Token, dann neu autorisieren und neu abonnieren. Da Ihr Reconnect-Pfad bereits existiert (Sie haben ihn im vorherigen Schritt gebaut), ist ein geplanter Wechsel nur eine kontrollierte Version derselben Routine. Er macht aus einer überraschenden Trennung um 3 Uhr nachts eine geplante, unsichtbare Auffrischung.

Tabelle zur Fehlerbehebung

Verhindern Sie das mit PickMyTrade

Wenn Ihr Ziel schlicht ist, TradingView-Alarme zuverlässig in Tradovate zu bekommen, müssen Sie diese gesamte Socket-Infrastruktur nicht selbst bauen und überwachen. PickMyTrade sitzt zwischen TradingView und Tradovate und hält die Verbindung für Sie gesund.

• Verwaltete Reconnect-Logik, automatischer Reconnect, Re-Autorisierung und Neuabonnement bei jedem Abbruch, sodass ein verlorener Socket sich erholt, ohne dass Sie den Code schreiben oder pflegen müssen.
• Integrierte Token-Erneuerung, Sitzungen werden vor Ablauf aufgefrischt, sodass die Verbindung authentifiziert bleibt, statt an der 90-Minuten-Token-Uhr zu sterben.
• Verbindungswechsel, langlebige Verbindungen werden proaktiv recycelt, sodass der Abbruch nach ca. 24 Stunden Ihre Automatisierung nie offline erwischt.
• Ratenlimit-sicheres Routing, Reconnects und Order-Fluss werden zeitlich gestreckt, um die Limits von Tradovate einzuhalten, und vermeiden die Reconnect-Sturm-Sperren, die rohe Sockets plagen.