Tradovate-WebSocket-Fehler 10054 / SSL / 502
WinError 10054, SSL-Protokollversions-Alerts und ein 502 beim Handshake sind die drei Fehler, die die meisten Tradovate-Sockets beenden. Hier sehen Sie, welche TLS-Probleme Sie beheben können und welche vorübergehenden Server-Aussetzer Sie einfach überstehen müssen.
On This Page
- Was "[WinError 10054] An Existing Connection Was Forcibly Closed by the Remote Host" bedeutet
- Häufigste Ursachen für Tradovate-WebSocket-Fehler
- 1. Veraltete TLS-Version im Client
- 2. Fehlende oder gedrosselte Heartbeats
- 3. Das 2-Sitzungen-Limit und Token-Invalidierung
- 4. Vorübergehende 502-/serverseitige Trennungen
- 5. Zu aggressives Neuverbinden
- So beheben Sie Tradovate-WebSocket-Fehler: Schritt für Schritt
- SSL-/Protokollversionsfehler beheben (und das durch den Handshake ausgelöste 10054)
- Die Verbindung mit Heartbeats am Leben halten
- Reconnect-Logik für 10054 und 502 hinzufügen
- Tabelle zur Fehlerbehebung
- Vermeiden Sie das mit PickMyTrade
Wenn Ihr Bot über die Tradovate-API Live-Kurse von ES oder NQ streamt und der Socket mitten in der Sitzung stirbt, ist jede Sekunde offline ein Fill, den Sie nicht managen können. Drei WebSocket-Fehler beenden mehr Verbindungen als alles andere: [WinError 10054] An existing connection was forcibly closed by the remote host, das SSL-Paar SSL: TLSV1_ALERT_PROTOCOL_VERSION / SSL: SSLV3_ALERT_BAD_RECORD_MAC und ein 502 Bad Gateway beim Handshake. Die ersten beiden sind fast immer ein TLS-Verhandlungsproblem auf Ihrer Seite. Das 502 ist ein vorübergehender Server-Aussetzer. Die dauerhafte Lösung ist eine zweiteilige Kombination: Verhandeln Sie eine moderne TLS-Version, damit der Handshake gelingt, und umhüllen Sie den Socket mit Reconnect-Logik, damit sich eine getrennte Verbindung selbst neu aufbaut, statt Ihre Automatisierung komplett zu stoppen. Eine Brücke wie PickMyTrade übernimmt beides für Sie, aber wenn Sie Ihren eigenen Client bauen, zeigen wir hier, wie Sie jede Variante diagnostizieren und beheben.
Kurz-Checkliste bei Tradovate-WebSocket-Fehlern
- Erhalten Sie einen SSL-Protokoll-/Versions-Alert? Erzwingen Sie in Ihrem Client TLS 1.2 oder höher. Die Server von Tradovate akzeptieren TLS ab v1.1, und alte Standardwerte wie TLS 1.0 und SSLv3 werden abgelehnt.
- Erhalten Sie WinError 10054 zufällig? Behandeln Sie es als erwartetes Signal “wir haben Sie getrennt”, nicht als Fehler. Bauen Sie Catch-and-Reconnect, statt jede Trennung verhindern zu wollen.
- Erhalten Sie ein 502 Bad Gateway? Es liegt auf Serverseite. Warten Sie ab und wiederholen Sie dann den Handshake mit exponentiellem Backoff und Jitter.
- Socket schließt sich nach ein paar Minuten Ruhe? Ihnen fehlen Heartbeats, senden Sie alle ~2,5 Sekunden einen
[]-Frame. - Socket stirbt direkt nach einem Login an anderer Stelle? Sie haben das 2-Sitzungen-Limit überschritten. Ein neues Token macht die alte Sitzung ungültig und schließt deren Socket.
- Verbinden Sie sich nie in einer engen Schleife neu. Den Endpunkt zu bombardieren kann Ratenlimits auslösen und alles verschlimmern.
Was "[WinError 10054] An Existing Connection Was Forcibly Closed by the Remote Host" bedeutet
WinError 10054 (auch als WSAECONNRESET geschrieben) ist ein Fehler der Windows-Sockets–Schicht, kein Tradovate-spezifischer. Er bedeutet, dass die TCP-Verbindung von der Gegenseite zurückgesetzt wurde, bevor Ihr Code damit rechnete. Sehen Sie ihn als allgemeine Websocket-Server-Meldung, die im Grunde sagt: “Hey, wir haben Ihre Verbindung getrennt, Entschuldigung.” Bei einem langlebigen Socket ist es normal, ihn ab und zu zu sehen.
Zwei Dinge lösen ihn am häufigsten aus. Erstens ein fehlgeschlagener TLS-Handshake: Wenn sich Ihr Client und die Server von Tradovate nicht auf eine TLS-Version oder Cipher Suite einigen können, setzt der Server die Verbindung zurück und Windows meldet das als 10054. Derselbe Fehler steht für Handshake-Fehler vor dem Login, bei denen zwischen Client und Server keine passenden TLS-Protokolle existieren. Zweitens Inaktivität oder ein vorübergehender Netzwerkaussetzer, ein gedrosselter Heartbeat, ein verlorenes WLAN-Paket oder ein routinemäßiger Server-Neustart.
Die SSL-Varianten machen die Handshake-Ursache explizit. SSL: TLSV1_ALERT_PROTOCOL_VERSION bedeutet, dass der Server die von Ihrem Client angebotene TLS-Version abgelehnt hat. SSL: SSLV3_ALERT_BAD_RECORD_MAC deutet auf einen beschädigten oder nicht passenden TLS-Record hin, oft von einem veralteten SSL/TLS-Stack. Ein 502 Bad Gateway ist wieder etwas anderes: Der Handshake hat den Edge von Tradovate erreicht, aber ein Upstream-Knoten war kurzzeitig nicht verfügbar, sodass nichts, was Sie clientseitig ändern, es “behebt”, Sie wiederholen es einfach.
Häufigste Ursachen für Tradovate-WebSocket-Fehler
1. Veraltete TLS-Version im Client
Das ist die mit Abstand häufigste Ursache der SSL- und 10054-Fehler. Die Server von Tradovate unterstützen TLS ab v1.1, sodass jeder Client, der noch standardmäßig TLS 1.0 oder SSLv3 verwendet, alte Python-Builds, veraltete .NET-Framework-Einstellungen, ein ungepatchtes OpenSSL, seinen Handshake abgelehnt bekommt. Verhandeln Sie TLS 1.2 oder 1.3, die jeder aktuelle Tradovate-Endpunkt akzeptiert.
2. Fehlende oder gedrosselte Heartbeats
Nach dem Verbinden ist Ihr Client dafür verantwortlich, den Socket am Leben zu halten. Tradovate erwartet etwa alle 2,5 Sekunden einen Heartbeat-Frame, den Text []. Verpassen Sie das Fenster, schließt der Server die Verbindung, was bei Ihrem nächsten Lesevorgang als 10054 wieder auftaucht. In Browsern ist das eine klassische Falle: Hintergrund-Tabs drosseln Timer, sodass ein setInterval()-Heartbeat leise langsamer wird und der Socket stirbt.
3. Das 2-Sitzungen-Limit und Token-Invalidierung
Ein Tradovate-Nutzer ist auf eine kleine Zahl gleichzeitiger Sitzungen begrenzt. Sobald eine dritte (oder weitere) Sitzung erstellt wird, werden die ältesten Sitzungen geschlossen. Das Anfordern eines neuen Access-Tokens startet eine neue Sitzung und macht das alte Token ungültig, sodass jeder WebSocket, der noch das vorherige Token nutzt, getrennt wird. Stirbt Ihr Socket in dem Moment, in dem Sie sich auf einem anderen Gerät anmelden oder einen zweiten Client neu authentifizieren, ist das der Grund.
4. Vorübergehende 502-/serverseitige Trennungen
Manchmal liegt der Fehler wirklich nicht bei Ihnen. Ein 502 Bad Gateway beim Handshake oder ein Reset mitten in der Sitzung ohne Code-Änderungen auf Ihrer Seite bedeutet, dass die Infrastruktur von Tradovate neu startet oder kurzzeitig nicht erreichbar ist. Versuchen Sie nicht, jede Trennung zu verhindern, erkennen Sie sie und stellen Sie die Verbindung wieder her.
5. Zu aggressives Neuverbinden
Die Kehrseite der Wiederherstellung ist die Überkorrektur. Eine Reconnect-Schleife ohne Verzögerung bombardiert den Endpunkt, kann Login- und Anfrage-Ratenlimits auslösen und macht aus einem Zwei-Sekunden-Aussetzer eine Sperre. Jeder zuverlässige Client braucht Backoff, keine while True-Wiederholung.
So beheben Sie Tradovate-WebSocket-Fehler: Schritt für Schritt
SSL-/Protokollversionsfehler beheben (und das durch den Handshake ausgelöste 10054)
Eine moderne Mindest-TLS-Version festlegen
Verlangen Sie in Ihrem Socket-/SSL-Kontext ausdrücklich TLS 1.2 oder 1.3, statt sich auf den Sprachstandard zu verlassen.
Ihren Krypto-Stack aktualisieren
Aktualisieren Sie Python (und das mitgelieferte OpenSSL), Node oder die .NET-Runtime, damit die neueren Protokolle tatsächlich zur Verhandlung zur Verfügung stehen.
Den Endpunkt bestätigen
Verweisen Sie auf den korrekten, aktuellen Tradovate-WebSocket-Host, zum Beispiel wss://live.tradovateapi.com/v1/websocket für Live, den Demo-Host für die Simulation und den Marktdaten-Host für Kurse. Bestätigen Sie den genauen Host in der aktuellen API-Dokumentation, da sich Endpunkte gelegentlich ändern.
Den Handshake erneut testen
Eine saubere Verbindung liefert jetzt den o-Open-Frame des Servers statt eines SSL-Alerts oder eines sofortigen 10054.
Die Verbindung mit Heartbeats am Leben halten
[] im ~2,5-Sekunden-Takt senden
Beginnen Sie nach der Autorisierung, den Frame mit dem leeren Array auszugeben, damit der Server Sie nie als inaktiv ansieht.
Verlassen Sie sich in einem Browser nicht auf setInterval
Steuern Sie Heartbeats reaktiv: Versehen Sie jede empfangene Nachricht mit einem Zeitstempel und senden Sie einen Heartbeat, sobald ~2,5 Sekunden vergangen sind, oder führen Sie den Client in einem Web Worker oder als Node.js-Prozess aus, damit Timer nicht gedrosselt werden.
Auf Stille achten
Erhalten Sie mehrere Sekunden lang keine Servernachricht, gehen Sie davon aus, dass der Socket veraltet ist, und bauen Sie ihn ab, statt zu warten, bis ein Lesevorgang fehlschlägt.
Reconnect-Logik für 10054 und 502 hinzufügen
Die Trennung abfangen
Behandeln Sie das Close-/Error-Ereignis des Sockets (einschließlich 10054 und 502), statt die Ausnahme Ihr Programm anhalten zu lassen.
Neu instanziieren und neu autorisieren
Öffnen Sie bei einer Trennung einen neuen Socket und führen Sie den vollständigen Authorize-Handshake erneut aus, die alte Sitzung oder das Token könnte tot sein.
Exponentiell mit Jitter zurückfahren
Beginnen Sie bei etwa einer Sekunde und steigern Sie die Verzögerung bis zu einer sinnvollen Obergrenze (zehn Sekunden), und fügen Sie zufälligen Jitter hinzu, damit parallele Clients sich nicht im Gleichschritt neu verbinden.
Begrenzen und alarmieren
Begrenzen Sie die Versuche und lösen Sie bei Erschöpfung einen Alert aus, statt endlos zu schleifen, das ist Ihr Hinweis darauf, dass ein echter Ausfall oder ein Ratenlimit-/Sitzungsproblem vorliegt.
Tabelle zur Fehlerbehebung
| Fehler | Bedeutung | Lösung |
|---|---|---|
| [WinError 10054] An existing connection was forcibly closed by the remote host | Server hat die TCP-/WebSocket-Verbindung zurückgesetzt, Handshake-Fehler oder vorübergehende Trennung | TLS 1.2+ festlegen, dann abfangen und mit Backoff neu verbinden |
| SSL: TLSV1_ALERT_PROTOCOL_VERSION | Server hat die von Ihrem Client angebotene TLS-Version abgelehnt | TLS 1.2/1.3 erzwingen; Krypto-Stack aktualisieren |
| SSL: SSLV3_ALERT_BAD_RECORD_MAC | Beschädigter/nicht passender TLS-Record von einem veralteten SSL-Stack | OpenSSL/Runtime aktualisieren und eine moderne TLS-Version verhandeln |
| 502 Bad Gateway | Vorübergehende serverseitige Nichtverfügbarkeit beim Handshake | Warten und mit exponentiellem Backoff wiederholen (serverseitig, nicht Ihr Fehler) |
| Socket schließt sich nach ~Sekunden Stille | Heartbeats verpasst, Server behandelt Sie als inaktiv | Alle ~2,5 Sekunden einen []-Heartbeat senden |
| Socket stirbt direkt nach neuem Login/Token | Limit gleichzeitiger Sitzungen erreicht; altes Token ungültig | Sitzungen zusammenführen; neu verbinden und neu autorisieren |
Vermeiden Sie das mit PickMyTrade
Wenn Sie lieber keinen selbstgebauten WebSocket-Client pflegen möchten, sitzt PickMyTrade zwischen TradingView und Tradovate und verwaltet die Verbindung für Sie:
- Verwaltete, TLS-korrekte Verbindung, die Brücke verhandelt einen modernen, kompatiblen TLS-Handshake, sodass SSL-Protokollversions- und Bad-Record-Fehler Ihre Strategie nie erreichen.
- Integrierte Heartbeats und Wiederverbindung, Heartbeats und Wiederverbindung mit exponentiellem Backoff laufen serverseitig, sodass sich ein 10054 oder 502 selbst heilt, statt Ihre Automatisierung zu stoppen.
- Sitzungsbewusstes Routing, der Orderfluss wird getaktet und sequenziert, damit Sie bei Wiederverbindungen keine Limits für gleichzeitige Sitzungen oder Ratenlimits auslösen.
- Multi-Account-Synchronisierung, sobald sich die Verbindung erholt, wird derselbe Alert ohne doppelte oder verpasste Orders auf alle verknüpften Konten gespiegelt.
Lassen Sie die Brücke den Socket übernehmen
Haben Sie genug davon, einen rohen Socket zu bemuttern? Starten Sie Ihre kostenlose 7-Tage-Testphase, verknüpfen Sie noch heute Ihre Alerts und lassen Sie die Brücke TLS, Heartbeats und Wiederverbindungen für Sie erledigen.
Starten Sie Ihre kostenlose 7-Tage-TestphaseHäufig gestellte Fragen
In der Regel nicht. Es ist ein allgemeines Signal „wir haben Ihre Verbindung getrennt“ für langlebige WebSocket-Verbindungen. Zum Problem wird es nur, wenn Sie sich nicht neu verbinden. Bauen Sie eine Catch-and-Reconnect-Logik, und ein gelegentliches 10054 wird zum Nicht-Ereignis.
Die Server von Tradovate akzeptieren TLS ab v1.1. Da TLS 1.0 und 1.1 branchenweit veraltet sind, verhandeln Sie TLS 1.2 oder 1.3, beide werden akzeptiert und sind der moderne Standard.
Ein 502 liegt auf Serverseite. Der Handshake hat den Edge von Tradovate erreicht, aber ein Upstream-Knoten war kurzzeitig nicht verfügbar. Clientseitig gibt es nichts zu beheben, warten Sie einen Moment und versuchen Sie es mit Backoff erneut.
Etwa alle 2,5 Sekunden. Der Heartbeat ist ein Frame mit dem Text [] (ein leeres Array). Verpassen Sie den Takt, schließt der Server den Socket wegen Inaktivität.
Sie haben wahrscheinlich das Limit gleichzeitiger Sitzungen erreicht. Das Erstellen eines neuen Access-Tokens startet eine neue Sitzung und macht das alte Token ungültig, sodass jeder Socket, der noch das vorherige Token verwendet, getrennt wird. Verwenden Sie eine Sitzung wieder oder verbinden Sie sich neu und autorisieren Sie sich erneut.
Eine Schleife ohne Verzögerung bombardiert den Endpunkt und kann Ratenlimits auslösen, was die Wiederherstellung verschlimmert. Fügen Sie exponentielles Backoff mit Jitter hinzu, begrenzen Sie die Versuche und führen Sie bei jedem Versuch den vollständigen Authorize-Handshake erneut aus.
Ein getrennter Socket storniert keine aktiven Orders auf Seiten von Tradovate, aber Sie verlieren die Echtzeit-Sicht, bis Sie sich neu verbinden. Gleichen Sie nach einer Trennung stets Positionen und Orders ab, bevor Sie neue Einstiege senden.
Ja. Eine Brücke wie PickMyTrade übernimmt den TLS-Handshake, die Heartbeats und die Wiederverbindung für Sie, sodass Sie einen einfachen Alert senden und nie rohen Socket-Code anfassen.
Dieser Leitfaden dient ausschließlich Bildungs- und Informationszwecken und stellt weder Finanz-, Anlage- noch 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 weder von Tradovate, Inc. unterstützt noch gesponsert. „Tradovate“ sowie alle zugehörigen Namen, Logos und Marken sind Eigentum ihrer jeweiligen Inhaber. Funktionen und Schritte der Plattform ändern sich im Laufe der Zeit. Prüfen Sie daher stets den aktuellen Ablauf in der offiziellen Tradovate-Plattform und -Dokumentation, bevor Sie handeln.