Skip to content

Tester WebSocket online (client ws/wss)

Testa un WebSocket dal browser: invia veri frame binari da HEX/Base64, leggi i messaggi binari in HEX, vedi i codici di chiusura con motivo e checklist. ws:// o wss://. I messaggi vanno dritti al tuo server, non al nostro.

Funziona nel browser Gratuito
Il tuo browser invia i messaggi direttamente al server che inserisci: non passano dai server di go-tools.
Inserisci: (servizio di eco di terze parti: la disponibilità non è garantita e i tuoi messaggi arrivano a quella terza parte)
Non connesso

I messaggi compaiono qui. Nessuna connessione WebSocket viene aperta finché non premi Connetti.

Invio temporizzato (heartbeat applicativo)
ms

Invia un normale messaggio di testo a intervalli regolari. Non è un frame di ping a livello di protocollo: le pagine web non possono né inviare né vedere i frame ping/pong. Disattivato per impostazione predefinita, perché un server che non se lo aspetta potrebbe chiudere la connessione.

Connessione, messaggi di testo e binari, codici di chiusura, handshake falliti, timeout di connessione, l'handshake Socket.IO, heartbeat, riconnessione e una raffica di 10.000 messaggi sono testati end-to-end contro un server WebSocket locale; il comportamento dei browser descritto in questa pagina è stato misurato in Chromium, Firefox e WebKit a ottobre 2026. — Team Go Tools · Oct 13, 2026

Realizzato e verificato dal team di ingegneria di Go Tools.

Tester WebSocket: risposte rapide

Questa pagina HTTPS può connettersi a ws://localhost?

Sì in Chrome, dopo aver consentito l'accesso alla rete locale Dipende dal browser (a ottobre 2026). A partire dalla versione 147, Chrome chiede prima se la pagina può accedere ai dispositivi della tua rete locale; dopo che hai scelto Consenti, ws://localhost e ws:// verso un indirizzo IP della LAN si connettono. Firefox si connette direttamente a localhost ma blocca gli indirizzi LAN. Safari blocca ws:// dalle pagine HTTPS.

Perché una connessione fallita riporta solo 1006?

Il browser nasconde il motivo Quando l'handshake fallisce, i browser sono tenuti a passare alla pagina solo un evento error e il codice di chiusura 1006, mai lo stato HTTP o il motivo. Premi F12: la console di Chrome e di Edge mostra il codice di stato restituito dal server.

Posso aggiungere un header Authorization?

I browser non possono impostare header No. L'API WebSocket del browser non permette di impostare header di richiesta. Metti il token in un parametro dell'URL, in un sottoprotocollo o in un cookie, a seconda di cosa accetta il tuo server.

L'heartbeat è un frame di ping?

È un messaggio normale No. Le pagine web non possono né inviare né vedere i frame ping/pong a livello di protocollo; ai ping del server risponde il browser da solo. L'invio temporizzato di questo strumento è un normale messaggio di testo inviato a intervalli, ed è disattivato per impostazione predefinita.

Perché non riesco a connettermi a un server Socket.IO?

Usa il preset Socket.IO Socket.IO non è un semplice WebSocket. Scegli il preset Socket.IO: si connette a /socket.io/?EIO=4&transport=websocket, risponde 40 al pacchetto di apertura e risponde a ogni ping 2 con pong 3 (Socket.IO v3/v4).

Che cos'è un tester WebSocket online?

Un tester WebSocket è un client che punti verso un server WebSocket per vedere se accetta la connessione e cosa rimanda indietro. Inserisci un indirizzo ws:// o wss://, ti connetti, invii messaggi di testo o binari e leggi le risposte: il modo più rapido per verificare un endpoint backend, un reverse proxy o un dispositivo che parla WebSocket senza scrivere codice client.

Questo tester gira nel tuo browser: la connessione va direttamente dal tuo browser al server che inserisci, e i messaggi non passano dai server di go-tools. Questo significa anche che ha i limiti del browser. Non può aggiungere header di richiesta personalizzati, non può inviare frame di ping a livello di protocollo e, quando un handshake fallisce, il browser comunica alla pagina solo il codice di chiusura 1006, non il motivo.

Cosa aggiunge rispetto alla semplice console del browser: messaggi binari mostrati in HEX (o Base64) e inviati da HEX o Base64 come veri frame binari, JSON formattato automaticamente, codici di chiusura spiegati, una checklist quando una connessione fallisce, un avviso prima di connettersi quando è probabile che il browser blocchi l'indirizzo e un log che resta reattivo con circa 2.000 messaggi al secondo (misurato).

09:30:01.204 · Connecting to ws://localhost:8080/ws
09:30:01.219 · Connected · subprotocol: chat
09:30:02.517 → TXT 17 B {"type":"hello"}
09:30:02.531 ← TXT 25 B {"type":"hello","ok":true}
09:30:03.002 → BIN 4 B 48 69 00 FF
09:30:03.010 ← BIN 4 B 48 69 00 FF
09:30:09.880 · Closed · code 4001: application-defined code

Funzioni del tester WebSocket

Localhost e LAN: indicazioni per ogni browser prima di connetterti

Prima della connessione lo strumento controlla l'indirizzo: un ws:// in chiaro verso un nome di dominio verrà bloccato da questa pagina HTTPS, quindi te lo dice e suggerisce wss://. Per localhost e gli indirizzi IP della LAN ti avvisa che Chrome chiederà l'accesso alla rete locale e spiega come si comportano invece Firefox e Safari (a ottobre 2026).

Messaggi binari in HEX, invii binari veri

I messaggi binari ricevuti sono mostrati in HEX, 16 byte per riga, oppure in Base64. Scrivi i byte come 48 69 00 FF, 0x48,0x69 o in Base64 e partono come messaggio binario; i caratteri non validi e un numero dispari di cifre vengono segnalati con la loro posizione, e l'anteprima dei byte mostra esattamente cosa verrà inviato.

Codici di chiusura ed errori su cui puoi agire

Ogni chiusura mostra il codice, il testo del motivo e se l'handshake di chiusura è stato completato, con il significato dei codici standard 1000–1015 e una nota per i codici applicativi 4000–4999. Un errore prima che la connessione si apra produce una checklist invece di un'ipotesi.

Log veloce con ricerca ed esportazione

I messaggi vengono disegnati una volta per fotogramma, così la pagina resta reattiva con circa 2.000 messaggi al secondo nei nostri test. Ogni voce ha direzione, timestamp al millisecondo, tipo e dimensione in byte. Filtra per direzione, cerca, metti in pausa la vista, conserva le ultime N voci, copia o esporta come testo.

Sottoprotocolli, timeout, preset Socket.IO

Richiedi uno o più sottoprotocolli (separati da virgole) e verifica se il server ne ha confermato uno. Un timeout di connessione chiude gli handshake a cui il server non risponde mai. Il preset Socket.IO completa l'handshake Engine.IO v4 e risponde ai ping al posto tuo.

Heartbeat e riconnessione solo se li attivi

L'invio temporizzato ripete a intervalli un messaggio a tua scelta, e la riconnessione automatica riprova con backoff esponenziale dopo un'interruzione imprevista. Entrambi sono disattivati per impostazione predefinita, e lo strumento non invia mai nulla che tu non abbia chiesto.

Esempi di test WebSocket: localhost, binario, codici di chiusura, Socket.IO

Testare un server di sviluppo locale

ws://localhost:8080/ws
Connesso
→ TXT 17 B {"type":"hello"}
← TXT 25 B {"type":"hello","ok":true}

In Chrome 147 e successivi il browser chiede prima se consentire l'accesso alla rete locale: scegli Consenti. Firefox si connette direttamente a localhost; Safari blocca ws:// da questa pagina HTTPS (a ottobre 2026).

Inviare un messaggio binario da HEX

48 69 00 FF
→ BIN 4 B 48 69 00 FF

In modalità HEX lo strumento invia un messaggio binario con questi quattro byte, non il testo 48 69 00 FF. Il Base64 SGkA/w== invia gli stessi quattro byte.

Leggere una chiusura del server

Il server chiude con codice 4001, motivo "token expired"
Chiuso · codice 4001: codice definito dall'applicazione · chiusura pulita
Motivo: token expired

I codici 4000–4999 sono definiti dall'applicazione, quindi cerca 4001 nella documentazione del server. I codici 1000–1015 sono standard e vengono spiegati nel log.

Connettersi a un server Socket.IO

Protocollo: Socket.IO v3/v4, indirizzo ws://localhost:3000
Connessione a ws://localhost:3000/socket.io/?EIO=4&transport=websocket
← 0{"sid":"…","pingInterval":25000,…}
→ 40
← 40{"sid":"…"}

Il preset completa il percorso e la query di Socket.IO, risponde 40 per entrare nel namespace predefinito e risponde a ogni ping 2 con 3. Invia gli eventi come 42["event","data"].

Come testare un WebSocket online

  1. 1

    Inserisci l'indirizzo del server

    Digita o incolla un indirizzo ws:// o wss://; http:// e https:// vengono trattati come ws:// e wss://. Leggi la nota sotto l'indirizzo: ti avvisa quando è probabile che il browser lo blocchi.

  2. 2

    Aggiungi i sottoprotocolli se il server li richiede

    Alcuni server richiedono un sottoprotocollo, per esempio mqtt. Inseriscine uno o più, separati da virgole. Dopo la connessione il log mostra quale ha confermato il server.

  3. 3

    Connettiti

    Fai clic su Connetti. Per localhost o un indirizzo LAN in Chrome, scegli Consenti quando ti viene chiesto l'accesso alla rete locale. Se la connessione non riesce, segui la checklist che compare.

  4. 4

    Invia e leggi i messaggi

    Scegli Testo, HEX o Base64, controlla l'anteprima e premi Ctrl+Invio. Il JSON ricevuto viene formattato e i dati binari sono mostrati in HEX; puoi passare a Base64 dalla barra degli strumenti del log.

  5. 5

    Filtra, poi copia o esporta

    Filtra per direzione o cerca nel log, metti in pausa la vista durante una raffica di messaggi, poi copia o esporta il log come testo con timestamp, direzione e dimensioni in byte.

Errori comuni nelle connessioni WebSocket

ws:// verso un nome di dominio da una pagina HTTPS

I browser bloccano un ws:// non cifrato verso un nome di dominio da una pagina caricata via HTTPS (contenuto misto). Chrome e Firefox rifiutano subito con un SecurityError. Usa wss://; per un server nella LAN, in Chrome scrivi il suo indirizzo IP (l'accesso alla rete locale deve essere consentito).

✗ Errato 
ws://api.example.com/ws
✓ Corretto 
wss://api.example.com/ws

HEX scritto in modalità testo

In modalità testo 48 69 viene inviato come i caratteri 4, 8, spazio, 6, 9. Passa a HEX per inviare i byte 0x48 0x69 come messaggio binario.

✗ Errato 
Modalità testo: 48 69 → TXT 5 B
✓ Corretto 
Modalità HEX: 48 69 → BIN 2 B

URL Socket.IO usato come WebSocket semplice

Un server Socket.IO rifiuta un WebSocket semplice sul percorso radice e, se nessuno risponde al suo handshake e ai suoi ping, chiude la connessione. Usa il preset Socket.IO.

✗ Errato 
ws://localhost:3000
✓ Corretto 
ws://localhost:3000/socket.io/?EIO=4&transport=websocket

Token in un header di richiesta

I browser non possono inviare un header Authorization con l'handshake WebSocket. Se il tuo server lo consente, passa il token come parametro dell'URL o come sottoprotocollo.

✗ Errato 
Authorization: Bearer eyJ…
✓ Corretto 
wss://api.example.com/ws?token=eyJ…

Quando serve un tester WebSocket online

Verificare un endpoint backend
Conferma che una nuova route WebSocket risponde, esamina i primi messaggi che invia e verifica come gestisce un input malformato, prima ancora che esista il frontend.
Fare debug di un reverse proxy
Dietro Nginx o un gateway, verifica se l'upgrade passa e quanto sopravvive una connessione inattiva.
IoT e protocolli binari
Dispositivi e broker che parlano binario su WebSocket possono essere letti in HEX e ricevere byte esatti inviati da HEX o Base64.
Riprodurre i codici di chiusura
Guarda il codice di chiusura e il motivo che il server invia davvero, per esempio quando un token scade o un client supera il limite di richieste.
Rendering con molti messaggi al secondo
Osserva un server che invia circa 2.000 messaggi al secondo (misurato) senza che la pagina si blocchi, con contatori di messaggi e byte.

Come funzionano le connessioni WebSocket nel browser

L'handshake di apertura
Un WebSocket nasce come richiesta HTTP con Upgrade: websocket. Gli header della richiesta li costruisce il browser: Origin, Sec-WebSocket-Key, Sec-WebSocket-Version: 13 e Sec-WebSocket-Protocol dall'elenco dei sottoprotocolli; la pagina non può aggiungerne altri. Il server risponde 101 Switching Protocols e da quel momento le due parti si scambiano messaggi.
Messaggi di testo e binari
send() con una stringa invia un messaggio di testo codificato in UTF-8; send() con dei byte invia un messaggio binario. Le pagine ricevono messaggi interi, mai frame, frammenti o maschere. Questo strumento imposta binaryType su arraybuffer, così i messaggi binari arrivano in ordine e possono essere mostrati in HEX.
Perché gli errori non hanno dettagli
Lo standard WebSocket vieta ai browser di dire agli script perché una connessione è fallita (errore DNS, porta rifiutata, errore di certificato o HTTP 401 appaiono tutti uguali), così una pagina non può sondare la tua rete locale. Le pagine vedono un evento error e il codice di chiusura 1006 (Firefox segnala gli errori di certificato come 1015).
Contenuto misto e accesso alla rete locale
Una pagina HTTPS non può aprire un ws:// non cifrato verso un host pubblico. Da Chrome 147 anche WebSocket rientra nel Local Network Access: per raggiungere localhost o un IP privato da una pagina pubblica serve il tuo permesso. Firefox esenta gli indirizzi di loopback, Safari no (a ottobre 2026).
Codici di chiusura
Un client può chiudere solo con 1000 o 3000–4999, e il motivo può essere al massimo di 123 byte in UTF-8. 1005 (nessun codice di stato) e 1006 (chiusura anomala) non viaggiano mai in rete: li riporta il browser. 1015 viene riportato per errori TLS solo da alcuni browser.

Consigli per testare i WebSocket

Usa wss:// fuori dalla tua macchina
Il wss:// cifrato con un certificato attendibile raggiunge i server pubblici da questa pagina in tutti i browser e protegge i token nell'URL; per localhost o gli indirizzi LAN, Chrome chiede comunque prima il permesso per la rete locale. Riserva il ws:// in chiaro a localhost.
Controlla la console quando l'handshake fallisce
La pagina vede solo 1006. Chrome ed Edge stampano lo stato HTTP nella console, che di solito indica subito un problema di autenticazione, di percorso o di proxy.
Consenti l'Origin sul server
I browser inviano sempre Origin. Se il tuo server lo controlla, consenti https://go-tools.org durante i test; gli header CORS non si applicano a WebSocket.
Lascia i ping al server
Per mantenere vive le connessioni inattive attraverso i proxy, fai inviare i frame di ping al server; il browser risponde automaticamente. Usa l'invio temporizzato solo se il tuo protocollo si aspetta un messaggio applicativo.
Tieni i token fuori dai log condivisi
Gli indirizzi contengono spesso dei token. Lo strumento conserva indirizzo e messaggi solo in memoria, ma i log esportati e gli screenshot li includono: rimuovi i segreti prima di condividerli.

Domande frequenti sul tester WebSocket

Posso testare ws://localhost o un server della LAN da questa pagina HTTPS?
Dipende dal browser (a ottobre 2026). A partire dalla versione 147, Chrome tratta le connessioni WebSocket verso il tuo computer o la tua rete locale come accesso alla rete locale: la prima volta chiede se consentirlo a questo sito e, dopo che hai scelto Consenti, ws://localhost, ws://127.0.0.1 e ws:// verso un indirizzo IP della LAN come 192.168.1.10 si connettono. In Chrome il server della LAN va scritto come indirizzo IP; un semplice nome host (diverso da .local) viene bloccato anche se si risolve nella tua rete. Firefox si connette direttamente a localhost ma blocca ws:// verso gli indirizzi LAN. Safari blocca ws:// verso localhost e la LAN dalle pagine HTTPS. wss:// non è soggetto alla regola del contenuto misto: i server pubblici funzionano da questa pagina in tutti i browser purché il certificato sia attendibile; per localhost o gli indirizzi LAN, anche qui Chrome chiede prima il permesso per la rete locale.
Perché non riesco a connettermi a ws://example.com da questa pagina?
Questa pagina è servita via HTTPS, e i browser bloccano una connessione ws:// non cifrata verso un host pubblico da una pagina HTTPS (contenuto misto). Chrome e Firefox rifiutano subito con un SecurityError, che lo strumento segnala. Usa l'indirizzo wss:// del server. I siti pubblici serviti in semplice http non hanno questa regola, ma nelle versioni recenti di Chrome non possono raggiungere affatto localhost o la tua LAN.
La connessione è fallita con codice 1006: cosa è andato storto?
1006 significa solo che la connessione si è chiusa senza handshake di chiusura. Quando un handshake fallisce, lo standard WebSocket impone al browser di nascondere la causa alla pagina (un 401, un 404, una porta rifiutata, un errore di certificato e un Origin respinto appaiono identici; Firefox segnala gli errori di certificato come 1015), quindi nessun tester web che si connette direttamente dal browser può mostrarla. Premi F12 e apri la Console: Chrome ed Edge stampano lo stato HTTP restituito dal server. Lo strumento distingue inoltre i fallimenti avvenuti prima dell'apertura della connessione dalle interruzioni successive, ed elenca le cause più comuni per ciascun caso.
Posso aggiungere un header Authorization o un altro header personalizzato?
No. L'API WebSocket del browser non permette alle pagine web di impostare header di richiesta; il browser invia un insieme fisso (compresi Origin e i cookie per il sito del server stesso). Le soluzioni più comuni, a seconda di cosa supporta il tuo server: un token nell'URL, come wss://host/ws?token=…; un token passato come sottoprotocollo (sono ammessi solo caratteri token, quindi un JWT funziona ma il Base64 standard con = o / no, e il server deve rimandare indietro il sottoprotocollo); oppure un cookie, che i browser inviano in modo affidabile solo al sito della pagina, quindi da questa pagina di solito non arriva al tuo server. Strumenti come Postman possono impostare header perché non sono browser.
Perché funziona in Postman ma non qui?
Postman e i client da riga di comando possono impostare qualsiasi header e di solito non inviano Origin. Un browser non può aggiungere un header Authorization e invia sempre Origin: https://go-tools.org. Se il server richiede un token nell'header o controlla Origin, rifiuta l'handshake del browser; consenti l'Origin o passa il token in un altro modo.
L'heartbeat invia frame di ping WebSocket?
No. Le pagine web non possono né inviare né vedere i frame ping/pong a livello di protocollo; quando il server invia un ping, il browser risponde da solo con un pong. L'invio temporizzato di questo strumento invia un normale messaggio di testo, come {"type":"ping"}, all'intervallo che imposti. È disattivato per impostazione predefinita perché un server che non si aspetta quel messaggio potrebbe chiudere la connessione. Per mantenere viva una connessione inattiva attraverso un proxy, fai inviare i ping al server.
Perché non riesco a connettermi al mio server Socket.IO?
Socket.IO è un protocollo costruito sopra WebSocket, non un semplice WebSocket. Un server Socket.IO v3/v4 si aspetta il percorso /socket.io/?EIO=4&transport=websocket, invia un pacchetto di apertura che inizia con 0, si aspetta 40 per entrare nel namespace predefinito e chiude la connessione se a ogni ping 2 non si risponde con pong 3. Scegli il preset Socket.IO e lo strumento fa tutto questo; poi invia gli eventi come 42["event","data"]. I server configurati solo per il long-polling HTTP non accettano affatto un WebSocket.
La connessione cade dopo circa un minuto: perché?
Di solito è un timeout di inattività in un reverse proxy. Per impostazione predefinita Nginx chiude una connessione inoltrata quando non passano dati per 60 secondi (proxy_read_timeout), e la pagina vede il codice 1006. Aumenta il timeout o fai inviare frame di ping al server. Dietro Nginx, assicurati anche che il proxy inoltri l'upgrade con proxy_set_header Upgrade $http_upgrade; e proxy_set_header Connection "upgrade"; (prima di Nginx 1.29.7 serve anche proxy_http_version 1.1;).
Come mi connetto a un server wss:// con certificato autofirmato?
Apri https://stesso-host:porta/ in una nuova scheda, accetta l'avviso sul certificato, poi torna qui e connettiti. Il browser ricorda l'eccezione per quell'host e quella porta. Fallo solo per i tuoi server di test, perché riduce la protezione del browser.
Come invio e leggo messaggi binari?
Scegli HEX o Base64 come formato di invio. HEX accetta 48 69 00 FF, 0x48,0x69 o 486900FF; l'anteprima mostra i byte, e i caratteri non validi o un numero dispari di cifre vengono segnalati con la loro posizione invece di essere inviati. I messaggi binari ricevuti sono mostrati in HEX, 16 byte per riga, e la barra degli strumenti del log li passa a Base64. Per leggere come testo l'HEX ricevuto, incollalo in Da Hex a Testo.
I miei messaggi passano dai server di go-tools?
No. Il tuo browser si connette direttamente all'indirizzo che inserisci, e i messaggi non passano dai nostri server. Inoltre lo strumento non apre alcuna connessione WebSocket finché non premi Connetti, e conserva indirizzo e messaggi solo in memoria, non nell'URL della pagina né nello storage del browser. Come il resto del sito, questa pagina carica script di analisi e pubblicità.
C'è un server su cui posso fare test?
Usa l'eco locale: gira dentro questa pagina, rimanda indietro tutto ciò che invii e non apre alcuna connessione di rete. Esistono anche servizi di eco pubblici come wss://echo.websocket.org/, ma sono di terze parti: la disponibilità non è garantita e i tuoi messaggi arrivano a quella terza parte.

Strumenti correlati

Vedi tutti gli strumenti →

Generatore e costruttore di comandi cURL

Web & API

Crea comandi curl nel browser — imposta metodo, intestazioni, autenticazione e corpo, ottieni subito il comando pronto da copiare. Preset per Bearer, POST JSON, upload file. Gratuito, privato, senza registrazione.

Generatore htpasswd — bcrypt, Apache MD5 (apr1) e Basic Auth

Web & API

Genera voci htpasswd con bcrypt, Apache MD5 (apr1), SHA-1 e altro. Ottieni configurazioni pronte per Apache, nginx e Docker. 100% nel browser — nessun caricamento.

Generatore di Meta Tag e Open Graph

Web & API

Genera meta tag Open Graph, Twitter Card e SEO con anteprima live per Google, Facebook e X. Gratis, nel browser, senza registrazione — copia e incolla.

Tester nginx location — perché vince quel blocco

Web & API

Scopri quale blocco location di nginx vince e perché gli altri perdono. Tester online gratuito per =, ^~, ~ e ~*, tutto dentro il browser.

Terminale seriale online (monitor seriale web)

Web & API

Monitor seriale in Chrome o Edge senza installazione: collega CH340, CP2102, ESP32 o Arduino, invia testo o HEX anche a intervalli, con CRC-16 Modbus automatico. Testo illeggibile? Rileva il GBK e ridisegna quanto già ricevuto.

Calcolatore di Sottoreti IPv4

Web & API

Calcola online indirizzo di rete, broadcast, host utilizzabili, netmask e wildcard di un blocco CIDR IPv4, divide in sottoreti, gestisce /31 (RFC 3021).