Caídas del WebSocket de Tradovate: heartbeats y límite de 24 h
Un socket de Tradovate que se desconecta constantemente casi siempre se debe a tres errores solucionables: heartbeats ausentes, ID de solicitud duplicados y mantener una conexión abierta más allá del límite de 24 horas. Aquí tiene cada causa y la solución exacta.
On This Page
- Qué significa «el WebSocket de Tradovate se desconecta constantemente»
- Principales causas de las caídas del WebSocket de Tradovate en 2026
- 1. Sin heartbeat (o uno tardío)
- 2. Las pestañas del navegador limitan su temporizador
- 3. ID de solicitud duplicados
- 4. Enviar solicitudes demasiado rápido
- 5. Alcanzar el límite de 24 horas o un token caducado
- Cómo solucionar las caídas del WebSocket de Tradovate: paso a paso
- Solución de los heartbeats ausentes
- Solución de la limitación de las pestañas del navegador
- Solución de los ID de solicitud duplicados
- Solución de las ráfagas de solicitudes y el límite de 24 horas
- Tabla de solución de problemas
- Evítelo con PickMyTrade
Si transmite cotizaciones en vivo de ES o NQ a una estrategia automatizada, un WebSocket de Tradovate que se desconecta en silencio puede dejar una posición sin gestionar durante minutos antes de que usted lo note. El socket en tiempo real de Tradovate no perdona. El servidor cierra una conexión inactiva en unos 10 segundos si deja de recibir noticias de su cliente, y una única conexión tiene una vida útil estricta que se mide en horas, no en días. Cuando un WebSocket de Tradovate se desconecta continuamente, casi siempre se reduce a tres errores solucionables, heartbeats ausentes, ID de solicitud duplicados y mantener una conexión más allá del límite de 24 horas, más un cuarto, saturar el socket con solicitudes. A continuación encontrará cada causa, la solución exacta y cómo enrutar sus alertas a través de PickMyTrade le evita por completo la gestión del socket en bruto.
Lista de verificación rápida para las caídas del WebSocket de Tradovate
- Envíe un heartbeat cada 2,5 segundos, una trama que contiene un array vacío
[], enviada desde el cliente, mantiene abierto el socket. - No confíe en setInterval en una pestaña del navegador, las pestañas en segundo plano limitan los temporizadores y dejan sin heartbeats a su conexión. Use una comprobación de marca de tiempo o un Web Worker.
- Dé a cada solicitud una i (ID de solicitud) única e incremental, nunca reutilice un ID entero en el mismo socket.
- Regule el ritmo de sus solicitudes, enviar demasiadas tramas demasiado rápido provoca una desconexión por parte del servidor.
- Reconecte antes de ~24 horas, un único WebSocket de Tradovate no está pensado para vivir indefinidamente, así que programe una reconexión limpia.
- Renueve el token de acceso antes de que caduque, un token caducado significa que su nueva autorización al reconectar falla.
Qué significa «el WebSocket de Tradovate se desconecta constantemente»
El protocolo WebSocket de Tradovate es conversador por diseño. Tras abrir el socket, el servidor envía una trama open (o), usted envía una trama authorize con su token de acceso y, a partir de ahí, se espera que ambas partes sigan comunicándose. Si el servidor no recibe nada de su cliente durante aproximadamente 10 segundos, asume que la conexión está muerta y la cierra. Por eso un socket que “funcionaba hace un segundo” se cae en el momento en que su código deja de enviar tramas.
Aquí está el detalle que sorprende a la mayoría de los desarrolladores: una vez que se suscribe a un feed de datos en vivo, el servidor deja de enviarle sus propias tramas de heartbeat porque los propios mensajes de streaming demuestran que el enlace está activo. Sin embargo, su cliente aún tiene que demostrar que él está activo. Si su feed de datos se queda en silencio, en una sesión nocturna lenta o con un símbolo poco negociado, y su cliente no envía sus propios heartbeats, el servidor cierra el socket aunque nada esté “mal”.
Además del tiempo de espera por inactividad, mantener una única conexión abierta durante más de 24 horas provoca desconexiones. Así que incluso un cliente perfectamente correcto que envía heartbeats acaba siendo desconectado si nunca reconecta. Comprender estos dos relojes, el temporizador de inactividad de ~10 segundos y el techo de conexión de ~24 horas, es la clave para un feed estable.
Principales causas de las caídas del WebSocket de Tradovate en 2026
1. Sin heartbeat (o uno tardío)
Esta es la causa número uno. Su cliente es responsable de enviar un heartbeat cada 2,5 segundos, una trama cuyo texto es exactamente [], para evitar que lo cierren por inactividad. Si pierde la ventana, el socket se cierra.
2. Las pestañas del navegador limitan su temporizador
Si su aplicación se ejecuta en un navegador y controla los heartbeats con setInterval o setTimeout, el navegador limita los temporizadores de una pestaña inactiva o en segundo plano. Sus heartbeats llegan tarde o se detienen por completo, y el socket muere “sin motivo” en cuanto cambia de pestaña.
3. ID de solicitud duplicados
Cada solicitud que envía lleva un ID entero en su campo i. Si envía dos solicitudes con el mismo i en el mismo socket, confunde la asociación entre solicitud y respuesta, lo que puede romper la conexión o dejarle esperando indefinidamente una respuesta que nunca se resuelve limpiamente.
4. Enviar solicitudes demasiado rápido
Si lanza una ráfaga de tramas al socket, por ejemplo suscribiéndose a docenas de símbolos en un bucle cerrado o martilleando modificaciones de órdenes, puede activar la protección contra saturación de Tradovate y provocar una desconexión.
5. Alcanzar el límite de 24 horas o un token caducado
Una conexión mantenida abierta más de unas 24 horas se cierra. Relacionado con esto: el token de acceso de su sesión caduca (los tokens de acceso de Tradovate son de corta duración, del orden de 90 minutos), así que si intenta volver a autorizar un socket reconectado con un token obsoleto, la autenticación falla y sigue desconectado.
Cómo solucionar las caídas del WebSocket de Tradovate: paso a paso
Solución de los heartbeats ausentes
Inicie una rutina de heartbeat tras autorizar
En cuanto su socket esté autorizado, inicie una rutina de heartbeat.
Envíe el array vacío con una cadencia de 2,5 s
Cada 2,5 segundos (2500 ms), envíe una trama que contenga un array vacío [] usando el método send estándar del WebSocket.
Siga enviando incluso durante el streaming
Siga enviando heartbeats incluso mientras recibe datos de mercado, no asuma que el silencio del servidor significa que el enlace está sano. Cuando fluyen datos en vivo, el servidor deja de enviar sus propios heartbeats, así que los suyos son lo único que mantiene abierto el socket durante los periodos tranquilos.
Trátelo como «enviar y olvidar»
Trate el heartbeat como «enviar y olvidar». No lleva ID de solicitud y no espera respuesta.
Solución de la limitación de las pestañas del navegador
Deje de depender solo de setInterval
Deje de depender únicamente de setInterval / setTimeout para los heartbeats en un navegador.
Use un enfoque basado en marcas de tiempo
Use en su lugar un enfoque basado en marcas de tiempo: en cada mensaje entrante, registre la hora actual y compárela con la hora del último heartbeat. Si han transcurrido más de 2500 ms, envíe una trama de heartbeat de inmediato.
Mueva el temporizador fuera del hilo principal
En aplicaciones que deben sobrevivir a largos periodos sin datos entrantes en una pestaña en segundo plano, mueva el temporizador a un Web Worker (que no se limita de la misma manera), o ejecute el socket en un proceso Node.js del lado del servidor, donde no existe el concepto de pestaña inactiva.
Solución de los ID de solicitud duplicados
Mantenga un único contador incremental
Mantenga un único contador estrictamente creciente para el campo i en cada socket.
Reserve los ID bajos para la configuración
Reserve los ID bajos que el protocolo usa para la configuración (la autorización y la solicitud de sincronización inicial) y haga que su contador general empiece por encima de ellos.
Incremente de forma atómica
Incremente el contador de forma atómica para que dos tareas asíncronas nunca obtengan el mismo valor. En código multihilo o muy concurrente, proteja el contador con un bloqueo, un closure o una estructura segura para hilos.
Nunca reutilice un ID al reintentar
Nunca escriba a mano el mismo ID dos veces. Si reintenta una solicitud, asigne al reintento un ID nuevo.
Solución de las ráfagas de solicitudes y el límite de 24 horas
Limite las tramas salientes
Ponga sus solicitudes en cola y libérelas a un ritmo constante en lugar de enviarlas en ráfagas. Espaciar las suscripciones y las acciones sobre órdenes le mantiene por debajo de la tolerancia del socket.
Programe una reconexión proactiva
No espere a la caída de ~24 horas. Reconecte con su propio calendario (bien dentro de las 24 horas), vuelva a enviar la trama authorize y vuelva a suscribirse a sus feeds para que el cambio sea fluido.
Renueve primero el token
Controle la caducidad de su token de acceso y renuévelo antes de que expire para que la nueva autorización al reconectar use siempre un token válido. Tradovate fija la duración exacta de los tokens y puede cambiar, consulte la documentación actual de la API en lugar de codificar un número fijo.
Recupérese automáticamente tras cada cierre inesperado
Trate cada cierre inesperado como un error y recupérese automáticamente. A menos que esté apagando de forma intencionada, vuelva a abrir el socket, vuelva a autorizar y vuelva a suscribirse automáticamente. Añada un tiempo de espera a las respuestas pendientes para que una solicitud atascada nunca bloquee a todo su cliente.
Tabla de solución de problemas
| Síntoma / error | Qué significa | Solución |
|---|---|---|
| El socket se cierra tras ~10 segundos de silencio | Sin heartbeat del cliente; el servidor cerró la conexión inactiva | Enviar un heartbeat con array vacío [] cada 2,5 s |
| El feed muere en cuanto la pestaña pasa a segundo plano | El navegador limitó setInterval / setTimeout | Usar heartbeats basados en marcas de tiempo o un Web Worker |
| Los datos en vivo se detienen pero el socket «parece» conectado | El servidor dejó de enviar sus propios heartbeats durante el streaming; el cliente no envió ninguno | Seguir enviando heartbeats del cliente incluso durante el streaming |
| Las respuestas no coinciden o las solicitudes se bloquean | Valores enteros i (ID de solicitud) duplicados | Usar un único contador de ID de solicitud atómico e incremental |
| La conexión se cae tras una ráfaga de tramas | Se enviaron demasiadas solicitudes demasiado rápido | Poner en cola y regular el ritmo de las solicitudes salientes |
| La conexión se cae alrededor de las 24 horas | Una única conexión mantenida más allá de su vida útil | Reconectar, volver a autorizar y volver a suscribirse bien dentro de las 24 h |
| La nueva autorización falla tras una reconexión | El token de acceso caducó | Renovar el token antes de que caduque y luego volver a enviar authorize |
Evítelo con PickMyTrade
Si está montando la automatización solo para hacer llegar órdenes a Tradovate, es posible que no necesite gestionar un WebSocket en bruto en absoluto. PickMyTrade toma sus alertas de TradingView y se las entrega a Tradovate por usted, de modo que el momento de los heartbeats, la higiene de los ID de solicitud y la lógica de reconexión quedan de nuestro lado:
- Salud de la conexión gestionada, la conexión con Tradovate se mantiene activa y se reconecta por usted, de modo que las interrupciones de heartbeat y el techo de 24 horas nunca llegan a su estrategia.
- Enrutamiento seguro frente a límites de tasa, las alertas se espacian y se ponen en cola para que una ráfaga de señales nunca sature el socket hasta provocar una desconexión.
- Gestión de tokens & sesión, la autenticación y la renovación se gestionan entre bastidores, de modo que un token caducado nunca mata silenciosamente su automatización.
- Sincronización multicuenta, una alerta se replica limpiamente en varias cuentas de Tradovate sin que tenga que manejar un socket por cuenta.
Opere sin rechazos
Comience su prueba gratuita de 7 días, vincule sus alertas hoy mismo y opere sin rechazos.
Comience su prueba gratuita de 7 díasPreguntas frecuentes
Cada 2,5 segundos. El cliente envía una trama que contiene un array vacío []. Si el servidor no recibe nada de su cliente durante aproximadamente 10 segundos, cierra el socket por inactividad.
Es simplemente el texto [], un array JSON vacío, enviado con el método send estándar del WebSocket. No tiene ID de solicitud y no espera respuesta.
Los navegadores limitan setInterval y setTimeout en las pestañas en segundo plano, por lo que los heartbeats controlados por temporizador llegan tarde y el socket agota el tiempo de espera. Use una comprobación de marca de tiempo en los mensajes entrantes, o mueva el temporizador a un Web Worker, para que los heartbeats sigan enviándose cuando la pestaña está inactiva.
Sí. Una vez que se suscribe a un feed de datos, el servidor deja de enviar sus propios heartbeats porque los mensajes de streaming demuestran que el enlace está activo, pero su cliente debe seguir demostrando que lo está. Durante los periodos tranquilos sin datos entrantes, sus heartbeats son lo único que mantiene abierto el socket.
Cada solicitud lleva un entero i, y las respuestas se asocian de vuelta a ese ID. Reutilizar un ID en el mismo socket confunde esa asociación y puede bloquear solicitudes o cortar la conexión. Use un único contador atómico que se incremente en cada solicitud.
Sí. Mantener una conexión abierta más de unas 24 horas provoca la desconexión. El patrón fiable consiste en reconectar con su propio calendario, bien dentro de las 24 horas, y luego volver a autorizar y a suscribirse, en lugar de esperar que un único socket viva para siempre.
Es probable que su token de acceso haya caducado. Los tokens de acceso de Tradovate son de corta duración, así que renueve el token antes de que expire y vuelva a enviar la trama authorize con un token válido en cada reconexión. Tradovate fija la duración exacta de los tokens y puede cambiar, así que confírmela en la documentación actual de la API.
Si su objetivo es simplemente automatizar órdenes de Tradovate desde TradingView, use un puente como PickMyTrade para que la salud de la conexión, el ritmo de envío y la gestión de tokens se encarguen por usted, en lugar de mantener usted mismo un socket en bruto.
Esta guía tiene fines exclusivamente educativos e informativos y no constituye asesoramiento financiero, de inversión ni de trading. Operar con futuros y otros productos apalancados conlleva un riesgo sustancial de pérdida y no es adecuado para todos los inversores. PickMyTrade es una plataforma de automatización independiente de terceros y no está afiliada, respaldada ni patrocinada por Tradovate, Inc. «Tradovate» y todos los nombres, logotipos y marcas relacionados son propiedad de sus respectivos titulares. Las funciones y los pasos de la plataforma cambian con el tiempo, por lo que debe confirmar siempre el proceso actual en la plataforma y la documentación oficiales de Tradovate antes de actuar.