Kann ich ws://localhost oder einen LAN-Server von dieser HTTPS-Seite aus testen?
Das hängt vom Browser ab (Stand: Oktober 2026). Chrome ab Version 147 behandelt WebSocket-Verbindungen zu Ihrem Rechner oder Ihrem lokalen Netzwerk als Zugriff aufs lokale Netzwerk: Beim ersten Mal fragt er, ob Sie dieser Website den Zugriff erlauben, und nachdem Sie „Zulassen“ gewählt haben, verbinden sich ws://localhost, ws://127.0.0.1 und ws:// zu einer LAN-IP-Adresse wie 192.168.1.10. In Chrome muss der LAN-Server als IP-Adresse angegeben werden; ein einfacher Hostname (außer .local) wird blockiert, selbst wenn er in Ihr Netzwerk auflöst. Firefox verbindet sich direkt mit localhost, blockiert aber ws:// zu LAN-Adressen. Safari blockiert ws:// zu localhost und ins LAN von HTTPS-Seiten aus. wss:// ist von der Mixed-Content-Regel nicht betroffen: Öffentliche Server funktionieren von dieser Seite aus in jedem Browser, solange dem Zertifikat vertraut wird; bei localhost- oder LAN-Adressen fragt Chrome auch hier zuerst nach dem Zugriff aufs lokale Netzwerk.
Warum kann ich mich von dieser Seite aus nicht mit ws://example.com verbinden?
Diese Seite wird über HTTPS ausgeliefert, und Browser blockieren von einer HTTPS-Seite aus eine unverschlüsselte ws://-Verbindung zu einem öffentlichen Host (Mixed Content). Chrome und Firefox verweigern sofort mit einem SecurityError, den das Tool meldet. Verwenden Sie die wss://-Adresse des Servers. Für öffentliche Websites, die über reines http ausgeliefert werden, gilt diese Regel nicht, aber im aktuellen Chrome können sie localhost oder Ihr LAN überhaupt nicht erreichen.
Die Verbindung ist mit Code 1006 fehlgeschlagen – was ist schiefgelaufen?
1006 bedeutet nur, dass die Verbindung ohne Closing Handshake endete. Schlägt ein Handshake fehl, verlangt der WebSocket-Standard, dass der Browser die Ursache vor der Seite verbirgt – ein 401, ein 404, ein abgewiesener Port, ein Zertifikatsfehler und ein abgelehnter Origin sehen alle gleich aus (Firefox meldet Zertifikatsfehler als 1015) –, daher kann kein Web-Tester, der sich direkt aus dem Browser verbindet, sie anzeigen. Drücken Sie F12 und öffnen Sie die Konsole: Chrome und Edge geben den HTTP-Status aus, den der Server zurückgegeben hat. Außerdem unterscheidet das Tool Fehler, bevor die Verbindung offen war, von Abbrüchen danach und listet für beide die üblichen Ursachen auf.
Kann ich einen Authorization- oder einen anderen eigenen Header hinzufügen?
Nein. Die WebSocket-API des Browsers lässt Webseiten keine Request-Header setzen; der Browser sendet einen festen Satz (darunter Origin und Cookies für die eigene Website des Servers). Gängige Auswege, je nachdem, was Ihr Server unterstützt: ein Token in der URL, etwa wss://host/ws?token=…; ein Token als Subprotokoll (erlaubt sind nur Token-Zeichen, JWT funktioniert also, Standard-Base64 mit = oder / aber nicht, und der Server muss das Subprotokoll zurückgeben); oder ein Cookie, das Browser zuverlässig nur an die eigene Website der Seite senden, sodass es von dieser Seite aus Ihren Server meist nicht erreicht. Tools wie Postman können Header setzen, weil sie keine Browser sind.
Warum funktioniert es in Postman, aber nicht hier?
Postman und Kommandozeilen-Clients können beliebige Header setzen und senden meist keinen Origin. Ein Browser kann keinen Authorization-Header hinzufügen und sendet immer Origin: https://go-tools.org. Braucht der Server ein Token im Header oder prüft er Origin, lehnt er den Handshake des Browsers ab; lassen Sie den Origin zu oder übergeben Sie das Token auf anderem Weg.
Sendet der Heartbeat WebSocket-Ping-Frames?
Nein. Webseiten können Ping/Pong-Frames auf Protokollebene weder senden noch sehen; sendet der Server einen Ping, antwortet der Browser selbst mit einem Pong. Das zeitgesteuerte Senden hier verschickt eine gewöhnliche Textnachricht, etwa {"type":"ping"}, in dem Intervall, das Sie festlegen. Es ist standardmäßig ausgeschaltet, weil ein Server, der diese Nachricht nicht erwartet, die Verbindung schließen könnte. Um eine inaktive Verbindung über einen Proxy hinweg offen zu halten, lassen Sie den Server Pings senden.
Warum kann ich mich nicht mit meinem Socket.IO-Server verbinden?
Socket.IO ist ein Protokoll auf WebSocket-Basis, kein reines WebSocket. Ein Socket.IO-v3/v4-Server erwartet den Pfad /socket.io/?EIO=4&transport=websocket, sendet ein Open-Paket, das mit 0 beginnt, erwartet 40, um dem Standard-Namespace beizutreten, und schließt die Verbindung, wenn nicht jedes Ping 2 mit Pong 3 beantwortet wird. Wählen Sie das Socket.IO-Preset, und das Tool erledigt all das; danach senden Sie Events als 42["event","data"]. Server, die nur für HTTP-Long-Polling konfiguriert sind, nehmen überhaupt kein WebSocket an.
Meine Verbindung bricht nach etwa einer Minute ab – warum?
Meist ist es ein Idle-Timeout in einem Reverse Proxy. Nginx schließt eine weitergeleitete Verbindung standardmäßig, wenn 60 Sekunden lang keine Daten fließen (proxy_read_timeout), und die Seite sieht Code 1006. Erhöhen Sie das Timeout oder lassen Sie den Server Ping-Frames senden. Hinter Nginx stellen Sie außerdem sicher, dass der Proxy das Upgrade mit proxy_set_header Upgrade $http_upgrade; und proxy_set_header Connection "upgrade"; weiterleitet (vor Nginx 1.29.7 zusätzlich proxy_http_version 1.1;).
Wie verbinde ich mich mit einem wss://-Server mit selbstsigniertem Zertifikat?
Öffnen Sie https://derselbe-host:port/ in einem neuen Tab, akzeptieren Sie die Zertifikatswarnung, kommen Sie dann zurück und verbinden Sie sich. Der Browser merkt sich die Ausnahme für diesen Host und Port. Tun Sie das nur für Ihre eigenen Testserver, weil es den Schutz des Browsers schwächt.
Wie sende und lese ich Binärnachrichten?
Wählen Sie HEX oder Base64 als Sendeformat. HEX akzeptiert 48 69 00 FF, 0x48,0x69 oder 486900FF; die Vorschau zeigt die Bytes, und ungültige Zeichen oder eine ungerade Ziffernanzahl werden mit ihrer Position gemeldet, statt gesendet zu werden. Empfangene Binärnachrichten werden als HEX mit 16 Bytes pro Zeile angezeigt, und die Symbolleiste des Logs schaltet sie auf Base64 um. Um empfangenes HEX als Text zu lesen, fügen Sie es in Hex in Text ein. Laufen meine Nachrichten über Server von go-tools?
Nein. Ihr Browser verbindet sich direkt mit der Adresse, die Sie eingeben, und Nachrichten laufen nicht über unsere Server. Das Tool öffnet außerdem keine WebSocket-Verbindung, bevor Sie auf Verbinden klicken, und hält Adresse und Nachrichten nur im Arbeitsspeicher – nicht in der Seiten-URL und nicht im Browserspeicher. Wie der Rest der Website lädt diese Seite Analyse- und Werbeskripte.
Gibt es einen Server, gegen den ich testen kann?
Nutzen Sie das lokale Echo: Es läuft innerhalb dieser Seite, schickt alles zurück, was Sie senden, und baut keine Netzwerkverbindung auf. Es gibt auch öffentliche Echo-Dienste wie wss://echo.websocket.org/, aber sie werden von Dritten betrieben: Die Verfügbarkeit ist nicht garantiert, und Ihre Nachrichten gehen an diesen Drittanbieter.