La page de chat se charge mais la connexion en direct échoue : où chercher

Ouvrez le panneau réseau avant de charger la page de chat, puis trouvez la requête qui transporte les messages plutôt que celle qui dessine la coque. Le document, les scripts, l’échange de connexion et le transport du chat peuvent tous aller vers des hôtes différents. La plupart des signalements selon lesquels le VPN a cassé le chat décrivent en réalité l’échec de l’une de ces quatre requêtes. Observez-les dans l’ordre et la réponse est généralement visible dans les deux premières minutes.

Trouvez la requête qui transporte les messages

Filtrez par type une fois la page stabilisée : un WebSocket apparaît comme sa propre entrée, un flux d’événements reste ouvert avec une réponse croissante, et une interrogation longue se répète à intervalle régulier. Notez le schéma, l’hôte, le port et le statut de celle qui transporte les mises à jour. Remarquez si elle a commencé avant ou après la connexion, car un transport ouvert avant l’authentification a généralement une conception différente de celui ouvert après. Lisez les en-têtes de la requête de mise à niveau ou du type de contenu accepté, car ils identifient le transport que la page déployée a réellement choisi.

Les anciens messages de forum décrivent des transports que les produits ont cessé d’utiliser il y a des années, alors faites confiance à ce que le navigateur a enregistré plutôt qu’à l’article. Si l’entrée manque complètement, le code client n’a peut-être jamais tenté de connexion, ce qui indique un échec antérieur de script ou de configuration. Une page qui se charge prouve seulement que le document est arrivé, et cette distinction décide si vous déboguez réellement le réseau.

La configuration, la livraison et la durée de vie échouent différemment

Un WebSocket s’ouvre par une mise à niveau HTTP à laquelle on répond par un statut 101, et tout ce qui suit est constitué de messages encadrés plutôt que de récupération de pages, deux étapes que RFC 6455 maintient explicitement séparées. Un flux d’événements répond avec un type de contenu en flux et maintient le corps de la réponse ouvert. Les deux peuvent échouer à s’ouvrir, s’ouvrir sans rien livrer, ou s’ouvrir, livrer puis mourir silencieusement.

wscat -c wss://chat.example.com/socket -H "Origin: https://chat.example.com"
curl -N -H "Accept: text/event-stream" https://chat.example.com/events

Capturez le premier échec significatif avant de toucher à un profil, car les trois moments pointent vers des couches différentes. Si la poignée de main ne se termine jamais, comparez-la à une requête HTTPS simple vers le même hôte pour voir si quoi que ce soit l’atteint. Si elle se termine et qu’aucun message n’arrive, surveillez les trames ou le corps du flux pendant que quelqu’un envoie un message de test depuis un autre compte. Si cela fonctionne puis s’arrête, notez l’heure exacte et le code de fermeture, car ce couple identifie quel côté a abandonné.

Le code 1006 signifie que le socket s’est fermé sans trame de fermeture, ce qui est l’aspect d’un intermédiaire ou d’un délai d’inactivité vu de l’intérieur du navigateur. Un battement de cœur VPN ne prouve pas que la session interne de l’application est encore vivante.

L’hôte en direct est une destination à part

Les backends de chat vivent souvent sur leur propre nom d’hôte, parfois sur un port différent ou derrière un certificat distinct. Cette destination a besoin de sa propre résolution, route et traitement de proxy, et le tunnel divisé peut inclure la page tout en excluant le socket. Résolvez le nom d’hôte en direct depuis la machine cliente et confirmez qu’il répond avec l’adresse attendue sur ce réseau. Vérifiez la chaîne de certificats spécifiquement pour ce nom d’hôte, car un joker qui couvre le site ne couvre pas toujours le point de terminaison du socket.

Si un proxy se trouve sur le chemin, confirmez qu’il autorise la mise à niveau ou la réponse de longue durée au lieu de la mettre en tampon. Les proxys d’entreprise qui réécrivent le HTML gèrent souvent mal les mises à niveau WebSocket, ce qui produit une page qui s’affiche alors que le chat ne se connecte jamais. Deux requêtes vers le même produit ne sont donc pas deux requêtes vers le même hôte.

Corrigez la liste des destinations, pas les contrôles de sécurité

Corriger une liste de destinations est un changement de routage et appartient à qui possède la route. Assouplir la validation des certificats ou supprimer l’en-tête Origin est un changement de sécurité et appartient à qui possède la politique, ce qui est rarement la personne qui débogue le ticket. Le moyen le plus rapide de faire apparaître une connexion est généralement le moyen le plus rapide de rendre un incident possible.

Demandez au propriétaire de l’application quelles origines le backend accepte avant de changer quoi que ce soit, et transmettez cette réponse à qui contrôle le proxy. Si une erreur de certificat n’apparaît que par le tunnel, inspectez l’appareil qui intercepte au lieu d’installer un contournement.

Consignez assez pour la transmission

L’artefact utile est court : URL de la page, point de terminaison en direct, résultat de la poignée de main, heure du premier échec et si une reconnexion a été tentée. Ajoutez le nom du profil VPN et le réseau sur lequel vous étiez, et n’importe quel lecteur pourra reproduire le test sans poser six questions. Masquez les cookies, les en-têtes d’autorisation et les corps des messages, et préférez une capture de la colonne des temps à une exportation complète de l’archive. Les trames et les archives réseau peuvent contenir des messages privés et des jetons de session, alors inspectez avant de joindre quoi que ce soit.

Si l’échec est une fermeture silencieuse, incluez le code de fermeture et l’intervalle d’inactivité qui l’a précédé, car ce couple identifie généralement le propriétaire du délai d’attente. Remettez le relevé au propriétaire de l’application ou de la passerelle au lieu de deviner vous-même une valeur de délai. Leur réponse sur le comportement de keepalive pris en charge est celle qui clôt le ticket.