Ferramenta de Teste WebSocket Online
Teste de conexão WebSocket online, envio e recebimento de mensagens ferramenta de depuração
O que é WebSocket?
O teste WebSocket conecta a uma URL WebSocket e ajuda a verificar se um canal em tempo real consegue abrir, enviar mensagens e receber respostas. WebSockets são usados em chats, dashboards ao vivo, notificações, recursos multiplayer, dados de mercado, comunicação com dispositivos e outras conexões bidirecionais persistentes. A ferramenta é útil em desenvolvimento, diagnóstico, configuração de proxy, checagem TLS e comparação entre endpoints ws:// e wss://. Ela não é teste de carga nem analisador completo de protocolo. Autenticação, subprotocolos, heartbeats, reconexão, formato de mensagens, backpressure e limites do servidor ainda precisam ser testados no cliente e ambiente reais.
Como Usar
Como usar
- Insira o endereço do servidor WebSocket no campo URL (ws:// ou wss://)
- Opcional: insira subprotocolos, separados por vírgula quando forem vários
- Clique em 'Connect' para estabelecer a conexão WebSocket
- Insira o conteúdo da mensagem no campo de entrada
- Selecione o tipo de mensagem (Text ou JSON); o tipo JSON valida o formato automaticamente
- Clique em 'Send' ou pressione Ctrl + Enter para enviar a mensagem
- Visualize as mensagens enviadas e recebidas na lista e clique para copiar
Dicas de Conexão
- Use wss:// ao testar em uma página HTTPS; os navegadores costumam bloquear conexões ws:// inseguras a partir de origens seguras.
- Exporte ou copie os logs de mensagens importantes antes de desconectar, atualizar a página ou trocar de endpoint durante a depuração.
Casos de uso
Princípio técnico
O núcleo do protocolo WebSocket é o HTTP Upgrade. O cliente primeiro envia uma requisição HTTP GET comum, mas com os cabeçalhos Upgrade: websocket e Connection: Upgrade, além de um Sec-WebSocket-Key gerado aleatoriamente. Após validar esses cabeçalhos, o servidor responde com 101 Switching Protocols, incluindo o valor Sec-WebSocket-Accept, que é o SHA-1 da Key concatenada com um GUID fixo e depois codificado em Base64. Após a resposta 101, a conexão TCP muda de HTTP para WebSocket, e os dados subsequentes são transmitidos como frames WebSocket. O cabeçalho de um frame WebSocket tem pelo menos 2 bytes, contendo a flag FIN, o opcode (0x1 texto, 0x2 binário, 0x8 fechar, 0x9 ping, 0xA pong) e o tamanho do payload. Os frames ping/pong são usados para detecção de heartbeat; a API do navegador não os envia automaticamente, então a camada de aplicação deve implementá-los. wss:// equivale a HTTPS+WebSocket, fazendo primeiro o handshake TLS e depois o upgrade WebSocket; ws:// é texto puro, e o navegador recusa endpoints ws:// em páginas https para prevenir ataques de downgrade. Um único frame é limitado a cerca de 1MB por padrão; mensagens maiores são divididas em múltiplos frames.
- Handshake: o cliente envia um HTTP GET com o cabeçalho Upgrade: websocket, e o servidor retorna 101 Switching Protocols para sinalizar uma atualização bem-sucedida
- Sec-WebSocket-Key é uma string Base64 de 16 bytes gerada aleatoriamente pelo navegador; o servidor concatena um GUID fixo, calcula o SHA-1 e verifica via Sec-WebSocket-Accept
- Framing: cada frame carrega um cabeçalho de pelo menos 2 bytes, com FIN, opcode (texto/binário/ping/pong/fechar) e o tamanho do payload
- ws:// é texto puro, wss:// é WebSocket sobre HTTPS; navegadores recusam ws:// em sites https para prevenir ataques de downgrade
- Frames ping/pong para heartbeats: a RFC 6455 exige um pong em resposta a cada ping; o navegador não envia heartbeats automaticamente, a aplicação deve implementá-los
- Sequência de fechamento: qualquer lado envia um frame de fechamento 0x8 com um código de status, o peer responde com um frame de fechamento correspondente, e só então a conexão TCP é efetivamente liberada
Exemplos
Conectar a um serviço Echo público
wss://echo.websocket.org — handshake 101 Switching Protocols bem-sucedido, ao enviar "hello" recebe imediatamente "hello" de voltaDepurar seu próprio serviço WebSocket
wss://api.example.com/ws — subprotocolo graphql-ws, conexão bem-sucedida, mensagens de assinatura recebidas normalmenteReproduzir uma conexão interrompida
wss://api.example.com/ws — o servidor encerra ativamente a conexão 30 segundos após o estabelecimento, código de fechamento 1006 (encerramento anormal)Perguntas frequentes
O que o testador de WebSocket faz?
Permite que você se conecte a qualquer endpoint ws:// ou wss://, envie e receba mensagens e inspecione a troca de protocolo. Útil para testar APIs WebSocket, brokers MQTT-sobre-WS, servidores de jogos em tempo real, sistemas de chat e feeds de cotações de ações durante o desenvolvimento.
As mensagens passam pelos seus servidores?
Não. O navegador abre a conexão WebSocket diretamente com o host de destino. Sem intermediário, sem registro do nosso lado. O host de destino vê seu IP como qualquer outro cliente.
Por que não consigo conectar no meu endpoint localhost?
Regras de conteúdo misto: se esta página é servida por HTTPS, os navegadores bloqueiam conexões ws:// (inseguras). Use wss:// no destino, ou rode esta página em HTTP comum para testes locais. O console do navegador mostra o motivo exato da rejeição.
Posso enviar dados binários?
Sim. A maioria das builds suporta frames de texto e binários. A entrada binária geralmente é Base64 ou hex; a página decodifica antes de enviar. A exibição de respostas binárias usa hex ou Base64 por padrão.
Como adiciono cabeçalhos personalizados?
A API WebSocket do navegador não permite cabeçalhos personalizados — é uma restrição da Web Platform. O único cabeçalho que você pode definir é Sec-WebSocket-Protocol (o subprotocolo). Para autenticação Bearer token, use um parâmetro de query ou autenticação na primeira mensagem; alguns servidores aceitam um Cookie.
Ele testa compressão e extensões?
Os navegadores negociam per-message-deflate automaticamente com servidores que o anunciam. A página geralmente mostra a extensão negociada. Extensões personalizadas não são testadas — os navegadores não expõem esse nível de controle.
Por que minha conexão fica caindo?
Causas comuns: timeout de inatividade do servidor (geralmente 30-120 s), timeout de proxy/load balancer, interrupção de rede ou seu notebook entrando em modo de suspensão. WebSockets modernos precisam de heartbeats ping/pong; verifique se o servidor está enviando pings, ou faça seu cliente enviar mensagens periódicas.