WebSocket 1006 fortæller ikke, hvilket led der brød
Læs unormal WebSocket-lukning som manglende bevis for Close-handshake, og find derefter ud af, om proxyopsætningen eller en etableret session fejlede.
WebSocket-kode 1006 angiver unormal lukning uden den forventede Close-ramme. Koden er reserveret: et endepunkt må ikke sende 1006 som status i en WebSocket Close-ramme. At se den i en API-hændelse er ikke en servermeddelelse, der udpeger proxyen som årsag.
Hvis forbindelsen aldrig blev åbnet
Følg opsætningen i rækkefølge: forbindelse til proxyen, proxyforhandling, destinations-TLS til WSS og derefter WebSocket-åbningshandshaken. En proxyudfordring eller afvisning af tunnelen kan stoppe forløbet før WebSocket-trinnet.
Hvis den åbnede og transporterede meddelelser
Notér den brugbare varighed og hvad der skete før lukningen. Afbrydelse af transporten, nedlukning af applikationen og en mellemleds politik kan alle efterlade modtageren uden en ren lukkeudveksling.
Bevar endepunktet, sessions-id, sidste aktivitet og om en normal Close-ramme blev observeret. Sammenlign browserens eller bibliotekets netværksfejl med destinationslogfiler, du kontrollerer. Alene hændelseskoden kan ikke udpege udbyderen, proxyoperatøren eller applikationsserveren som kilde.
En normal HTTPS-side gennem samme proxy tester en kort udveksling, ikke denne sessions levetid. Hold browsertilstand og applikationskode uændret, når du skifter rute; ellers er et vellykket nyt forsøg svært at fortolke.
Reparér den grænse, som beviserne understøtter. Proxygodkendelse, TLS-tillid og genoprettelse af applikationsforbindelsen er separate opgaver, og at forhøje alle timeouts kan ikke få 1006 til at udpege en af dem.