---
url: https://docs.ogmabox.com/pl/app/ws-replay.md
description: >-
  Łącz się ponownie z punktami końcowymi WebSocket, edytuj ramki i ponownie
  wysyłaj przechwycone wiadomości w Ogma.
---

# Ponowne wysyłanie WS {#websocket-replay}

Ponowne wysyłanie WS tworzy sesje wielokrotnego użytku do testowania punktów końcowych WebSocket. Używaj go, aby łączyć się ponownie z przechwyconymi szczegółami uzgadniania połączenia, edytować wiadomości, wysyłać nowe ramki i obserwować odpowiedzi serwera.

## Tworzenie sesji {#creating-a-session}

Sesję ponownego wysyłania WebSocket można utworzyć na dwa sposoby:

* Kliknij przechwyconą wiadomość WebSocket prawym przyciskiem myszy w panelu **Historia WS / SSE** i wybierz **Wyślij do panelu Ponowne wysyłanie WS**.
* Otwórz **Ponowne wysyłanie WS** i ręcznie utwórz sesję z adresem URL `ws://` lub `wss://`.

Sesje ręczne mogą zawierać niestandardowe nagłówki ciasteczek, tokenów autoryzacji, negocjacji protokołu lub wartości uzgadniania właściwych dla aplikacji.

## Konfiguracja sesji {#session-setup}

| Pole | Opis |
| --- | --- |
| Nazwa | Czytelna etykieta sesji. |
| URL | Punkt końcowy WebSocket. URL musi zaczynać się od `ws://` lub `wss://`. |
| Nagłówki | Opcjonalne nagłówki uzgadniania wysyłane podczas łączenia. |

Jeśli zmienisz URL lub nagłówki, Ogma zapisze sesję przed otwarciem następnego połączenia.

## Łączenie {#connecting}

Wybierz sesję i kliknij **Połącz**. Stan połączenia wskazuje, czy gniazdo jest rozłączone, łączy się, jest otwarte, zamyka się czy jest zamknięte.

Użyj **Rozłącz** przed zmianą celu lub szczegółów uzgadniania. Po edycji URL lub nagłówków połącz się ponownie, aby przetestować nową ścieżkę serwera lub kontekst uwierzytelnienia.

Połączenie kończy jedynie uzgadnianie WebSocket. Wiele aplikacji wymaga następnie ramki uwierzytelnienia lub inicjalizacji, zanim zaakceptuje wiadomości biznesowe. Użyj pierwszej przechwyconej wiadomości klienta jako punktu odniesienia, poczekaj na jej potwierdzenie i dopiero wtedy wyślij zmodyfikowaną wiadomość. Przechwycone ciasteczka, podpisane adresy URL i tokeny mogły wygasnąć.

## Wysyłanie wiadomości {#sending-messages}

Użyj edytora wiadomości, aby zmienić ładunek i wysłać go przez wybraną sesję. Ładunki tekstowe są wysyłane jako tekstowe ramki WebSocket.

Przełącz na tryb binarny dla bajtów w zapisie szesnastkowym. **Wyślij ponownie pierwszą przechwyconą wiadomość WebSocket** pomaga odtworzyć inicjalizację, a **Wyślij ponownie przechwyconą sekwencję wychodzącą** wysyła przechwycone wiadomości klienta po kolei. Sprawdzaj odpowiedzi na osi czasu, zamiast zakładać, że wysłanie sekwencji odtworzyło stan aplikacji.

Edytor protokołu obsługuje surowy WebSocket i zarządzane tryby GraphQL (`graphql-transport-ws` oraz starszy `graphql-ws`). Wybierz protokół używany przez cel i podaj jego parametry połączenia. Zachowaj oryginalny nagłówek podprotokołu, gdy jest wymagany; żądanie niewłaściwego protokołu może uniemożliwić zmianę protokołu połączenia.

**Aktualizuj znaczniki czasu** jest domyślnie wyłączone. Włącz je tylko dla niepodpisanych żądań wymagających aktualnych znaczników czasu: zmiana podpisanego URL lub ładunku może unieważnić podpis. **Automatyczne ponowne łączenie** ponawia próbę po rozłączeniu, ale nowe połączenie nadal może wymagać uwierzytelnienia na poziomie aplikacji.

Wiadomości przesłane z historii zachowują oryginalny ładunek jako punkt wyjścia, dzięki czemu można zmieniać jedno pole naraz i porównywać działanie.

## Oś czasu wiadomości {#message-timeline}

Oś czasu zapisuje wysłane i odebrane ramki wybranej sesji.

| Kolumna | Opis |
| --- | --- |
| Kierunek | Czy ramka została wysłana przez klienta, czy odebrana z serwera. |
| Kod operacji | Typ ramki, na przykład tekstowa, binarna, ping, pong lub zamknięcie. |
| Rozmiar | Rozmiar ładunku. |
| Czas | Kiedy Ogma zaobserwowała ramkę. |

Wybierz wiadomość, aby przeanalizować jej ładunek. Ładunki JSON są formatowane, gdy to możliwe; surowa zawartość pozostaje dostępna do dokładnego przeglądu.

## Przebieg testowania {#testing-workflow}

1. Przechwyć normalną komunikację WebSocket w panelu **Historia WS / SSE**.
2. Wyślij interesującą wiadomość klienta do panelu **Ponowne wysyłanie WS**.
3. Połącz się ponownie i wyślij oryginalną wiadomość, aby potwierdzić zachowanie bazowe.
4. Modyfikuj jedno pole, token, identyfikator lub polecenie naraz.
5. Zapisz potwierdzone zachowanie w panelu **Ustalenia** lub prowadź notatki w panelu **Notatki**.

## Rozwiązywanie problemów {#troubleshooting}

| Objaw | Co sprawdzić |
| --- | --- |
| Zmiana protokołu odrzucona lub zabroniona | URL, Origin, ciasteczka, autoryzację i wygasłe podpisane wartości zapytania. |
| Nieprawidłowy lub nieżądany podprotokół | Porównaj nagłówki zmiany protokołu z przechwyconym uzgadnianiem i wybranym trybem protokołu. |
| Połączenie udaje się, a potem zamyka | Sprawdź wiadomość systemową lub zamknięcia i wyślij wymaganą ramkę inicjalizacji lub uwierzytelnienia. |
| Wiadomość wysłana, ale brak użytecznej odpowiedzi | Potwierdź identyfikatory subskrypcji, wcześniejsze wiadomości, uwierzytelnienie i stan aplikacji; transport WebSocket nie odtwarza automatycznie sesji przeglądarki. |

W MCP używaj dedykowanych narzędzi listowania i odczytu wiadomości oraz rozłączania sesji ponownego wysyłania WS. Narzędzia przechwyconej historii odczytują inny zapis komunikacji; zobacz [dokumentację referencyjną narzędzi MCP](../reference/mcp-tools.md#websocket-and-sse).

## Powiązane strony {#related-pages}

* [Historia WS / SSE](./ws-sse-history.md)
* [Ponowne wysyłanie](./replay.md)
* [Ustalenia](./findings.md)