WebSocket 1006 nie mówi, które ogniwo pękło
Czytaj nieprawidłowe zamknięcie WebSocket jako brak dowodu Close handshake, a następnie ustal, czy zawiodła konfiguracja proxy, czy już ustanowiona sesja.
Kod WebSocket 1006 zgłasza nieprawidłowe zamknięcie bez oczekiwanej ramki Close. Kod jest zarezerwowany: punkt końcowy nie może wysyłać 1006 jako statusu w ramce Close WebSocket. Widok w zdarzeniu API nie jest komunikatem serwera wskazującym proxy jako przyczynę.
Jeśli połączenie nigdy się nie otworzyło
Postępuj zgodnie z konfiguracją po kolei: połączenie z proxy, negocjacja proxy, TLS celu dla WSS, następnie handshake otwarcia WebSocket. Wyzwanie proxy lub odrzucenie tunelu mogą zatrzymać sekwencję przed etapem WebSocket.
Jeśli się otworzyło i przenosiło komunikaty
Zapisz użyteczny czas trwania i to, co wydarzyło się przed zamknięciem. Przerwa w transporcie, wyłączenie aplikacji i polityka pośrednika mogą pozostawić odbiorcę bez czystej wymiany zamknięcia.
Zachowaj punkt końcowy, identyfikator sesji, ostatnią aktywność i informację, czy zaobserwowano normalną ramkę Close. Porównaj błędy sieciowe przeglądarki lub biblioteki z dziennikami celu, które kontrolujesz. Sam kod zdarzenia nie może wskazać dostawcy, operatora proxy ani serwera aplikacji jako źródła.
Zwykła strona HTTPS przez to samo proxy sprawdza krótką wymianę, a nie czas życia tej sesji. Utrzymuj stan przeglądarki i kod aplikacji bez zmian przy zmianie trasy; inaczej trudno zinterpretować udaną ponowną próbę.
Napraw granicę, którą popierają dowody. Uwierzytelnianie proxy, zaufanie TLS i ponowne połączenie aplikacji to osobne zadania, a zwiększanie wszystkich limitów czasu nie sprawi, że 1006 wskaże jedno z nich.