Herramienta de Prueba WebSocket Online
Prueba de conexión WebSocket online, envío y recepción de mensajes herramienta de depuración
¿Qué es WebSocket?
La prueba WebSocket se conecta a una URL WebSocket y ayuda a comprobar si un canal en tiempo real puede abrirse, enviar mensajes y recibir respuestas. WebSockets se usan en chats, dashboards en vivo, notificaciones, funciones multijugador, datos de mercado, comunicación con dispositivos y otras conexiones bidireccionales persistentes. La herramienta sirve en desarrollo, diagnóstico, configuración de proxies, revisión TLS y comparación entre endpoints ws:// y wss://. No es una prueba de carga ni un analizador completo de protocolo. Autenticación, subprotocolos, heartbeats, reconexión, formato de mensajes, backpressure y límites del servidor deben probarse en el cliente y entorno reales. Una conexión exitosa solo demuestra que una ruta funciona en ese momento.
Cómo usar
Cómo usar
- Introduce la dirección del servidor WebSocket en el campo URL (ws:// o wss://)
- Opcional: introduce subprotocolos; si hay varios, sepáralos con comas
- Haz clic en 'Conectar' para establecer la conexión WebSocket
- Escribe el contenido del mensaje en el campo de entrada
- Selecciona el tipo de mensaje (Texto o JSON); el tipo JSON validará automáticamente el formato
- Haz clic en 'Enviar' o presiona Ctrl + Enter para enviar el mensaje
- Mira los mensajes enviados y recibidos en la lista; haz clic para copiar
Consejos de conexión
- Usa wss:// cuando pruebes desde una página HTTPS; los navegadores suelen bloquear conexiones inseguras ws:// desde orígenes seguros.
- Exporta o copia el historial de mensajes importantes antes de desconectar, actualizar la página o cambiar endpoints durante la depuración.
Casos de uso
Principio técnico
El núcleo del protocolo WebSocket es el HTTP Upgrade. El cliente primero envía una petición HTTP GET normal, pero con los encabezados Upgrade: websocket y Connection: Upgrade, además de un Sec-WebSocket-Key generado aleatoriamente. Tras validar estos encabezados, el servidor responde con 101 Switching Protocols, incluyendo el valor Sec-WebSocket-Accept, que es el SHA-1 de la Key concatenada con un GUID fijo y luego codificada en Base64. Después de la respuesta 101, la conexión TCP cambia de HTTP a WebSocket, y los datos posteriores se transmiten como tramas WebSocket. La cabecera de una trama WebSocket ocupa al menos 2 bytes, conteniendo el flag FIN, el opcode (0x1 texto, 0x2 binario, 0x8 cierre, 0x9 ping, 0xA pong) y la longitud de la carga útil. Las tramas ping/pong se usan para la detección de latido; la API del navegador no las envía automáticamente, por lo que la capa de aplicación debe implementarlas. wss:// es el equivalente a HTTPS+WebSocket, realizando primero un handshake TLS y luego la actualización WebSocket; ws:// es texto plano, y el navegador rechazará endpoints ws:// en páginas https para prevenir ataques de degradación. Una sola trama está limitada a aproximadamente 1 MB por defecto; los mensajes más largos se dividen en múltiples tramas.
- Handshake: el cliente envía un HTTP GET con el encabezado Upgrade: websocket, y el servidor devuelve 101 Switching Protocols para señalar una actualización exitosa
- Sec-WebSocket-Key es una cadena Base64 de 16 bytes generada aleatoriamente por el navegador; el servidor concatena un GUID fijo, calcula el SHA-1 y verifica mediante Sec-WebSocket-Accept
- Encuadre: cada trama lleva una cabecera de al menos 2 bytes, con FIN, opcode (texto/binario/ping/pong/cierre) y la longitud de la carga útil
- ws:// es texto plano, wss:// es WebSocket sobre HTTPS; los navegadores rechazan ws:// en sitios https para prevenir ataques de degradación
- Tramas ping/pong para latidos: RFC 6455 requiere un pong en respuesta a cada ping; el navegador no envía latidos automáticamente, la aplicación debe implementarlos
- Secuencia de cierre: cualquiera de los lados envía una trama de cierre 0x8 con un código de estado, el par responde con una trama de cierre correspondiente, y solo entonces la conexión TCP se libera realmente
Ejemplos
Conectar a un servicio Echo público
wss://echo.websocket.org — el handshake 101 Switching Protocols se completa, al enviar "hello" devuelve inmediatamente "hello"Depurar tu propio servicio WebSocket
wss://api.example.com/ws — subprotocolo graphql-ws, la conexión se establece, los mensajes de suscripción se reciben con normalidadReproducir una conexión caída
wss://api.example.com/ws — el servidor cierra activamente la conexión 30 segundos después de establecerse, código de cierre 1006 (cierre anormal)Preguntas frecuentes
¿Qué hace el tester de WebSocket?
Te permite conectarte a cualquier endpoint ws:// o wss://, enviar y recibir mensajes, e inspeccionar el intercambio del protocolo. Útil para probar API de WebSocket, brokers MQTT-sobre-WS, servidores de juegos en tiempo real, sistemas de chat y feeds de cotizaciones bursátiles durante el desarrollo.
¿Los mensajes pasan por vuestros servidores?
No. El navegador abre la conexión WebSocket directamente con el host destino. Sin intermediarios, sin registros por nuestra parte. El host destino ve tu IP igual que la de cualquier otro cliente.
¿Por qué no se conecta a mi endpoint en localhost?
Reglas de contenido mixto: si esta página se sirve por HTTPS, los navegadores bloquean conexiones ws:// (inseguras). Usa wss:// para el destino, o sirve esta página por HTTP plano para pruebas locales. La consola del navegador indica el motivo exacto del rechazo.
¿Puedo enviar datos binarios?
Sí. La mayoría de versiones admiten frames de texto y binarios. La entrada binaria suele ser Base64 o hex; la página la decodifica antes de enviar. La visualización de respuestas binarias usa hex o Base64 por defecto.
¿Cómo añado cabeceras personalizadas?
La API WebSocket del navegador no permite cabeceras personalizadas: es una restricción de la plataforma web. La única cabecera que puedes establecer es Sec-WebSocket-Protocol (el subprotocolo). Para autenticación con Bearer token usa un parámetro de query o autentica con el primer mensaje; algunos servidores aceptan una Cookie.
¿Probará la compresión y las extensiones?
Los navegadores negocian per-message-deflate automáticamente con los servidores que la anuncian. La página normalmente muestra la extensión negociada. Las extensiones personalizadas no se prueban: los navegadores no exponen ese nivel de control.
¿Por qué mi conexión se cae todo el tiempo?
Causas comunes: el timeout de inactividad del servidor (a menudo 30-120 s), timeout del proxy o balanceador, interrupción de red o que tu portátil entre en suspensión. Los WebSockets modernos necesitan heartbeats ping/pong; verifica que el servidor envíe pings, o haz que tu cliente envíe mensajes periódicos.