WebSocket 1006 säger inte vilken länk som bröts
Läs onormal WebSocket-stängning som saknat bevis för Close-handskakningen och ta sedan reda på om proxyuppsättningen eller en redan etablerad session misslyckades.
WebSocket-kod 1006 rapporterar onormal stängning utan den förväntade Close-ramen. Koden är reserverad: en endpoint får inte skicka 1006 som status i en WebSocket Close-ram. Att se den i en API-händelse är inte ett servermeddelande som pekar ut proxyn som orsak.
Om anslutningen aldrig öppnades
Följ uppsättningen i ordning: anslutning till proxyn, proxyförhandling, destinations-TLS för WSS och sedan WebSocket-öppningshandskakningen. En proxyutmaning eller tunnelavvisning kan stoppa sekvensen före WebSocket-steget.
Om den öppnades och bar meddelanden
Notera den användbara varaktigheten och vad som hände före stängningen. Avbrott i transporten, nedstängning av programmet och en mellanhands policy kan alla lämna mottagaren utan ett rent stängningsutbyte.
Bevara endpointen, sessionsidentifieraren, senaste aktivitet och om en normal Close-ram observerades. Jämför webbläsarens eller bibliotekets nätverksfel med destinationsloggar du kontrollerar. Enbart händelsekoden kan inte identifiera leverantören, proxyoperatören eller applikationsservern som källa.
En vanlig HTTPS-sida via samma proxy testar ett kort utbyte, inte livslängden för denna session. Håll webbläsarens tillstånd och programkoden oförändrade när du byter väg; annars är ett lyckat nytt försök svårt att tolka.
Reparera gränsen som bevisen stöder. Proxyautentisering, TLS-förtroende och återanslutning av programmet är separata arbeten, och att höja alla tidsgränser kan inte få 1006 att peka ut en av dem.