WebSocket 1006 ne dit pas quel maillon a rompu
Lisez la fermeture anormale de WebSocket comme une preuve manquante de Close handshake, puis déterminez si la configuration du proxy ou une session déjà établie a échoué.
Le code 1006 de WebSocket signale une fermeture anormale sans la trame Close attendue. Il est réservé : un point de terminaison ne doit pas envoyer 1006 comme statut dans une trame Close WebSocket. Le voir dans un événement API n'est pas un message du serveur désignant le proxy comme cause.
Si la connexion ne s'est jamais ouverte
Suivez la configuration dans l'ordre : connexion au proxy, négociation du proxy, TLS de destination pour WSS, puis la poignée de main d'ouverture WebSocket. Un défi du proxy ou un refus de tunnel peut arrêter la séquence avant l'étape WebSocket.
Si elle s'est ouverte et a transporté des messages
Notez la durée utile et ce qui s'est passé avant la fermeture. Une interruption du transport, l'arrêt de l'application et la politique d'un intermédiaire peuvent laisser le récepteur sans échange de fermeture propre.
Conservez le point de terminaison, l'identifiant de session, la dernière activité et si une trame Close normale a été observée. Comparez les erreurs réseau du navigateur ou de la bibliothèque avec les journaux de destination que vous contrôlez. Le code d'événement seul ne peut pas identifier le fournisseur d'accès, l'opérateur du proxy ou le serveur applicatif comme source.
Une page HTTPS normale via le même proxy teste un échange court, pas la durée de vie de cette session. Gardez l'état du navigateur et le code de l'application stables lors d'un changement de route ; sinon, un nouvel essai réussi est difficile à interpréter.
Réparez la frontière que les preuves soutiennent. L'authentification du proxy, la confiance TLS et la reconnexion de l'application sont des tâches distinctes, et augmenter tous les délais d'attente ne peut pas faire que 1006 en désigne une.