Il WebSocket di Tradovate si chiude esattamente dopo 5 minuti

Quando automatizza strumenti veloci come ES o NQ, poche cose bruciano più di un WebSocket di Tradovate che muore a tempo. Si connette, autorizza, si iscrive ai dati di mercato e tutto scorre benissimo, fino ai 300 secondi, quando il socket cade senza errore, senza motivo di chiusura, senza avviso. È la stessa storia ogni volta: la connessione si chiude esattamente a 5 minuti, anche quando i suoi heartbeat sembrano partire correttamente. Di solito si accompagnano due errori correlati, un'eccezione WebSocket is not open: readyState 0 (CONNECTING) quando il suo codice scrive su un socket semiaperto, e un semplice codice di chiusura 1006 (chiusura anomala) dal peer remoto. Ecco cosa significa davvero la chiusura a 5 minuti nel 2026, le vere cause alla base e lo schema esatto heartbeat più riconnessione che mantiene viva la connessione, oltre a come PickMyTrade gestisce questa infrastruttura per Lei, così che un socket caduto non le costi mai un fill.

Cosa significa «il WebSocket si chiude esattamente dopo 5 minuti»

L'API in tempo reale di Tradovate è una connessione WebSocket: la apre, invia un frame di autorizzazione, quindi si iscrive ai dati e agli eventi che le interessano. Per mantenere aperta la connessione, il client è responsabile dell'invio degli heartbeat, piccoli frame keep-alive, con una cadenza fissa. Se smette di inviarli, Tradovate considera il socket inattivo e lo chiude lato server.

Il motivo per cui l'errore cade così spesso sul preciso traguardo dei 5 minuti è che i timeout lungo il percorso di rete, il server, un load balancer o un proxy intermedio, tendono a essere applicati su cifre tonde. La connessione si interrompe esattamente ogni 5 minuti (300 secondi) senza alcun messaggio e, in modo rivelatore, senza heartbeat la caduta avviene invece dopo circa 2 minuti. Quindi gli heartbeat prolungano la vita del socket, ma un heartbeat in ritardo o mancato, o un timer di inattività indipendente da qualche parte sul percorso, può comunque ghigliottinarlo a 300 secondi. Non c'è una causa radice pubblicata per il caso esatto dei 5 minuti, quindi la risposta ingegneristica duratura non è prevenire ogni chiusura, ma sopravviverle.

I due messaggi di errore che vedrà sono sintomi dello stesso problema di fondo. WebSocket is not open: readyState 0 (CONNECTING) significa che il suo codice ha tentato un send() prima che l'handshake fosse completato, cosa comune in una funzione heartbeat che scatta a metà riconnessione. Il codice di chiusura 1006 è il modo in cui browser o libreria dicono “la connessione è caduta in modo anomalo”, senza handshake di chiusura pulito, esattamente ciò che ottiene quando un timer di inattività lato server taglia la linea.

Principali cause della chiusura del WebSocket a 5 minuti nel 2026

1. Frame heartbeat in ritardo o del tutto mancanti

È la causa numero uno. Tradovate si aspetta un frame heartbeat, con contenuto testuale [], circa ogni 2,5 secondi per dimostrare che il client è vivo. Se manca quella finestra, il server avvia il conto alla rovescia per la chiusura. E qui sta il problema: una volta che inizia a trasmettere quotazioni in tempo reale, il server di Tradovate smette di inviare i propri heartbeat, quindi non può contare sul traffico integrato della connessione per mantenerla aperta. Il suo client deve inviare il frame di parentesi vuote secondo un proprio programma.

2. Limitazione dei timer del browser (setInterval / setTimeout)

Se pianifica gli heartbeat con setInterval() o setTimeout() in un browser, è alla mercé della priorità della scheda. Quando la scheda perde il focus, Chrome (e la maggior parte dei browser) abbassa la priorità di quei timer, così un intervallo di “2,5 secondi” può dilatarsi silenziosamente fino a diversi secondi. L'heartbeat supera la scadenza e il socket si chiude, spesso intorno ai 5 minuti, quando si è accumulato abbastanza ritardo.

3. Timeout di inattività o di sessione lato server

Nemmeno un heartbeat perfettamente cadenzato può annullare un timeout applicato a monte. Un proxy, un gateway o la stessa sessione di Tradovate possono limitare il tempo di inattività o la durata totale della connessione, ed è per questo che la chiusura cade su quel sospetto confine tondo di 300 secondi. Poiché ciò è fuori dal suo controllo, la soluzione è la riconnessione, non la prevenzione.

4. Invio su un socket che non è OPEN (readyState 0)

Un WebSocket ha quattro stati: CONNECTING (0), OPEN (1), CLOSING (2) e CLOSED (3). Se il suo ciclo heartbeat o il codice degli ordini chiama send() mentre il socket è ancora a readyState 0, ottiene WebSocket is not open: readyState 0 (CONNECTING) e, spesso, subito dietro un messaggio “Disconnected from Tradovate Market WebSocket”. Colpisce più duramente nell'istante successivo a una caduta, quando la sua riconnessione ha avviato un nuovo socket che non ha ancora completato l'handshake.

5. Scadenza del token e connessioni di lunga durata

Un token di accesso di Tradovate ha una durata limitata e queste connessioni non sono pensate per vivere in eterno; se mantiene un singolo socket aperto per periodi molto lunghi (oltre un giorno), tende a cadere. Se il token scade a metà sessione o la connessione invecchia, il socket si chiude e qualsiasi riautorizzazione con il vecchio token fallisce. La durata dei token varia e cambia nel tempo, quindi verifichi i valori attuali nella documentazione API di Tradovate e rinnovi in modo proattivo invece di aspettare un errore.

Come risolvere la chiusura del WebSocket a 5 minuti: passo dopo passo

Soluzione 1: inviare un frame heartbeat circa ogni 2,5 secondi

L'heartbeat è la base. Con una cadenza di circa 2,5 secondi, invii un frame il cui testo è un array JSON vuoto:

Soluzione 2: sostituire setInterval con un controllo del timestamp o un Web Worker

Poiché i timer del browser vengono limitati, non si affidi solo a setInterval, né in una scheda in primo piano né in background. Due alternative collaudate:

• Heartbeat guidati dal timestamp. Registri un timestamp (new Date()) ogni volta che riceve un messaggio. Lo confronti con l'ultima volta che ha inviato un heartbeat; se sono trascorsi più di 2500 ms, invii [] subito. Questo reagisce al traffico reale invece che a un timer che il browser può mettere a digiuno.
• Sposti il timer fuori dal thread principale. Esegua l'heartbeat all'interno di un Web Worker, oppure esegua l'intera connessione come servizio Node.js. Entrambi aggirano del tutto la limitazione delle schede del browser, un processo Node non è affatto soggetto alla penalità delle schede in background.

Soluzione 3: proteggere ogni invio con un controllo di readyState

Elimini l'errore readyState 0 non scrivendo mai su un socket che non è aperto:

Soluzione 4: aggiungere logica di riconnessione, riautorizzazione e nuova iscrizione

Poiché alcune chiusure a 5 minuti sono imposte a monte e non possono essere prevenute, tratti ogni caduta come un errore recuperabile e ricostruisca automaticamente:

Tabella di risoluzione dei problemi

Lo prevenga con PickMyTrade

PickMyTrade si colloca tra i suoi alert di TradingView e Tradovate e gestisce il livello WebSocket come servizio gestito lato server, così la chiusura a 5 minuti viene trattata prima ancora di raggiungerla:

• Heartbeat gestiti, invia il frame keep-alive con una cadenza affidabile lato server, senza alcuna scheda del browser che limiti il timer.
• Auto-Reconnect & Re-Auth, rileva un socket caduto, ne apre uno nuovo, riautorizza con un token valido e si iscrive di nuovo automaticamente.
• Protezioni sullo stato della connessione, trasmette solo quando il socket è davvero aperto, eliminando gli errori di invio con readyState 0.
• Multi-Account Sync, mantiene sano il flusso di ogni conto collegato così che una singola riconnessione non lasci mai indietro un conto.