WebSocket 1006 fortel ikkje kva lenkje som rauk
Les unormal WebSocket-lukking som manglande prov på Close-handtrykket, og finn deretter ut om proxyoppsettet eller ei etablert økt svikta.
WebSocket-kode 1006 melder unormal lukking utan den venta Close-ramma. Koden er reservert: eit endepunkt må ikkje senda 1006 som status i ei WebSocket Close-ramme. Å sjå han i ein API-hending er ikkje ei tenarmelding som peikar på proxyen som årsak.
Viss tilkoplinga aldri vart opna
Følg oppsettet i rekkjefølgje: tilkopling til proxyen, proxyforhandling, destinasjons-TLS for WSS, deretter WebSocket-opningshandtrykket. Ei proxyutfordring eller avvising av tunnelen kan stoppa sekvensen før WebSocket-trinnet.
Viss ho opna og frakta meldingar
Noter den brukbare varigheita og kva som skjedde før lukkinga. Avbrot i transporten, nedstenging av applikasjonen og ein mellommanns policy kan alle etterlata mottakaren utan ei rein lukkeutveksling.
Ta vare på endepunktet, øktidentifikatoren, siste aktivitet og om ei normal Close-ramme vart observert. Samanlikn nettverksfeila til nettlesaren eller biblioteket med destinasjonsloggar du kontrollerer. Berre hendingskoden kan ikkje identifisera leverandøren, proxyoperatøren eller applikasjonsserveren som kjelde.
Ei vanleg HTTPS-side gjennom same proxy testar ei kort utveksling, ikkje levetida til denne økta. Hald nettlesartilstanden og applikasjonskoden uendra når du byter rute; elles er eit vellukka nytt forsøk vanskeleg å tolka.
Reparer grensa som prova støttar. Proxyautentisering, TLS-tillit og gjenoppkopling av applikasjonen er separate jobbar, og å auke alle tidsavbrot kan ikkje få 1006 til å peika ut ein av dei.