Analyse PCAP d'échec de mise à niveau WebSocket : 101 protocoles de commutation, en-têtes de proxy, TLS et interruptions de connexion

Les échecs WebSocket se cachent souvent derrière des messages génériques de navigateur ou d'application: "Échec de la connexion WebSocket", "Code de réponse inattendu", "Connexion fermée avant de recevoir une réponse de poignée de main", "101 protocoles de commutation manquants" ou "socket déconnecté". Les utilisateurs recherchent « Échec de la mise à niveau WebSocket pcap », « 101 protocoles de commutation non renvoyés », « en-têtes de proxy WebSocket nginx » et « réinitialisation de la connexion WebSocket » lorsque HTTP semble fonctionner mais pas le trafic en temps réel." Une capture de paquets peut montrer si la demande de mise à niveau HTTP a été envoyée, si le serveur a renvoyé « 101 protocoles de commutation », si un proxy a supprimé les en-têtes requis, si TLS a réussi et si la connexion a été interrompue après la mise à niveau.

La chirurgie PCAP est utile car les traces WebSocket nécessitent souvent de préserver à la fois la prise de contact HTTP et la chronologie TCP après la mise à niveau.

À quoi ressemble une mise à niveau saine de WebSocket

Un client envoie une requête HTTP avec les en-têtes de mise à niveau :

GET /socket HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: ...
Sec-WebSocket-Version: 13

The server replies:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: ...

Après cela, la connexion n’est plus un trafic de requête/réponse HTTP ordinaire. Il transporte des trames WebSocket.

Échecs de mise à niveau courants

Les causes courantes incluent :

• Le proxy supprime l'en-tête « Mise à niveau ».
• Le proxy supprime ou réécrit « Connexion : mise à niveau ».
• La route backend ne prend pas en charge WebSocket.
• La terminaison TLS envoie une requête au mauvais amont.
• Le comportement de mise à niveau de HTTP/2 vers HTTP/1.1 est mal configuré.
• La redirection d'authentification se produit au lieu de 101.
• Le backend renvoie 400, 403, 404, 426, 502 ou 504.
• La connexion est réinitialisée après la mise à niveau.
• Le délai d'inactivité ferme le WebSocket silencieux.

Le code d'état et les en-têtes sont importants.

Problèmes d'en-tête de proxy

Les proxys inverses doivent transmettre correctement les en-têtes de mise à niveau WebSocket. Si le backend ne voit jamais « Mise à niveau : websocket », il peut traiter la requête comme un HTTP ordinaire.

Preuve par paquets :

• La requête client-proxy inclut les en-têtes de mise à niveau.
• La requête proxy vers backend en manque.
• Le backend renvoie une réponse HTTP normale au lieu de 101.

Il s'agit d'un problème de configuration de proxy, pas d'un bug du client WebSocket.

TLS et SNI

Pour WebSocket sécurisé (wss://), TLS se produit avant la mise à niveau HTTP. Si TLS échoue, la négociation WebSocket ne commence jamais. Préservez DNS, TCP, TLS ClientHello, SNI et toute alerte ou réinitialisation TLS.

Ne diagnostiquez pas les en-têtes de mise à niveau tant que le chemin TLS n’est pas prouvé.

La connexion est interrompue après 101

Parfois, la mise à niveau réussit, puis la connexion est fermée. C’est un autre échec.

Rechercher:

• Expéditeur FIN ou RST.
• Durée du délai d'inactivité.
• Activité de ping/pong WebSocket.
• Expiration du délai de lecture du proxy.
• Retransmissions TCP.
• Zéro fenêtre.
• Redémarrage du processus backend.

Si la chute se produit à un intervalle fixe, une politique de délai d'attente est probable.

Checklist

Utilisez ce flux de travail :

1. Préservez les connexions DNS et TCP.
2. Vérifiez la négociation TLS pour wss://.
3. Inspectez les en-têtes de demande de mise à niveau du client.
4. Inspectez l’état de réponse du serveur.
5. Confirmez « 101 protocoles de commutation » si prévu.
6. Comparez les requêtes client-proxy et proxy-backend.
7. Recherchez des redirections ou des réponses d'authentification.
8. Si la mise à niveau réussit, inspectez FIN/RST/timeout après la mise à niveau.
9. Conservez le timing ping/pong de WebSocket s’il est visible.
10. Coupez seulement après avoir gardé la poignée de main complète.

Diagnostic final

Les échecs de mise à niveau de WebSocket sont généralement dus à des problèmes de négociation HTTP ou de transfert de proxy jusqu'à ce que « 101 protocoles de commutation » soit prouvé. Après la mise à niveau, les échecs se transforment en problèmes de longue durée d'expiration TCP, de réinitialisation ou de protocole d'application.

PCAP Surgery aide à préserver les deux phases afin qu'une vague erreur WebSocket puisse être attribuée aux en-têtes, au comportement du proxy, à TLS, à la réponse du backend ou à la durée de vie de la connexion.