WebSocket Online-Testtool

Online WebSocket-Verbindungstest, Nachrichten senden und empfangen Debugging-Tool

Getrennt

WebSocket URL

Unterprotokoll (optional, kommagetrennt)

Gesendet

Empfangen

Dauer

00:00

Nachrichten Gesamt

Nachrichtenprotokoll

Verbinden um Nachrichten zu senden und empfangen

Ctrl + Enter zum Senden

Was ist WebSocket?

Der WebSocket-Test verbindet sich mit einer WebSocket-Adresse und hilft zu prüfen, ob ein Echtzeitkanal geöffnet, Nachrichten gesendet und Antworten empfangen werden können. WebSockets werden für Chats, Live-Dashboards, Benachrichtigungen, Multiplayer-Funktionen, Marktdaten, Gerätekommunikation und andere dauerhafte bidirektionale Verbindungen genutzt. Das Werkzeug ist nützlich bei Entwicklung, Fehlersuche, Proxy-Konfiguration, TLS-Prüfung und dem Vergleich von ws:// und wss:// Endpunkten. Es ist jedoch kein Lasttest und keine vollständige Protokollanalyse. Authentifizierung, Subprotokolle, Heartbeats, Reconnect-Strategien, Nachrichtenformat und Serverlimits müssen im echten Client weiterhin geprüft werden. Auch Proxy-Header und Netzwerkpfade sollten bei Fehlern mitgeprüft werden. Für echte Fehlersuche sollte das Ergebnis mit Berechtigungen, Browserumgebung, Netzwerkpfad und Geräte-/Serverstatus kombiniert werden.

Verwendung

So verwenden Sie

Geben Sie die WebSocket-Serveradresse in das URL-Feld ein (ws:// oder wss://)
Optional: Subprotokolle eingeben, mehrere durch Kommas getrennt.
Klicken Sie auf 'Verbinden', um die WebSocket-Verbindung herzustellen
Geben Sie den Nachrichteninhalt in das Eingabefeld ein
Wählen Sie den Nachrichtentyp (Text oder JSON); JSON-Typ validiert das Format automatisch
Klicken Sie auf 'Senden' oder drücken Sie Strg + Enter, um die Nachricht zu senden
Sehen Sie gesendete und empfangene Nachrichten in der Nachrichtenliste an; klicken Sie zum Kopieren

Verbindungstipps

Verwenden Sie wss:// bei Tests von einer HTTPS-Seite; Browser blockieren oft unsichere ws://-Verbindungen von sicheren Ursprüngen.
Exportieren oder kopieren Sie wichtige Nachrichtenprotokolle, bevor Sie die Verbindung trennen, aktualisieren oder Endpunkte während des Debuggings wechseln.

Anwendungsfälle

Manuell mit WebSocket-Endpunkten verbindenGeben Sie eine ws://- oder wss://-URL ein, geben Sie optional kommagetrennte Subprotokolle an und öffnen Sie eine Browser-WebSocket-Verbindung. Es werden nur die von Ihnen eingegebenen URL und Subprotokolle verwendet; der Browser öffnet eine einzelne Verbindung zu diesem Endpunkt und kontaktiert nichts anderes. Die Statusleiste unterscheidet Getrennt, Verbinden, Verbunden und Fehlerzustände mit Close-Code-Details, sofern verfügbar.

Text- oder JSON-Nachrichten senden und prüfenVerfassen Sie Text- oder JSON-Nachrichten, validieren Sie JSON vor dem Senden im JSON-Modus und senden Sie mit Strg oder Command plus Enter. Gesendete und empfangene Nachrichten werden mit Zeitstempel, Bytegröße und JSON-Markierung bei Parsebarkeit versehen und nach Möglichkeit mit formatiertem JSON angezeigt, sodass ein frameweiser Abgleich mit Servererwartungen unkompliziert ist.

Ein WebSocket-Sitzungsprotokoll exportierenDas Nachrichtenprotokoll speichert bis zu 500 Einträge, verfolgt gesendete und empfangene Zählungen sowie Verbindungsdauer und kann als JSON-Datei exportiert werden. Einzelne Nachrichten können auch zum Debuggen von API-Gesprächen oder Echtzeit-Event-Streams kopiert werden, oder zusammen mit dem Close-Code und der Dauer an ein Ticket angehängt werden.

Subprotokoll-Verhandlung testenListen Sie kommagetrennte Subprotokolle (z. B. 'graphql-ws,soap,wamp') vor der Verbindung auf. Der Handshake wird den vom Server gewählten Wert im Sec-WebSocket-Protocol-Response-Header zurückgeben – der schnellste Weg zu prüfen, ob Client und Gateway übereinstimmen oder ob ein Proxy den angeforderten Wert entfernt. Wenn die Antwort fehlt, hat der Server die Anfrage als Plain WebSocket behandelt und Ihr Anwendungsparser wird typischerweise bei der ersten Nachricht fehlschlagen, weil die Rahmenbildung auf beiden Seiten nicht mehr übereinstimmt.

Heartbeats und Idle-Timeouts beobachtenLassen Sie die Verbindung ohne Datenverkehr offen und beobachten Sie unerwünschte Ping-Frames oder Auto-Close. Vergleichen Sie die Idle-Pause mit dem dokumentierten Heartbeat-Intervall des Servers, um zu bestätigen, dass die Keep-Alive-Einstellungen übereinstimmen, und erfassen Sie den Close-Code, um einen höflichen 1000 von abnormalen Trennungen wie 1006 unterscheiden zu können. In der Praxis beträgt NGINX' Standard proxy_read_timeout 60 Sekunden und viele Cloud-Load-Balancer werfen idle Sockets nach 60 bis 350 Sekunden raus – eine Verbindung, die kurz nach der Ein-Minuten-Marke schließt, ist fast immer ein Proxy-Schnitt, kein Server-Bug. Die Unterscheidung zwischen 1006 (abnormale Trennung, kein Close-Frame empfangen), 1001 (going away) und 1011 (Server-Fehler) zeigt Ihnen, ob Sie den Proxy-Betreiber oder das Anwendungsteam eskalieren sollten.

Technisches Prinzip

Das Kernstück des WebSocket-Protokolls ist der HTTP-Upgrade. Der Client sendet zunächst eine reguläre HTTP-GET-Anfrage, jedoch mit den Headern Upgrade: websocket und Connection: Upgrade sowie einem zufällig erzeugten Sec-WebSocket-Key. Nach Validierung dieser Header antwortet der Server mit 101 Switching Protocols, einschließlich des Sec-WebSocket-Accept-Werts, der aus dem SHA-1 des Keys konkateniert mit einer festen GUID besteht und dann Base64-kodiert wird. Nach der 101-Antwort schaltet die TCP-Verbindung von HTTP auf WebSocket um, und nachfolgende Daten werden als WebSocket-Frames übertragen. Ein WebSocket-Frame-Header umfasst mindestens 2 Bytes und enthält das FIN-Flag, den Opcode (0x1 Text, 0x2 Binär, 0x8 Schließen, 0x9 Ping, 0xA Pong) und die Nutzdatenlänge. Ping/Pong-Frames dienen der Herzschlagerkennung; die Browser-API sendet sie nicht automatisch, daher muss die Anwendungsschicht sie implementieren. wss:// entspricht HTTPS+WebSocket — es erfolgt zunächst ein TLS-Handshake und dann der WebSocket-Upgrade; ws:// ist unverschlüsselt, und der Browser verweigert ws://-Endpunkte auf HTTPS-Seiten, um Downgrade-Angriffe zu verhindern. Ein einzelner Frame ist standardmäßig auf etwa 1 MB begrenzt; längere Nachrichten werden auf mehrere Frames aufgeteilt.

Handshake: Der Client sendet einen HTTP-GET mit dem Header Upgrade: websocket, und der Server antwortet mit 101 Switching Protocols, um den erfolgreichen Upgrade zu signalisieren
Sec-WebSocket-Key ist eine 16-Byte-Base64-Zeichenkette, die vom Browser zufällig erzeugt wird; der Server konkateniert eine feste GUID, bildet den SHA-1 und verifiziert über Sec-WebSocket-Accept
Framing: Jeder Frame trägt einen Header von mindestens 2 Bytes mit FIN, Opcode (Text/Binär/Ping/Pong/Schließen) und der Nutzdatenlänge
ws:// ist unverschlüsselt, wss:// ist WebSocket über HTTPS; Browser verweigern ws:// auf HTTPS-Seiten, um Downgrade-Angriffe zu verhindern
Ping/Pong-Frames für Herzschläge: RFC 6455 erfordert einen Pong als Antwort auf jeden Ping; der Browser sendet keine Herzschläge automatisch, die Anwendung muss sie implementieren
Schließsequenz: Eine Seite sendet einen 0x8-Schließ-Frame mit einem Statuscode, die Gegenseite antwortet mit einem passenden Schließ-Frame, und erst dann wird die TCP-Verbindung tatsächlich freigegeben

Beispiele

Verbindung zu einem öffentlichen Echo-Service

wss://echo.websocket.org — 101 Switching Protocols Handshake erfolgreich, das Senden von "hello" gibt sofort "hello" zurück

Eigenen WebSocket-Service debuggen

wss://api.example.com/ws — Subprotokoll graphql-ws, Verbindung erfolgreich, Subscription-Nachrichten werden normal empfangen

Verbindungsabbruch reproduzieren

wss://api.example.com/ws — der Server schließt die Verbindung 30 Sekunden nach Aufbau aktiv, Close-Code 1006 (abnormaler Abbruch)

FAQ

Was macht der WebSocket-Tester?

Du kannst dich mit einem beliebigen ws://- oder wss://-Endpunkt verbinden, Nachrichten senden und empfangen sowie den Protokollaustausch inspizieren. Praktisch zum Testen von WebSocket-APIs, MQTT-over-WS-Brokern, Echtzeit-Game-Servern, Chat-Systemen und Aktien-Feeds während der Entwicklung.

Werden Nachrichten über eure Server geschickt?

Nein. Der Browser baut die WebSocket-Verbindung direkt zum Zielhost auf. Kein Vermittler, kein Logging auf unserer Seite. Der Zielhost sieht deine IP wie bei jedem anderen Client.

Warum verbindet er sich nicht mit meinem localhost-Endpunkt?

Mixed-Content-Regeln: Wird diese Seite über HTTPS ausgeliefert, blockieren Browser unsichere ws://-Verbindungen. Verwende wss:// für das Ziel oder lade diese Seite zum lokalen Testen über reines HTTP. Die Browser-Konsole zeigt dir den genauen Ablehnungsgrund.

Kann ich Binärdaten senden?

Ja. Die meisten Builds unterstützen Text- und Binär-Frames. Binäre Eingaben sind üblicherweise Base64 oder Hex; die Seite dekodiert vor dem Senden. Binäre Antworten werden standardmäßig in Hex oder Base64 angezeigt.

Wie füge ich eigene Header hinzu?

Die WebSocket-API des Browsers erlaubt keine eigenen Header - eine Web-Plattform-Einschränkung. Der einzige setzbare Header ist Sec-WebSocket-Protocol (das Subprotokoll). Für Bearer-Token-Auth nutze einen Query-Parameter oder eine Authentifizierung in der ersten Nachricht; manche Server akzeptieren auch ein Cookie.

Werden Kompression und Erweiterungen getestet?

Browser handeln per-message-deflate automatisch mit Servern aus, die es anbieten. Die Seite zeigt typischerweise die ausgehandelte Erweiterung an. Eigene Erweiterungen lassen sich nicht testen - so weit gibt der Browser die Kontrolle nicht her.

Warum bricht meine Verbindung ständig ab?

Häufige Ursachen: Idle-Timeout des Servers (oft 30-120 s), Timeout im Proxy oder Load-Balancer, Netzwerkstörungen oder ein schlafender Laptop. Moderne WebSockets brauchen Ping/Pong-Heartbeats; prüfe, ob der Server Pings sendet, oder lasse deinen Client regelmäßig Nachrichten schicken.