Reenvío WebSocket
Reenvío WebSocket crea sesiones reutilizables para probar endpoints WebSocket. Utilízalo para volver a conectar con los detalles del handshake capturado, editar mensajes, enviar tramas nuevas y observar las respuestas del servidor.
Crear una sesión
Puedes crear una sesión de Reenvío WebSocket de dos formas:
- Haz clic derecho en un mensaje WebSocket capturado en Historial WebSocket / SSE y elige Enviar a Reenvío WS.
- Abre Reenvío WS y crea una sesión manualmente con una URL
ws://owss://.
Las sesiones manuales pueden incluir cabeceras personalizadas para cookies, tokens de autorización, negociación de protocolo o valores de handshake específicos de la aplicación.
Configurar la sesión
| Campo | Descripción |
|---|---|
| Nombre | Etiqueta legible de la sesión. |
| URL | Endpoint WebSocket. La URL debe empezar por ws:// o wss://. |
| Cabeceras | Cabeceras de handshake opcionales enviadas al conectar. |
Si cambias la URL o las cabeceras, Ogma guarda la sesión antes de abrir la siguiente conexión.
Conectar
Selecciona una sesión y haz clic en Conectar. El estado de conexión muestra si el socket está desconectado, conectando, abierto, cerrando o cerrado.
Utiliza Desconectar antes de cambiar de objetivo o modificar los detalles del handshake. Vuelve a conectar después de editar la URL o las cabeceras para probar una ruta nueva del servidor o un contexto autenticado.
Conectar solo completa el handshake WebSocket. Muchas aplicaciones requieren después una trama de autenticación o inicialización antes de aceptar mensajes de negocio. Utiliza el primer mensaje del cliente capturado como referencia, espera su confirmación y solo entonces envía tu mensaje modificado. Las cookies, URL firmadas y tokens capturados pueden haber caducado.
Enviar mensajes
Utiliza el editor de mensajes para editar un payload y enviarlo a través de la sesión seleccionada. Los payloads de texto se envían como tramas de texto WebSocket.
Cambia al modo binario para bytes hexadecimales. Reenviar el primer mensaje WebSocket capturado ayuda a reenviar la inicialización, y Reenviar la secuencia saliente capturada envía los mensajes capturados del cliente en orden. Comprueba las respuestas en la cronología en lugar de asumir que enviar una secuencia recreó el estado de la aplicación.
El editor de protocolo admite los modos WebSocket sin procesar y GraphQL gestionado (graphql-transport-ws y el antiguo graphql-ws). Elige el protocolo utilizado por el objetivo y proporciona sus parámetros de conexión. Conserva la cabecera de subprotocolo original cuando sea necesaria; solicitar el protocolo equivocado puede hacer que falle la actualización de conexión.
Actualizar marcas de tiempo está desactivado de forma predeterminada. Actívalo solo para solicitudes sin firmar que necesiten marcas de tiempo nuevas: cambiar una URL o un payload firmado puede invalidar su firma. Reconexión automática vuelve a intentarlo tras una desconexión, pero una conexión nueva puede seguir necesitando autenticación a nivel de aplicación.
Los mensajes capturados enviados desde el historial conservan su payload original como punto de partida, para que puedas cambiar un campo cada vez y comparar el comportamiento.
Cronología de mensajes
La cronología registra las tramas enviadas y recibidas de la sesión seleccionada.
| Columna | Descripción |
|---|---|
| Dirección | Si la trama la envió el cliente o se recibió del servidor. |
| Opcode | Tipo de trama, como texto, binaria, ping, pong o cierre. |
| Tamaño | Tamaño del payload. |
| Hora | Cuándo observó Ogma la trama. |
Selecciona un mensaje para inspeccionar su payload. Los payloads JSON se formatean cuando es posible; el contenido sin procesar sigue disponible para una revisión exacta.
Flujo de pruebas
- Captura un flujo WebSocket normal en Historial WebSocket / SSE.
- Envía un mensaje interesante del cliente a Reenvío WS.
- Vuelve a conectar y reenvía el mensaje original para confirmar el comportamiento de referencia.
- Modifica un campo, token, ID o comando cada vez.
- Registra el comportamiento confirmado en Hallazgos o conserva apuntes en Notas.
Solución de problemas
| Síntoma | Qué comprobar |
|---|---|
| Actualización de conexión rechazada o prohibida | URL, Origin, cookies, autorización y valores firmados caducados en la consulta. |
| Subprotocolo no válido o no solicitado | Compara las cabeceras de actualización con el handshake capturado y el modo de protocolo seleccionado. |
| Conecta correctamente y después se cierra | Inspecciona el mensaje de sistema/cierre y envía la trama de inicialización o autenticación necesaria. |
| Mensaje enviado, pero sin respuesta útil | Confirma los ID de suscripción, mensajes previos, autenticación y estado de la aplicación; el transporte WebSocket no recrea automáticamente una sesión de navegador. |
Con MCP, utiliza las herramientas dedicadas de listado/lectura de mensajes de Reenvío WS y de desconexión. Las herramientas del historial capturado leen una transcripción diferente; consulta la referencia de herramientas MCP.