Tradovate API

Erreurs WebSocket Tradovate 10054 / SSL / 502

WinError 10054, les alertes de version de protocole SSL et un 502 lors du handshake sont les trois erreurs qui tuent le plus de sockets Tradovate. Voici lesquelles sont des problèmes TLS que vous pouvez corriger et lesquelles sont des accrocs serveur transitoires qu'il suffit de traverser.

On This Page

Lorsque votre bot diffuse des cotations ES ou NQ en direct via l'API Tradovate et que le socket meurt en pleine séance, chaque seconde hors ligne est un fill que vous ne pouvez pas gérer. Trois erreurs WebSocket tuent plus de connexions que tout le reste : [WinError 10054] An existing connection was forcibly closed by the remote host, la paire SSL SSL: TLSV1_ALERT_PROTOCOL_VERSION / SSL: SSLV3_ALERT_BAD_RECORD_MAC, et un 502 Bad Gateway lors du handshake. Les deux premières sont presque toujours un problème de négociation TLS de votre côté. Le 502 est un accroc serveur transitoire. Le correctif permanent est un combo en deux parties : négocier une version moderne de TLS pour que le handshake réussisse, et envelopper le socket dans une logique de reconnexion pour qu'une connexion coupée se réinstancie d'elle-même au lieu d'arrêter net votre automatisation. Un pont comme PickMyTrade gère les deux pour vous, mais si vous développez votre propre client, voici comment diagnostiquer et corriger chaque variante.

Liste de contrôle rapide pour les erreurs WebSocket Tradovate

  • Vous recevez une alerte de protocole/version SSL ? Forcez votre client en TLS 1.2 ou supérieur. Les serveurs de Tradovate acceptent TLS v1.1 et supérieur, et les anciennes valeurs par défaut comme TLS 1.0 et SSLv3 sont refusées.
  • Vous recevez WinError 10054 au hasard ? Traitez-le comme un signal attendu “nous vous avons déconnecté”, pas comme un bug. Construisez capture et reconnexion plutôt que d'essayer d'empêcher chaque coupure.
  • Vous recevez un 502 Bad Gateway ? C'est côté serveur. Patientez, puis réessayez le handshake avec un backoff exponentiel et du jitter.
  • Le socket se ferme après quelques minutes de calme ? Il vous manque des heartbeats, envoyez une trame [] toutes les ~2,5 secondes.
  • Le socket meurt juste après une connexion ailleurs ? Vous avez dépassé la limite de 2 sessions. Un nouveau jeton invalide l'ancienne session et ferme son socket.
  • Ne vous reconnectez jamais dans une boucle serrée. Marteler le point de terminaison peut déclencher des limites de débit et aggraver les choses.

Ce que signifie "[WinError 10054] An Existing Connection Was Forcibly Closed by the Remote Host"

WinError 10054 (également écrit WSAECONNRESET) est une erreur de la couche sockets–de Windows, pas une erreur propre à Tradovate. Elle signifie que la connexion TCP a été réinitialisée par l'autre extrémité avant que votre code ne s'y attende. Voyez-y un message générique de serveur websocket qui dit, en substance, “Hé, nous avons coupé votre connexion, désolé.” Pour un socket de longue durée, la voir de temps en temps est normal.

Deux choses la déclenchent le plus souvent. D'abord, un échec du handshake TLS : si votre client et les serveurs de Tradovate ne parviennent pas à s'accorder sur une version de TLS ou une suite de chiffrement, le serveur réinitialise la connexion et Windows la remonte sous la forme 10054. Cette même erreur correspond aux échecs de handshake avant connexion où aucun protocole TLS commun n'existe entre le client et le serveur. Ensuite, l'inactivité ou un accroc réseau transitoire, un heartbeat bridé, un paquet Wi-Fi perdu ou un recyclage serveur de routine.

Les variantes SSL rendent la cause du handshake explicite. SSL: TLSV1_ALERT_PROTOCOL_VERSION signifie que le serveur a rejeté la version de TLS proposée par votre client. SSL: SSLV3_ALERT_BAD_RECORD_MAC pointe vers un enregistrement TLS corrompu ou non concordant, souvent issu d'une pile SSL/TLS héritée. Un 502 Bad Gateway est encore différent : le handshake a atteint la périphérie de Tradovate mais un nœud en amont a été momentanément indisponible, donc rien de ce que vous changez côté client ne le “corrige”, vous réessayez simplement.

Principales causes des erreurs WebSocket Tradovate

1. Version de TLS obsolète côté client

C'est la cause la plus courante des erreurs SSL et 10054. Les serveurs de Tradovate prennent en charge TLS v1.1 ou supérieur, donc tout client qui utilise encore TLS 1.0 ou SSLv3 par défaut, d'anciennes versions de Python, des paramètres .NET Framework hérités, un OpenSSL non patché, voit son handshake refusé. Négociez TLS 1.2 ou 1.3, que tout point de terminaison Tradovate actuel accepte.

2. Heartbeats manquants ou bridés

Une fois connecté, votre client est responsable du maintien en vie du socket. Tradovate attend une trame de heartbeat, le texte littéral [], environ toutes les 2,5 secondes. Manquez la fenêtre et le serveur ferme la connexion, ce qui réapparaît sous la forme d'un 10054 à votre prochaine lecture. Dans les navigateurs, c'est un piège classique : les onglets en arrière-plan brident les minuteries, de sorte qu'un heartbeat setInterval() ralentit discrètement et que le socket meurt.

3. La limite de 2 sessions et l'invalidation du jeton

Un utilisateur Tradovate est limité à un petit nombre de sessions simultanées. Dès qu'une troisième session (ou davantage) est créée, les plus anciennes sont fermées. Demander un nouveau jeton d'accès démarre une nouvelle session et invalide l'ancien jeton, de sorte que tout WebSocket utilisant encore le jeton précédent est déconnecté. Si votre socket meurt à l'instant où vous vous connectez depuis un autre appareil ou réauthentifiez un second client, voilà pourquoi.

4. Coupures 502 / côté serveur transitoires

Parfois, la faute n'est vraiment pas la vôtre. Un 502 Bad Gateway pendant le handshake, ou une réinitialisation en cours de session sans changement de code de votre côté, correspond à l'infrastructure de Tradovate qui se recycle ou est momentanément injoignable. N'essayez pas d'empêcher chaque coupure, détectez-la et récupérez.

5. Reconnexion trop agressive

Le revers de la récupération est la surcorrection. Une boucle de reconnexion sans délai martèle le point de terminaison, peut déclencher des limites de débit de connexion et de requêtes, et transforme un accroc de deux secondes en blocage. Tout client fiable a besoin d'un backoff, pas d'une relance while True.

Comment corriger les erreurs WebSocket Tradovate : pas à pas

Corriger les erreurs SSL / de version de protocole (et le 10054 déclenché par le handshake)

1

Fixer une version minimale moderne de TLS

Exigez explicitement TLS 1.2 ou 1.3 dans votre contexte socket/SSL plutôt que de vous fier à la valeur par défaut du langage.

2

Mettre à jour votre pile cryptographique

Mettez à niveau Python (et son OpenSSL intégré), Node ou le runtime .NET afin que les protocoles récents soient réellement disponibles pour la négociation.

3

Confirmer le point de terminaison

Pointez vers l'hôte WebSocket Tradovate correct et actuel, par exemple wss://live.tradovateapi.com/v1/websocket pour le live, l'hôte démo pour la simulation et l'hôte de données de marché pour les cotations. Confirmez l'hôte exact dans la documentation actuelle de l'API, car les points de terminaison changent à l'occasion.

4

Retester le handshake

Une connexion propre renvoie désormais la trame open o du serveur au lieu d'une alerte SSL ou d'un 10054 immédiat.

Maintenir la connexion en vie avec des heartbeats

1

Envoyer [] à une cadence d'environ 2,5 secondes

Après l'autorisation, commencez à émettre la trame de tableau vide afin que le serveur ne vous considère jamais comme inactif.

2

Ne pas se fier à setInterval dans un navigateur

Pilotez les heartbeats de façon réactive : horodatez chaque message reçu et envoyez un heartbeat dès que ~2,5 secondes se sont écoulées, ou exécutez le client dans un Web Worker ou comme processus Node.js afin que les minuteries ne soient pas bridées.

3

Surveiller le silence

Si vous ne recevez aucun message du serveur pendant plusieurs secondes, considérez le socket comme périmé et démontez-le plutôt que d'attendre qu'une lecture échoue.

Ajouter une logique de reconnexion pour 10054 et 502

1

Capturer la coupure

Gérez l'événement close/error du socket (y compris 10054 et 502) au lieu de laisser l'exception arrêter votre programme.

2

Réinstancier et réautoriser

À la déconnexion, ouvrez un nouveau socket et réexécutez le handshake d'autorisation complet, l'ancienne session ou l'ancien jeton peut être mort.

3

Temporiser exponentiellement avec jitter

Commencez autour d'une seconde et augmentez le délai jusqu'à un plafond raisonnable (des dizaines de secondes), en ajoutant un jitter aléatoire pour que les clients parallèles ne se reconnectent pas en cadence.

4

Plafonner et alerter

Limitez les tentatives et, si vous les épuisez, remontez une alerte plutôt que de boucler indéfiniment, c'est le signe d'une vraie panne ou d'un problème de limite de débit/session.

Tableau de dépannage

Erreur Signification Correctif
[WinError 10054] An existing connection was forcibly closed by the remote hostLe serveur a réinitialisé la connexion TCP/WebSocket, échec de handshake ou coupure transitoireFixer TLS 1.2+, puis capturer et se reconnecter avec backoff
SSL: TLSV1_ALERT_PROTOCOL_VERSIONLe serveur a rejeté la version de TLS proposée par votre clientForcer TLS 1.2/1.3 ; mettre à jour la pile cryptographique
SSL: SSLV3_ALERT_BAD_RECORD_MACEnregistrement TLS corrompu/non concordant issu d'une pile SSL héritéeMettre à niveau OpenSSL/runtime et négocier une version moderne de TLS
502 Bad GatewayIndisponibilité transitoire côté serveur lors du handshakeAttendre et réessayer avec un backoff exponentiel (côté serveur, pas votre bug)
Le socket se ferme après ~quelques secondes de calmeHeartbeats manqués, le serveur vous traite comme inactifEnvoyer un heartbeat [] toutes les ~2,5 secondes
Le socket meurt juste après une nouvelle connexion/un nouveau jetonLimite de sessions simultanées atteinte ; ancien jeton invalidéRegrouper les sessions ; se reconnecter et se réautoriser

Évitez cela avec PickMyTrade

Si vous préférez ne pas maintenir un client WebSocket artisanal, PickMyTrade se place entre TradingView et Tradovate et gère la connexion pour vous :

  • Connexion gérée et conforme TLS, le pont négocie un handshake TLS moderne et compatible, de sorte que les erreurs de version de protocole SSL et d'enregistrement corrompu n'atteignent jamais votre stratégie.
  • Heartbeats et reconnexion intégrés, les heartbeats et la reconnexion à backoff exponentiel sont gérés côté serveur, de sorte qu'un 10054 ou un 502 se répare tout seul au lieu d'arrêter votre automatisation.
  • Routage conscient des sessions, le flux d'ordres est espacé et séquencé pour que vous ne déclenchiez pas les limites de sessions simultanées ou de débit pendant les reconnexions.
  • Synchronisation multi-comptes, une fois la connexion rétablie, la même alerte est répliquée sur tous les comptes liés sans ordres en double ni manqués.

Laissez le pont gérer le socket

Fatigué de surveiller un socket brut ? Commencez votre essai gratuit de 7 jours, reliez vos alertes dès aujourd'hui et laissez le pont gérer TLS, les heartbeats et les reconnexions pour vous.

Commencez votre essai gratuit de 7 jours

Questions fréquentes

En général non. C'est un signal générique « nous avons coupé votre connexion » pour les connexions WebSocket de longue durée. Cela ne devient un problème que si vous ne vous reconnectez pas. Construisez une logique de capture et de reconnexion et un 10054 occasionnel devient un non-événement.

Les serveurs de Tradovate acceptent TLS v1.1 et supérieur. TLS 1.0 et 1.1 étant dépréciés dans toute l'industrie, négociez TLS 1.2 ou 1.3, tous deux sont acceptés et constituent la norme moderne.

Un 502 vient du serveur. Le handshake a atteint la périphérie de Tradovate mais un nœud en amont a été brièvement indisponible. Il n'y a rien à corriger côté client, attendez un instant et réessayez avec un backoff.

Environ toutes les 2,5 secondes. Le heartbeat est une trame dont le texte est [] (un tableau vide). Manquez la cadence et le serveur ferme le socket pour inactivité.

Vous avez probablement atteint la limite de sessions simultanées. Créer un nouveau jeton d'accès démarre une nouvelle session et invalide l'ancien jeton, de sorte que tout socket utilisant encore le jeton précédent est déconnecté. Réutilisez une seule session, ou reconnectez-vous et réautorisez-vous.

Une boucle sans délai martèle le point de terminaison et peut déclencher des limites de débit, aggravant la récupération. Ajoutez un backoff exponentiel avec jitter, plafonnez les tentatives et réexécutez le handshake d'autorisation complet à chaque essai.

Un socket coupé n'annule pas les ordres actifs côté Tradovate, mais vous perdez la visibilité en temps réel jusqu'à la reconnexion. Réconciliez toujours positions et ordres après une déconnexion avant d'envoyer de nouvelles entrées.

Oui. Un pont comme PickMyTrade maintient le handshake TLS, les heartbeats et la reconnexion pour vous : vous envoyez une simple alerte et ne touchez jamais au code de socket brut.

Ce guide est fourni à des fins exclusivement éducatives et informatives et ne constitue ni un conseil financier, ni un conseil en investissement, ni un conseil de trading. Le trading de contrats à terme et d'autres produits à effet de levier comporte un risque de perte important et ne convient pas à tous les investisseurs. PickMyTrade est une plateforme d'automatisation tierce indépendante et n'est ni affiliée à Tradovate, Inc., ni approuvée ou parrainée par cette dernière. « Tradovate » ainsi que tous les noms, logos et marques associés sont la propriété de leurs détenteurs respectifs. Les fonctionnalités et les étapes de la plateforme évoluent avec le temps ; vérifiez donc toujours la procédure en vigueur dans la plateforme et la documentation officielles de Tradovate avant d'agir.