Probador / cliente WebSocket

Conéctese a cualquier endpoint ws:// o wss://, declare subprotocolos opcionales, envíe mensajes de texto o JSON y siga un registro completo del ciclo de vida: transiciones de estado de preparación, códigos y motivos de cierre, y cada mensaje con su dirección, hora y contenido. Todo se ejecuta localmente en su navegador con la API WebSocket nativa — nada pasa por un servidor. Para API HTTP normales use el Cliente / probador de API REST; vea toda la familia de Herramientas de API.
Conexión
CERRADO Enviar un JSON de bienvenida al conectar
Enviar mensaje
Registro de mensajes 0 eventos
Todavía nada. Conéctese a un servidor para empezar.
Limitaciones de WebSocket en el navegador que conviene conocer: no se pueden personalizar las cabeceras de la petición (solo se envían las cookies y el subprotocolo Sec-WebSocket-Protocol indicado arriba); el handshake no se rige por CORS, pero la directiva connect-src de Content-Security-Policy de la página puede bloquearlo; una página segura (https) solo puede abrir wss://; JavaScript no puede enviar tramas ping a nivel de protocolo (el navegador responde a los ping del servidor automáticamente — use mensajes a nivel de aplicación como {"type":"ping"} para simular latidos); los certificados autofirmados no son de confianza. Para pruebas locales se recomienda ejecutar su propio servidor, o usar un eco público como wss://ws.postman-echo.com/raw o wss://echo.websocket.org.
WebSocket explicado
Un WebSocket le ofrece un canal de mensajes persistente y bidireccional entre el navegador y un servidor. A diferencia de HTTP, los mensajes pueden viajar en ambos sentidos por una única conexión.
ws:// frente a wss://—ws://no está cifrado (comohttp://); wss://está cifrado (comohttps://). Si esta página se sirve por HTTPS, el navegador solo permitewss://conexiones. Desde un archivo local (file://) se permiten ambos esquemas, pero muchos servidores de eco públicos (incluido echo.websocket.org) solo aceptanwss://.
Subprotocolos — la lista opcional separada por comas se corresponde con la cabecera de handshake Sec-WebSocket-Protocol. El servidor debe admitir uno de ellos; si no, el navegador rechaza la conexión.
¿Por qué termina Conectar pero no aparece el cuadro «Enviar mensaje»? El formulario de envío solo aparece cuando el estado pasa a OPEN. Si el servidor rechaza el handshake, verá un evento de error seguido de CLOSED con código 1006 (cierre anormal — sin trama de cierre). Causas típicas: usar ws:// contra un servidor que solo acepta wss://, un host o puerto erróneo, un desajuste de subprotocolo, o que el servidor esté fuera de línea.
Códigos de cierre que puede ver — 1000 normal; 1001 cierre de la pestaña del navegador; 1006 anormal / fallo del handshake; 1009 mensaje demasiado grande; 1011 error del servidor. El registro muestra automáticamente el código y un motivo breve.
Solución de problemas de una conexión fallida: primero cambie el esquema a wss://, asegúrese de que el host es accesible, quite los subprotocolos que no necesite y revise la consola del navegador por errores de TLS o de contenido mixto.