WebSocket 1006 sagt nicht, welches Glied brach
Lesen Sie einen abnormalen WebSocket-Abschluss als fehlenden Beleg für den Close-Handshake und klären Sie dann, ob das Proxy-Setup oder eine bestehende Sitzung versagt hat.
WebSocket-Code 1006 meldet einen abnormalen Abschluss ohne den erwarteten Close-Frame. Der Code ist reserviert: Ein Endpunkt darf 1006 nicht als Status in einem WebSocket-Close-Frame senden. Ihn in einem API-Ereignis zu sehen, ist keine Servermeldung, die den Proxy als Ursache benennt.
Wenn die Verbindung nie geöffnet wurde
Folgen Sie dem Setup der Reihe nach: Verbindung zum Proxy, Proxy-Aushandlung, Ziel-TLS für WSS, dann der WebSocket-Eröffnungshandshake. Eine Proxy-Aufforderung oder eine Tunnel-Ablehnung kann die Abfolge vor der WebSocket-Phase stoppen.
Wenn sie geöffnet wurde und Nachrichten trug
Notieren Sie die nutzbare Dauer und was vor dem Abschluss geschah. Transportunterbrechung, Anwendungsabschaltung und die Richtlinie eines Zwischenglieds können einen Empfänger ohne sauberen Abschlussaustausch zurücklassen.
Bewahren Sie Endpunkt, Sitzungskennung, letzte Aktivität und ob ein normaler Close-Frame beobachtet wurde. Vergleichen Sie die Netzwerkfehler von Browser oder Bibliothek mit Zielprotokollen, die Sie kontrollieren. Der Ereigniscode allein kann weder den ISP noch den Proxy-Betreiber oder den Anwendungsserver als Quelle benennen.
Eine normale HTTPS-Seite über denselben Proxy prüft einen kurzen Austausch, nicht die Lebensdauer dieser Sitzung. Halten Sie Browserzustand und Anwendungscode beim Wechsel der Route konstant; sonst ist ein erfolgreicher Wiederholungsversuch schwer zu deuten.
Reparieren Sie die Grenze, die die Belege stützen. Proxy-Authentifizierung, TLS-Vertrauen und Wiederverbindung der Anwendung sind getrennte Aufgaben, und das Erhöhen aller Timeouts kann 1006 nicht dazu bringen, eine davon zu benennen.