ToolAct

WebSocket Online-Testtool

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

Getrennt
Gesendet
0
Empfangen
0
Dauer
00:00
Nachrichten Gesamt
0

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 verwende

  1. Gib die WebSocket-Serveradresse in das URL-Feld ein (ws:// oder wss://)
  2. Optional: Subprotokolle eingeben, mehrere durch Kommas getrennt.
  3. Klicke auf 'Verbinden', um die WebSocket-Verbindung herzustellen
  4. Gib den Nachrichteninhalt in das Eingabefeld ein
  5. Wähle den Nachrichtentyp (Text oder JSON); JSON-Typ validiert das Format automatisch
  6. Klicke auf 'Senden' oder drücke Enter, um die Nachricht zu senden
  7. Sieh gesendete und empfangene Nachrichten in der Nachrichtenliste an; klicke zum Kopieren

Verbindungstipps

  • Verwende wss:// bei Tests von einer HTTPS-Seite; Browser blockieren oft unsichere ws://-Verbindungen von sicheren Ursprüngen.
  • Exportieren oder kopiere wichtige Nachrichtenprotokolle, bevor du die Verbindung trennst, aktualisierst oder Endpunkte während des Debuggings wechseln.

Anwendungsfälle

Manuell mit WebSocket-Endpunkten verbindenGib eine ws://- oder wss://-URL ein, gib optional kommagetrennte Subprotokolle an und öffne eine Browser-WebSocket-Verbindung. Es werden nur die von dir 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üfenVerfasse Text- oder JSON-Nachrichten, validiere JSON vor dem Senden im JSON-Modus und sende 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 testenListe 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 deine Anwendungsparser wird typischerweise bei der ersten Nachricht fehlschlagen, weil die Rahmenbildung auf beiden Seiten nicht mehr übereinstimmt.
Heartbeats und Idle-Timeouts beobachtenLass die Verbindung ohne Datenverkehr offen und beobachte unerwünschte Ping-Frames oder Auto-Close. Vergleiche die Idle-Pause mit dem dokumentierten Heartbeat-Intervall des Servers, um zu bestätigen, dass die Keep-Alive-Einstellungen übereinstimmen, und erfasse 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 dir, ob du zum Proxy-Betreiber oder zum Anwendungsteam eskalieren solltest.

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.

Verwandte Tools

IP-Adressabfragetool

Kostenloses Online-IP-Adressen-Abfrage-Tool. Sofort Ihre öffentliche IP-Adresse und Geolokalisierungs-Info einschließlich Land, Stadt und ISP finden.

Whois Abfrage

Kostenloses Online-Whois-Domain-Abfrage-Tool. Überprüfen Sie Domain-Registrierungsinformationen, Ablaufdatum, DNS-Server, Registrar-Details. Globale Domain-Erweiterungen unterstützt, Browser-basierter Datenschutz.

URL-Auflöser

Kostenloser Online-URL-Auflöser. Short-URLs von bit.ly, t.cn, TinyURL & Co. auflösen: echtes Ziel, komplette Weiterleitungskette, Statuscodes und Ladezeiten einsehen.

DNS-Abfrage

Kostenloses Online-DNS-Abfragetool. Abfrage von A-, AAAA-, MX-, TXT-, NS-, CNAME- und SOA-Einträgen über DoH (DNS over HTTPS). Läuft lokal in deinem Browser zum Schutz der Privatsphäre.

LAN-Dateiübertragung

Online LAN-Dateiübertragungstool mit WebRTC P2P. Übertragen Sie Dateien und Text zwischen Geräten im selben Netzwerk. Kein Server nötig, Daten lokal, sicher und schnell. QR-Code-Verbindung.

Port-Prüftool

Kostenloser Online-Port-Prüfer. Prüfen Sie, ob Ports auf einer IP-Adresse oder Domain geöffnet sind. Stapelprüfung, Antwortzeit-Anzeige, Browser-basierter Datenschutz.