WebSocket 1006 ne diras, kiu ligo rompiĝis
Legu nenormalan fermiĝon de WebSocket kiel mankantan pruvon de Close-handshake, poste trovu ĉu la proksea agordo aŭ jam establita sesio malsukcesis.
WebSocket-kodo 1006 raportas nenormalan fermiĝon sen la atendata Close-kadro. Ĝi estas rezervita: finpunkto ne rajtas sendi 1006 kiel staton en WebSocket Close-kadro. Vidi ĝin en API-evento ne estas servila mesaĝo, kiu nomas la prokseon la kaŭzo.
Se la konekto neniam malfermiĝis
Sekvu la agordon laŭvice: konekto al la prokseo, proksea intertraktado, celloka TLS por WSS, poste la malferma WebSocket-handshake. Proksea defio aŭ tunela rifuzo povas haltigi la sinsekvon antaŭ la WebSocket-etapo.
Se ĝi malfermiĝis kaj portis mesaĝojn
Notu la utilan daŭron kaj kio okazis antaŭ la fermo. Transporta interrompo, halto de la aplikaĵo kaj politiko de peranto povas lasi ricevanton sen pura ferma interŝanĝo.
Konservu la finpunkton, la sesian identigilon, la lastan aktivecon kaj ĉu normala Close-kadro estis observita. Komparu la retajn erarojn de la retumilo aŭ biblioteko kun cellokaj protokoloj, kiujn vi kontrolas. Nur la eventa kodo ne povas identigi la provizanton, la proksean operatoron aŭ la aplikaĵan servilon kiel fonton.
Normala HTTPS-paĝo tra la sama prokseo kontrolas mallongan interŝanĝon, ne la vivdaŭron de ĉi tiu sesio. Tenu la retumilan staton kaj la aplikaĵan kodon senŝanĝaj dum vi ŝanĝas la vojon; alie sukcesa reprovo estas malfacile interpretebla.
Riparu la limon, kiun la pruvoj subtenas. Proksea aŭtentikigo, TLS-fido kaj rekonekto de la aplikaĵo estas apartaj taskoj, kaj pliigi ĉiujn tempolimojn ne povas igi 1006 identigi unu el ili.