---
url: https://docs.ogmabox.com/de/app/ws-replay.md
description: >-
  Verbinde dich erneut mit WebSocket-Endpunkten, bearbeite Frames und sende
  aufgezeichnete Nachrichten in Ogma erneut.
---

# WS Replay {#websocket-replay}

WS Replay (WebSocket Replay) erstellt wiederverwendbare Sitzungen zum Testen von WebSocket-Endpunkten. Nutze es, um mit aufgezeichneten Handshake-Details erneut eine Verbindung herzustellen, Nachrichten zu bearbeiten, neue Frames zu senden und Serverantworten zu beobachten.

## Eine Sitzung erstellen {#creating-a-session}

Du kannst eine WebSocket-Replay-Sitzung auf zwei Arten erstellen:

* Klicke mit der rechten Maustaste auf eine aufgezeichnete WebSocket-Nachricht im **WS-/SSE-Verlauf** und wähle **An WS Replay senden**.
* Öffne **WS Replay** und erstelle manuell eine Sitzung mit einer `ws://`- oder `wss://`-URL.

Manuelle Sitzungen können eigene Header für Cookies, Autorisierungstokens, Protokollaushandlung oder anwendungsspezifische Handshake-Werte enthalten.

## Sitzung einrichten {#session-setup}

| Feld | Beschreibung |
| --- | --- |
| Name | Menschenlesbare Sitzungsbezeichnung. |
| URL | WebSocket-Endpunkt. Die URL muss mit `ws://` oder `wss://` beginnen. |
| Header | Optionale Handshake-Header, die beim Verbinden gesendet werden. |

Wenn du URL oder Header änderst, speichert Ogma die Sitzung vor dem Öffnen der nächsten Verbindung.

## Verbinden {#connecting}

Wähle eine Sitzung und klicke auf **Verbinden**. Der Verbindungszustand zeigt, ob der Socket getrennt ist, gerade eine Verbindung aufbaut, geöffnet ist, gerade geschlossen wird oder geschlossen ist.

Nutze **Trennen**, bevor du Ziele wechselst oder Handshake-Details änderst. Verbinde nach dem Bearbeiten von URL oder Headern erneut, um einen neuen Serverpfad oder authentifizierten Kontext zu testen.

Das Verbinden schließt nur den WebSocket-Handshake ab. Viele Anwendungen benötigen danach einen Authentifizierungs- oder Initialisierungsframe, bevor sie fachliche Nachrichten akzeptieren. Verwende die erste aufgezeichnete Client-Nachricht als Referenz, warte auf ihre Bestätigung und sende erst dann deine geänderte Nachricht. Aufgezeichnete Cookies, signierte URLs und Tokens können abgelaufen sein.

## Nachrichten senden {#sending-messages}

Bearbeite im Nachrichteneditor eine Payload und sende sie über die ausgewählte Sitzung. Text-Payloads werden als WebSocket-Textframes gesendet.

Wechsle für hexadezimale Bytes in den Binärmodus. **Erste erfasste WebSocket-Nachricht erneut senden** hilft beim Wiederholen der Initialisierung, und **Erfasste ausgehende Nachrichtenfolge erneut senden** sendet die aufgezeichneten Client-Nachrichten in ihrer Reihenfolge. Prüfe Antworten im Zeitverlauf, statt anzunehmen, dass das Senden einer Sequenz den Anwendungszustand wiederhergestellt hat.

Der Protokolleditor unterstützt den Modus Standard-WebSocket (Raw WebSocket) sowie verwaltete GraphQL-Modi (`graphql-transport-ws` und das ältere `graphql-ws`). Wähle das vom Ziel verwendete Protokoll und gib seine Verbindungsparameter an. Behalte den ursprünglichen Subprotokoll-Header bei, wenn er erforderlich ist; das Anfordern des falschen Protokolls kann das Upgrade scheitern lassen.

**Zeitstempel aktualisieren** ist standardmäßig ausgeschaltet. Aktiviere es nur für unsignierte Anfragen, die aktuelle Zeitstempel brauchen: Die Änderung einer signierten URL oder Payload kann ihre Signatur ungültig machen. **Automatisch neu verbinden** versucht nach einer Trennung erneut zu verbinden; eine neue Verbindung kann jedoch weiterhin Authentifizierung auf Anwendungsebene benötigen.

Aus dem Verlauf gesendete aufgezeichnete Nachrichten behalten ihre ursprüngliche Payload als Ausgangspunkt, sodass du jeweils ein Feld ändern und das Verhalten vergleichen kannst.

## Nachrichtenzeitverlauf {#message-timeline}

Der Zeitverlauf erfasst gesendete und empfangene Frames der ausgewählten Sitzung.

| Spalte | Beschreibung |
| --- | --- |
| Richtung | Ob der Frame vom Client gesendet oder vom Server empfangen wurde. |
| Opcode | Frame-Typ, etwa text, binary, ping, pong oder close. |
| Größe | Payload-Größe. |
| Zeit | Wann Ogma den Frame beobachtet hat. |

Wähle eine Nachricht, um ihre Payload zu untersuchen. JSON-Payloads werden nach Möglichkeit formatiert; Rohinhalte bleiben für die exakte Prüfung verfügbar.

## Testablauf {#testing-workflow}

1. Zeichne einen normalen WebSocket-Ablauf im **WS-/SSE-Verlauf** auf.
2. Sende eine interessante Client-Nachricht an **WS Replay**.
3. Verbinde erneut und sende die ursprüngliche Nachricht erneut, um das Referenzverhalten zu bestätigen.
4. Ändere jeweils ein Feld, einen Token, eine ID oder einen Befehl.
5. Dokumentiere bestätigtes Verhalten unter **Befunde** oder halte Notizen unter **Notizen** fest.

## Problemlösung {#troubleshooting}

| Symptom | Prüfen |
| --- | --- |
| Upgrade abgelehnt oder verboten | URL, Origin, Cookies, Autorisierung und abgelaufene signierte Query-Werte. |
| Ungültiges oder nicht angefordertes Subprotokoll | Vergleiche Upgrade-Header mit dem aufgezeichneten Handshake und dem ausgewählten Protokollmodus. |
| Verbindung gelingt, schließt danach aber | Untersuche die System-/Schließnachricht und sende den erforderlichen Initialisierungs- oder Authentifizierungsframe. |
| Nachricht gesendet, aber keine brauchbare Antwort | Prüfe Abonnement-IDs, vorherige Nachrichten, Authentifizierung und Anwendungszustand; der WebSocket-Transport stellt eine Browsersitzung nicht automatisch wieder her. |

Nutze mit MCP die speziellen WS-Replay-Tools zum Auflisten/Lesen von Nachrichten und zum Trennen. Tools für den aufgezeichneten Verlauf lesen ein anderes Transkript; siehe [MCP-Tool-Referenz](../reference/mcp-tools.md#websocket-and-sse).

## Verwandte Seiten {#related-pages}

* [WS-/SSE-Verlauf](./ws-sse-history.md)
* [Replay](./replay.md)
* [Befunde](./findings.md)