---
url: https://docs.ogmabox.com/it/app/ws-replay.md
description: >-
  Riconnettiti agli endpoint WebSocket, modifica i frame e invia di nuovo
  messaggi acquisiti in Ogma.
---

# Ripetizione WebSocket {#websocket-replay}

Ripetizione WebSocket crea sessioni riutilizzabili per testare gli endpoint WebSocket. Usala per riconnetterti con i dettagli dell'handshake acquisito, modificare messaggi, inviare nuovi frame e osservare le risposte del server.

## Creare una sessione {#creating-a-session}

Puoi creare una sessione di Ripetizione WebSocket in due modi:

* Fai clic con il pulsante destro su un messaggio WebSocket acquisito in **Cronologia WebSocket / SSE** e scegli **Invia a Ripetizione WS**.
* Apri **Ripetizione WS** e crea manualmente una sessione con un URL `ws://` o `wss://`.

Le sessioni manuali possono includere intestazioni personalizzate per cookie, token di autorizzazione, negoziazione del protocollo o valori di handshake specifici dell'applicazione.

## Configurare la sessione {#session-setup}

| Campo | Descrizione |
| --- | --- |
| Nome | Etichetta leggibile della sessione. |
| URL | Endpoint WebSocket. L'URL deve iniziare con `ws://` o `wss://`. |
| Intestazioni | Intestazioni facoltative dell'handshake inviate alla connessione. |

Se cambi l'URL o le intestazioni, Ogma salva la sessione prima di aprire la connessione successiva.

## Connettersi {#connecting}

Seleziona una sessione e fai clic su **Connetti**. Lo stato della connessione mostra se il socket è disconnesso, in connessione, aperto, in chiusura o chiuso.

Usa **Disconnetti** prima di cambiare target o dettagli dell'handshake. Riconnettiti dopo aver modificato l'URL o le intestazioni per testare un nuovo percorso del server o un contesto autenticato.

La connessione completa solo l'handshake WebSocket. Molte applicazioni richiedono poi un frame di autenticazione o inizializzazione prima di accettare messaggi applicativi. Usa il primo messaggio acquisito del client come riferimento, attendi la sua conferma e solo allora invia il messaggio modificato. I cookie, gli URL firmati e i token acquisiti potrebbero essere scaduti.

## Inviare messaggi {#sending-messages}

Usa l'editor dei messaggi per modificare un payload e inviarlo tramite la sessione selezionata. I payload di testo vengono inviati come frame di testo WebSocket.

Passa alla modalità binaria per byte esadecimali. **Ripeti primo messaggio WebSocket acquisito** aiuta a inviare di nuovo l'inizializzazione, e **Ripeti sequenza acquisita in uscita** invia in ordine i messaggi acquisiti del client. Controlla le risposte nella cronologia anziché presumere che l'invio di una sequenza abbia ricreato lo stato dell'applicazione.

L'editor del protocollo supporta le modalità WebSocket grezzo e GraphQL gestito (`graphql-transport-ws` e il precedente `graphql-ws`). Scegli il protocollo usato dal target e fornisci i suoi parametri di connessione. Conserva l'intestazione di sottoprotocollo originale quando richiesta; richiedere il protocollo sbagliato può far fallire l'upgrade.

**Aggiorna indicazioni temporali** è disattivo per impostazione predefinita. Attivalo solo per richieste non firmate che richiedono indicazioni temporali aggiornate: cambiare un URL o un payload firmato può invalidarne la firma. **Riconnessione automatica** riprova dopo una disconnessione, ma una nuova connessione può comunque richiedere autenticazione a livello applicativo.

I messaggi acquisiti inviati dalla cronologia mantengono il payload originale come punto di partenza, così puoi cambiare un campo alla volta e confrontare il comportamento.

## Cronologia dei messaggi {#message-timeline}

La cronologia registra i frame inviati e ricevuti per la sessione selezionata.

| Colonna | Descrizione |
| --- | --- |
| Direzione | Se il frame è stato inviato dal client o ricevuto dal server. |
| Opcode | Tipo di frame, come testo, binario, ping, pong o chiusura. |
| Dimensione | Dimensione del payload. |
| Ora | Quando Ogma ha osservato il frame. |

Seleziona un messaggio per ispezionare il payload. I payload JSON vengono formattati quando possibile; il contenuto grezzo resta disponibile per un esame esatto.

## Procedura di test {#testing-workflow}

1. Acquisisci un normale flusso WebSocket in **Cronologia WebSocket / SSE**.
2. Invia un messaggio interessante del client a **Ripetizione WS**.
3. Riconnettiti e invia di nuovo il messaggio originale per confermare il comportamento di riferimento.
4. Modifica un campo, token, ID o comando alla volta.
5. Registra il comportamento confermato in **Risultati** o conserva appunti in **Note**.

## Risoluzione dei problemi {#troubleshooting}

| Sintomo | Cosa controllare |
| --- | --- |
| Upgrade rifiutato o vietato | URL, Origin, cookie, autorizzazione e valori firmati scaduti nella query. |
| Sottoprotocollo non valido o non richiesto | Confronta le intestazioni di upgrade con l'handshake acquisito e la modalità di protocollo selezionata. |
| La connessione riesce, poi si chiude | Ispeziona il messaggio di sistema/chiusura e invia il frame di inizializzazione o autenticazione richiesto. |
| Messaggio inviato ma nessuna risposta utile | Conferma gli ID di sottoscrizione, i messaggi precedenti, l'autenticazione e lo stato dell'applicazione; il trasporto WebSocket non ricrea automaticamente una sessione di browser. |

Con MCP, usa gli strumenti dedicati di elenco/lettura dei messaggi di Ripetizione WS e di disconnessione. Gli strumenti della cronologia acquisita leggono una trascrizione diversa; consulta il [riferimento degli strumenti MCP](../reference/mcp-tools.md#websocket-and-sse).

## Pagine correlate {#related-pages}

* [Cronologia WebSocket e SSE](./ws-sse-history.md)
* [Ripetizione](./replay.md)
* [Risultati](./findings.md)