Tradovate MD: Täglich “Connection Forcibly Closed”

Das Muster kennen Sie inzwischen. In der lebhaften Eröffnungsphase läuft alles einwandfrei, dann wird der Markt ruhig und der Feed bricht mit An existing connection was forcibly closed by the remote host zusammen. Manchmal erholen sich die Charts nach einem schnellen Neuladen von selbst. Manchmal wird der gesamte Market-Data-Feed dunkel, und der OAuth-Login-Bildschirm erscheint erneut und verlangt eine neue Anmeldung. Und das ist kein Zufall, es trifft meist denselben ruhigen Abschnitt des Tages. Im Folgenden erfahren Sie, was dieser Fehler wirklich bedeutet, warum ruhige Kontrakte ihn häufiger auslösen als schnelle, und mit welchem Reconnect-plus-Re-Auth-Muster Sie verhindern, dass ein täglicher Zwangsabbruch zu einem verpassten Fill wird.

Was “Connection Forcibly Closed” wirklich bedeutet

Die Meldung An existing connection was forcibly closed by the remote host ist eine Windows-Sockets-Meldung, WinSock-Fehler 10054, auch als WSAECONNRESET bekannt. Vereinfacht gesagt hat die Gegenseite ein TCP-RST-Paket gesendet: Sie hat die Verbindung abrupt gekappt, statt den höflichen Close-Handshake zu durchlaufen. Ihr Client hat sich nicht selbst entschieden, aufzulegen. Etwas auf der Gegenseite hat es für Sie erledigt.

Dieses “Etwas” kann Tradovates Server sein, ein Load Balancer, ein Proxy oder ein Session-Timer irgendwo auf der Strecke. Beim Market-Data-Socket (MD) ist die praktische Lesart einfach: Die Verbindung war intakt, dann war sie in einem abrupten Schritt weg, ohne sauberes Herunterfahren, das Ihrem Code einen geordneten Hinweis gegeben hätte. Weil es sich um einen harten Reset handelt, kommt Ihr normaler Close-Handler kaum noch zum Zug, und jeder Schreibvorgang, den Sie auf diesem Socket in der Warteschlange hatten, wirft direkt danach einen Fehler.

Der entscheidende Perspektivwechsel: Ein Zwangsabbruch ist kein Defekt, den Sie wegpatchen können. TCP-Resets passieren, Netzwerke stottern, vorgelagerte Timer feuern, Sitzungen laufen ab. Die dauerhafte Lösung besteht nicht darin, jeden Abbruch zu verhindern. Sie besteht darin, eine Verbindung zu bauen, die den Abbruch sofort bemerkt und sich selbst wieder aufbaut, bevor Sie überhaupt zur Maus greifen würden.

Die häufigsten Ursachen für den täglichen Zwangsabbruch im Jahr 2026

1. Idle-Timeouts in ruhigen Marktphasen

Das ist die Hauptursache für das Muster “jeden Tag zur gleichen Zeit”. Wenn ein Kontrakt austrocknet, ein dünn gehandelter Agrar-Future mitten in der Sitzung oder ein beliebiges Symbol in der Übernachtruhe, bleiben Kursupdates aus. Ein Socket, der nur Market-Data-Ticks transportiert, wirkt für jeden Timer auf dem Weg nun untätig. Ohne einen stetigen Client-Heartbeat, der das Gegenteil beweist, entscheidet dieser Timer irgendwann, dass die Verbindung veraltet ist, und schließt sie zwangsweise. Je ruhiger das Tape, desto stärker schlägt das zu, weshalb sich die Abbrüche in den ruhigen Abschnitten Ihres Handelstags häufen.

2. Kein Heartbeat oder ein verspäteter Heartbeat

Tradovates Echtzeit-Feed erwartet, dass der Client etwa alle 2,5 Sekunden einen kleinen Keep-Alive-Frame mit dem Textinhalt [] sendet. Sobald Live-Daten fließen, stellt der Server das Senden eigener Heartbeats ein, Sie können sich also nicht auf eingehenden Traffic verlassen, um die Leitung offenzuhalten. Lassen Sie den Frame aus oder das Zeitfenster verstreichen, wird die Verbindung als tot markiert. Bei einem ruhigen Kontrakt gibt es keinen Tick-Verkehr, der einen verpassten Heartbeat verdeckt, ein nachlässiger Keep-Alive fliegt also schnell auf.

3. Die Sitzung und das Token hinter dem Socket sind abgelaufen

Stirbt der Socket, stirbt auch die darauf laufende autorisierte Sitzung. Deshalb erscheint der OAuth-Login-Bildschirm erneut: Der Client hat keine aktive Sitzung mehr, über die er streamen kann, und schickt Sie zurück zur Anmeldung. Schlimmer wird es, wenn Ihr Access-Token bereits kurz vor dem Ablauf stand: Selbst ein sofortiger Reconnect kann sich nicht mit einem veralteten Token autorisieren, sodass der neue Socket auf die gleiche Weise scheitert und Sie in einer Login-Schleife feststecken.

4. Zu aggressives Reconnecten (und die Folge: Rate-Limiting)

Sobald Sie die Abbrüche bemerken, ist der Instinkt, schnell neu zu verbinden, alle drei bis fünf Sekunden erneut zu versuchen, bis es klappt. Das geht nach hinten los. So schnell Verbindungen zu öffnen, löst Tradovates Rate-Limit aus und beschert Ihnen ein 429 Too Many Requests, das Sie noch härter aussperrt. Eine enge Reconnect-Schleife macht aus einem kurzen Ruhephasen-Aussetzer einen selbst verschuldeten Ausfall.

5. Sitzungslimits und langlebige Verbindungen

Jede neue Anmeldung startet eine neue serverseitige Sitzung, und die Anzahl gleichzeitiger Sitzungen ist begrenzt, starten Sie zu viele, werden die ältesten unter Ihnen weggeschlossen. Verbindungen sind zudem nicht für die Ewigkeit gedacht; halten Sie einen Socket über einen ganzen Tag offen, bricht er meist von selbst ab. Bei einem Prop- oder Evaluierungskonto können Sitzungs- und Reconnect-Regeln strenger sein und je nach Firma und Kontogröße variieren, prüfen Sie die aktuellen Regeln Ihrer Firma, statt anzunehmen, dass die Retail-Standardwerte gelten.

So beheben Sie den täglichen Zwangsabbruch: Schritt für Schritt

Lösung 1: Halten Sie den Socket mit einem echten Heartbeat am Leben

Heartbeats sind Ihre erste Verteidigungslinie, und sie zählen am meisten genau dann, wenn der Markt ruhig ist:

• Starten Sie nach dem Öffnen des Sockets und der Autorisierung eine Keep-Alive-Routine, die nach ihrer eigenen Uhr läuft, nicht abhängig von eingehenden Ticks.
• Senden Sie bei jedem Takt einen Frame mit dem Text [], den Keep-Alive mit leeren Klammern.
• Zielen Sie auf einen Takt knapp unter 2,5 Sekunden, damit ein leicht verspäteter Frame trotzdem innerhalb des Zeitfensters ankommt.
• Planen Sie ihn nicht mit einem einfachen Browser-Timer in einem Hintergrund-Tab, diese werden gedrosselt, das Intervall verschiebt sich, und der Socket bricht trotzdem ab. Betreiben Sie die Verbindung serverseitig oder in einem Worker, damit der Timer zuverlässig bleibt.

Lösung 2: Erkennen Sie den Abbruch und verbinden Sie sich mit Backoff neu

Da ein Zwangsabbruch früher oder später ohnehin passiert, kapseln Sie den Socket so, dass ein Abbruch ihn automatisch und kontrolliert wiederherstellt:

• Übernehmen Sie den Lebenszyklus. Kapseln Sie den Socket in einer einzigen Klasse oder Funktion, die für Erstellung, Abbau und Neuaufbau zuständig ist, sodass es eine einzige Stelle gibt, die auf einen Abbruch reagiert.
• Verbinden Sie bei Abbruch neu, wiederbeleben Sie nicht. Öffnen Sie einen brandneuen Socket, statt zu versuchen, den toten wiederzubeleben.
• Nutzen Sie exponentiellen Backoff. Beginnen Sie bei rund einer Sekunde, verdoppeln Sie die Wartezeit nach jedem gescheiterten Versuch, deckeln Sie sie bei rund sechzig Sekunden und fügen Sie 0–10 % zufälligen Jitter hinzu, damit nicht viele Clients gleichzeitig im Gleichschritt erneut versuchen. Das hält Sie von der 429-Sperre fern.
• Begrenzen Sie die Versuche, damit ein echter Ausfall nicht endlos weiterläuft, und zeigen Sie stattdessen einen klaren Fehler an, statt still weiterzuschleifen.

Lösung 3: Autorisieren Sie sich mit einem frischen Token neu, damit der OAuth-Bildschirm nie wieder erscheint

Der Reconnect ist nur die halbe Miete, der neue Socket braucht weiterhin eine gültige Sitzung:

• Erneuern Sie das Token proaktiv. Das Access-Token hat eine begrenzte Lebensdauer (häufig werden rund 60–90 Minuten genannt, und dieser Wert ändert sich mit der Zeit, prüfen Sie den aktuellen Wert in der API-Dokumentation). Erneuern Sie es rechtzeitig vor Ablauf über den Token-Erneuerungs-Endpunkt; eine gängige Richtlinie ist, etwa 15 Minuten vor Ablauf zu erneuern.
• Halten Sie ein frisches Token bereit. Tritt ein Abbruch ein, autorisieren Sie den neuen Socket mit einem Token, von dem Sie bereits wissen, dass es gültig ist, nicht mit dem, das gerade eben abgelaufen sein könnte.
• Nutzen Sie die Sitzung wo möglich weiter, damit Sie Ihr Limit für gleichzeitige Sitzungen nicht ausschöpfen und Ihre eigenen anderen Verbindungen nicht selbst aushebeln.
• Richtig umgesetzt, autorisiert sich der Client im Hintergrund neu, und Sie sehen den Login-Bildschirm überhaupt nie.

Lösung 4: Abonnieren Sie nach dem Reconnect jeden Feed erneut

Ein neuer Socket startet bei null, keine Abonnements, kein Sync, stellen Sie also den Zustand wieder her, bevor Sie den Daten vertrauen:

• Senden Sie Ihre Sync-Anfrage erneut, damit Konto- und Orderstatus wieder aktuell sind.
• Abonnieren Sie jedes Symbol und jeden Marktdaten-Feed, den Sie beobachtet haben, erneut; der neue Socket kennt keinen davon.
• Warten Sie, bis der Socket meldet, dass er wirklich offen ist, bevor Sie etwas senden, damit Sie nicht in eine halboffene Verbindung schreiben.
• Protokollieren Sie bei jedem Abbruch den Close-Code und den Grund, über eine Woche zeigt Ihnen das, welches ruhige Zeitfenster den Feed immer wieder killt.

Fehlerbehebungstabelle

So verhindern Sie das mit PickMyTrade

PickMyTrade sitzt zwischen Ihren TradingView-Alerts und Tradovate und betreibt die Verbindungsschicht als verwalteten, serverseitigen Dienst, sodass ein täglicher Zwangsabbruch längst behandelt ist, bevor er Sie einen Trade kosten kann:

• Verwaltete Heartbeats, sendet den Keep-Alive-Frame in einem stetigen serverseitigen Takt, sodass ein ruhiger Kontrakt für einen vorgelagerten Timer nie untätig wirkt.
• Automatischer Reconnect mit Backoff, erkennt den Zwangsabbruch, öffnet den Socket mit exponentiellem Backoff und Jitter neu und bleibt fern von der 429-Sperre.
• OAuth-Re-Auth im Hintergrund, erneuert das Token vor Ablauf und autorisiert automatisch neu, sodass der Login-Bildschirm Sie nie unterbricht.
• Automatisches Neu-Abonnieren & Multi-Account-Sync, stellt nach einem Reconnect jeden Feed wieder her und hält jedes verbundene Konto am Streamen, sodass ein Abbruch nie ein Konto zurücklässt.