PCAP-Chirurgie logo PCAP-Chirurgie PCAP-Reparatur und -Bearbeitung

2026-06-02

WebSocket-Upgrade-Fehler PCAP-Analyse: 101 Switching-Protokolle, Proxy-Header, TLS und Verbindungsabbrüche

So beheben Sie WebSocket-Upgrade-Fehler mit Paketerfassungen, einschließlich HTTP 101, Upgrade-Headern, Verbindungsheadern, Proxy-Stripping, TLS, Zurücksetzungen und Leerlaufzeitüberschreitungen.

WebSocket-Upgrade ist fehlgeschlagen, 101 Schaltprotokolle, Proxy-Websocket, Verbindungserweiterung, PCAP-Analyse, http troubleshooting

WebSocket-Fehler verbergen sich oft hinter generischen Browser- oder Anwendungsmeldungen: "„WebSocket-Verbindung fehlgeschlagen“, „Unerwarteter Antwortcode“, „Verbindung geschlossen, bevor eine Handshake-Antwort empfangen wurde“, „101 Switching-Protokolle fehlen“ oder „Socket getrennt“. Benutzer suchen nach „WebSocket-Upgrade-Fehler pcap“, „101 Switching-Protokolle nicht zurückgegeben“, „Nginx-Websocket-Proxy-Header“ und „WebSocket-Verbindung zurückgesetzt“, wenn HTTP zu funktionieren scheint, der Echtzeitverkehr jedoch nicht." Eine Paketerfassung kann zeigen, ob die HTTP-Upgrade-Anfrage gesendet wurde, ob der Server „101 Switching Protocols“ zurückgegeben hat, ob ein Proxy erforderliche Header entfernt hat, ob TLS erfolgreich war und ob die Verbindung nach dem Upgrade unterbrochen wurde.

PCAP Surgery ist nützlich, da für WebSocket-Traces häufig sowohl der HTTP-Handshake als auch die TCP-Zeitleiste nach dem Upgrade erhalten bleiben müssen.

Wie ein gesundes WebSocket-Upgrade aussieht

Ein Client sendet eine HTTP-Anfrage mit Upgrade-Headern:

GET /socket HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: ...
Sec-WebSocket-Version: 13

The server replies:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: ...

Danach besteht die Verbindung nicht mehr aus gewöhnlichem HTTP-Anfrage-/Antwortverkehr. Es trägt WebSocket-Frames.

Häufige Upgrade-Fehler

Zu den häufigsten Ursachen gehören:

  • Proxy entfernt den „Upgrade“-Header.
  • Proxy entfernt oder schreibt „Verbindung: Upgrade“ neu.
  • Die Back-End-Route unterstützt WebSocket nicht.
  • Die TLS-Beendigung sendet die Anfrage an den falschen Upstream.
  • Das Upgrade-Verhalten von HTTP/2 auf HTTP/1.1 ist falsch konfiguriert.
  • Die Authentifizierungsumleitung erfolgt anstelle von 101.
  • Das Backend gibt 400, 403, 404, 426, 502 oder 504 zurück.
  • Die Verbindung wird nach dem Upgrade zurückgesetzt.
  • Leerlauf-Timeout schließt stillen WebSocket.

Der Statuscode und die Header sind wichtig.

Probleme mit dem Proxy-Header

Reverse-Proxys müssen WebSocket-Upgrade-Header korrekt weiterleiten. Wenn das Backend „Upgrade: websocket“ nie sieht, behandelt es die Anfrage möglicherweise als normales HTTP.

Paketnachweis:

  • Die Client-zu-Proxy-Anfrage enthält Upgrade-Header.
  • Bei der Proxy-zu-Backend-Anfrage fehlen sie.
  • Das Backend gibt eine normale HTTP-Antwort anstelle von 101 zurück.

Dabei handelt es sich um ein Proxy-Konfigurationsproblem und nicht um einen WebSocket-Client-Fehler.

TLS und SNI

Bei einem sicheren WebSocket („wss://“) erfolgt TLS vor dem HTTP-Upgrade. Wenn TLS fehlschlägt, beginnt der WebSocket-Handshake nie. Behalten Sie DNS, TCP, TLS ClientHello, SNI und alle TLS-Warnungen oder -Resets bei.

Führen Sie keine Diagnose von Upgrade-Headern durch, bis der TLS-Pfad nachgewiesen ist.

Verbindung bricht nach 101 ab

Manchmal ist das Upgrade erfolgreich, dann wird die Verbindung geschlossen. Das ist ein anderes Versagen.

Suchen:

  • FIN- oder RST-Absender.
  • Dauer des Leerlauf-Timeouts.
  • WebSocket-Ping-/Pong-Aktivität.
  • Zeitüberschreitung beim Lesen des Proxys.
  • TCP-Neuübertragungen.
  • Nullfenster.
  • Neustart des Backend-Prozesses.

Wenn der Abfall in einem festen Intervall erfolgt, ist eine Timeout-Richtlinie wahrscheinlich.

Checklist

Verwenden Sie diesen Workflow:

  1. Behalten Sie die DNS- und TCP-Verbindung bei.
  2. Überprüfen Sie den TLS-Handshake für „wss://“.
  3. Überprüfen Sie die Header der Client-Upgrade-Anfrage.
  4. Überprüfen Sie den Antwortstatus des Servers.
  5. Bestätigen Sie ggf. „101 Switching Protocols“.
  6. Vergleichen Sie Client-zu-Proxy- und Proxy-zu-Backend-Anfragen.
  7. Suchen Sie nach Weiterleitungen oder Authentifizierungsantworten.
  8. Wenn das Upgrade erfolgreich ist, überprüfen Sie FIN/RST/Timeout nach dem Upgrade.
  9. Behalten Sie das WebSocket-Ping/Pong-Timing bei, sofern sichtbar.
  10. Trimmen Sie erst, nachdem Sie den vollständigen Handschlag eingehalten haben.

Endgültige Diagnose

WebSocket-Upgrade-Fehler sind in der Regel HTTP-Handshake- oder Proxy-Weiterleitungsprobleme, bis „101 Switching Protocols“ nachgewiesen ist. Nach dem Upgrade führen Ausfälle zu langlebigen TCP-Timeout-, Reset- oder Anwendungsprotokollproblemen.

PCAP Surgery trägt dazu bei, beide Phasen beizubehalten, sodass ein vager WebSocket-Fehler auf Header, Proxy-Verhalten, TLS, Backend-Antwort oder Verbindungslebensdauer zurückgeführt werden kann.

Verwandte Workflows