WebSocket de Tradovate «Connection to Remote Host Lost»

Cuando su bot transmite cotizaciones de ES o NQ las 24 horas, nada mata una estrategia más rápido que un WebSocket de Tradovate que muere en silencio con “Connection to remote host was lost.” Es uno de los dolores de cabeza más comunes de la API de Tradovate: el socket funciona sin problemas durante horas y luego se cae, muy a menudo justo en torno a las 24 horas, y arrastra consigo sus datos de mercado en vivo y el enrutamiento de órdenes. A veces lo verá como un cierre WebSocket en bruto (código 1006, “abnormal closure”). A veces parece una desconexión masiva. A veces es solo un feed muerto que nunca lanza una excepción.

No existe una única configuración mágica que lo arregle. Lo que de verdad mantiene vivo un socket es un conjunto de hábitos que funcionan juntos: heartbeats de 2,5 segundos, reconexión automática, renovación de token y ciclado de la conexión antes de que se quede obsoleta. PickMyTrade incorpora esta lógica de reconexión y reautorización, de modo que sus alertas de TradingView siguen llegando a Tradovate incluso cuando un socket hecho a mano se habría caído en silencio.

Qué significa «Connection to Remote Host Was Lost»

“Connection to remote host was lost” es la forma que tiene Tradovate de decirle que el WebSocket hacia sus servidores está cerrado y ya no se puede usar. Es un evento a nivel de transporte, no una orden rechazada ni una solicitud incorrecta. La tubería misma desapareció. Por debajo, esto suele aparecer como un cierre WebSocket anormal (código de cierre 1006), es decir, una conexión que se cayó sin un handshake de cierre limpio, de modo que su cliente no siempre puede decirle exactamente por qué.

Aquí está lo que confunde a la gente: perder la conexión es normal y esperable en un feed de larga duración. Las redes parpadean, los balanceadores de carga se reciclan, los sockets inactivos se podan, los tokens caducan y las sesiones muy largas se ciclan en el servidor. Incluso un cliente perfectamente bien portado que transmite datos en vivo puede perder el socket tras suficientes horas de actividad. Así que el objetivo no es un socket que nunca se caiga, eso es imposible. El objetivo es un cliente que note la caída al instante y se recupere solo, sin que tenga que vigilarlo.

Esa distinción importa para el riesgo. Si su feed muere en silencio y su código sigue asumiendo que está conectado, puede perder ejecuciones, perder disparos de stop o lanzar órdenes sobre una vista obsoleta del mercado. Trate cada WebSocket como desechable y cada desconexión como un evento rutinario que gestionar, no como una emergencia.

Principales causas de un WebSocket de Tradovate caído

1. Heartbeats perdidos (tiempo de espera de inactividad del servidor)

Esta es la causa más común con diferencia. El protocolo WebSocket de Tradovate exige que el cliente envíe un heartbeat cada 2,5 segundos, un frame cuyo texto es un array vacío, [], para demostrar que sigue vivo. Si el servidor pasa 2,5 segundos sin saber de usted y no le está transmitiendo datos activamente, trata al cliente como inactivo y cierra la conexión. Y aquí está el problema: mientras el servidor envía mensajes activamente (por ejemplo, una suscripción de datos de mercado muy activa), no enviará sus propios heartbeats, así que mantener fluyendo los frames [] depende por completo de su cliente.

2. Limitación del navegador / de los temporizadores

Si desarrolla en el navegador y programa los heartbeats con setInterval o setTimeout, cae en una trampa sutil: los navegadores limitan los temporizadores en pestañas en segundo plano o inactivas, estirando su intervalo de 2,5 segundos a varios segundos. En cuanto supera la ventana, el servidor cierra el socket. No se apoye en setInterval, calcule el momento de sus heartbeats a partir del último mensaje que realmente recibió.

3. Caducidad del token de acceso

Su WebSocket se autoriza una vez con un token de acceso, y ese token tiene una vida limitada, de alrededor de 90 minutos desde su creación según la documentación de la API de Tradovate. Cuando caduca el token tras una conexión activa, la conexión deja de estar autenticada y puede cortarse. Un cliente de larga ejecución que nunca renueva su token verá morir el socket con una cadencia predecible.

4. Conexiones de larga duración de más de ~24 horas

Mantener una conexión durante más de 24 horas es por sí mismo una causa reconocida de caídas. Incluso con heartbeats perfectos y un token nuevo, un socket que lleva abierto aproximadamente un día es un candidato principal para ser reciclado en el servidor. Por eso una conexión en bruto que “funcionó toda la tarde” muere misteriosamente durante la noche.

5. Tormentas de reconexión y el límite de sesiones

Cuando un socket se cae, el código ingenuo suele saturar al servidor con intentos de reconexión inmediatos y consecutivos. Eso puede activar los límites de tasa de solicitudes de Tradovate y empeorar las cosas, y reautenticarse repetidamente (en lugar de renovar) puede hacerle chocar con el tope de sesiones simultáneas. El resultado es un cliente atascado en un bucle de reconexión que nunca se estabiliza.

Cómo arreglar una conexión WebSocket de Tradovate perdida: paso a paso

Envíe un heartbeat cada 2,5 segundos, de la forma correcta

Este único hábito resuelve la mayoría de los informes de “connection to remote host was lost”, porque cumple directamente la regla de tiempo de espera de inactividad del servidor.

Añada lógica de reconexión automática y resuscripción

Renueve el token de acceso y reautorice el socket

Confirme que el acceso a la API está habilitado y que está dentro del límite de sesiones

Cicle la conexión de forma proactiva antes de las 24 horas

En lugar de esperar a que el servidor corte un socket de un día de antigüedad, adelántese. Con un temporizador, cómodamente por debajo del techo de ~24 horas, cierre limpiamente su WebSocket existente y abra uno nuevo con un token recién renovado, luego reautorice y vuelva a suscribirse. Como su ruta de reconexión ya existe (la construyó en el paso anterior), un ciclo programado es solo una versión controlada de la misma rutina. Convierte una desconexión sorpresa a las 3 de la madrugada en un refresco planificado e invisible.

Tabla de solución de problemas

Evite esto con PickMyTrade

Si su objetivo es simplemente que las alertas de TradingView lleguen a Tradovate de forma fiable, no tiene que construir ni vigilar usted mismo toda esta infraestructura de sockets. PickMyTrade se sitúa entre TradingView y Tradovate y mantiene sana la conexión por usted.

• Lógica de reconexión gestionada, reconexión, reautorización y resuscripción automáticas en cada caída, de modo que un socket perdido se recupera sin que tenga que escribir ni mantener el código.
• Renovación de token integrada, las sesiones se refrescan antes de caducar, manteniendo la conexión autenticada en lugar de morir con el reloj del token de ~90 minutos.
• Ciclado de conexión, las conexiones de larga duración se reciclan de forma proactiva, así que la caída de ~24 horas nunca sorprende a su automatización sin conexión.
• Enrutamiento seguro frente a límites de tasa, las reconexiones y el flujo de órdenes se espacian para respetar los límites de Tradovate, evitando los bloqueos por tormenta de reconexión que afectan a los sockets en bruto.