La pàgina del xat es carrega però la connexió en directe falla: on mirar

Obriu el panell de xarxa abans de carregar la pàgina del xat, i després trobeu la petició que porta els missatges en lloc de la que dibuixa l’esquelet. El document, els scripts, l’intercanvi d’inici de sessió i el transport del xat poden anar a amfitrions diferents. La majoria d’informes que la VPN va trencar el xat descriuen en realitat el fracàs d’una d’aquestes quatre peticions. Mireu-les per ordre i la resposta normalment es veu en els primers dos minuts.

Trobeu la petició que porta els missatges

Filtreu per tipus quan la pàgina s’estabilitzi: un WebSocket apareix com a entrada pròpia, un flux d’esdeveniments queda obert amb una resposta creixent, i una enquesta llarga es repeteix a interval regular. Anoteu l’esquema, l’amfitrió, el port i l’estat de la que porti les actualitzacions. Fixeu-vos si va començar abans o després de l’inici de sessió, perquè un transport obert abans de l’autenticació sol tenir un disseny diferent del que s’obre després. Llegiu les capçaleres de la petició d’actualització o del tipus de contingut acceptat, perquè identifiquen el transport que la pàgina desplegada va triar realment.

Els missatges antics de fòrums descriuen transports que els productes van deixar d’usar fa anys, així que confieu en el que el navegador va enregistrar i no en l’article. Si l’entrada falta del tot, potser el codi del client mai va intentar connectar-se, cosa que apunta a un fracàs anterior de script o de configuració. Una pàgina que es carrega només demostra que el document va arribar, i aquesta distinció decideix si esteu depurant la xarxa o no.

La configuració, el lliurament i la durada fallen de maneres diferents

Un WebSocket s’obre amb una actualització HTTP que rep un estat 101, i tot el que ve després són missatges emmarcats en lloc de descàrrega de pàgines, dues etapes que RFC 6455 manté explícitament separades. Un flux d’esdeveniments respon amb un tipus de contingut en streaming i manté obert el cos de la resposta. Tots dos poden fallar en obrir-se, obrir-se i no lliurar res, o obrir-se, lliurar i després morir en silenci.

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

Captureu el primer fracàs significatiu abans de tocar cap perfil, perquè els tres moments assenyalen capes diferents. Si l’apretada de mans no s’acaba mai, compareu-la amb una petició HTTPS simple al mateix amfitrió per veure si hi arriba res. Si s’acaba i no arriben missatges, observeu els marcs o el cos del flux mentre algú envia un missatge de prova des d’un altre compte. Si funciona i després s’atura, anoteu l’hora exacta i el codi de tancament, perquè aquesta parella identifica quin extrem va cedir.

El codi 1006 significa que el sòcol es va tancar sense un marc de tancament, que és com es veu un intermediari o un temps d’espera per inactivitat des de dins del navegador. Un batec de la VPN no demostra que la sessió interna de l’aplicació encara sigui viva.

L’amfitrió en directe és una destinació a part

Els serveis de xat sovint viuen en el seu propi nom d’amfitrió, de vegades en un port diferent o darrere d’un certificat a part. Aquesta destinació necessita la seva pròpia resolució, ruta i tractament de proxy, i el tunelatge dividit pot incloure la pàgina i excloure el sòcol. Resoleu el nom d’amfitrió en directe des de la màquina client i confirmeu que respon amb l’adreça que espereu en aquella xarxa. Reviseu la cadena de certificats específicament per a aquell nom d’amfitrió, perquè un comodí que cobreix el lloc no sempre cobreix el punt final del sòcol.

Si hi ha un proxy al camí, confirmeu que permet l’actualització o la resposta de llarga durada en lloc d’emmagatzemar-la temporalment. Els proxys corporatius que reescriuen HTML sovint gestionen malament les actualitzacions de WebSocket, cosa que produeix una pàgina que es mostra mentre el xat no es connecta mai. Dues peticions al mateix producte, doncs, no són dues peticions al mateix amfitrió.

Corregiu la llista de destinacions, no les comprovacions de seguretat

Corregir una llista de destinacions és un canvi d’encaminament i pertoca a qui posseeix la ruta. Relaxar la validació de certificats o eliminar la capçalera Origin és un canvi de seguretat i pertoca a qui posseeix la política, que poques vegades és la persona que depura el tiquet. La manera més ràpida de fer aparèixer una connexió sol ser la manera més ràpida de fer possible un incident.

Pregunteu al propietari de l’aplicació quins orígens accepta el servidor abans de canviar res, i passeu aquesta resposta a qui controla el proxy. Si un error de certificat apareix només a través del túnel, inspeccioneu el dispositiu que intercepta en lloc d’instal·lar una excepció.

Enregistreu prou per fer el traspàs

L’artefacte útil és curt: URL de la pàgina, punt final en directe, resultat de l’apretada de mans, hora del primer fracàs i si es va intentar reconnectar. Afegiu el nom del perfil de VPN i la xarxa on éreu, i qualsevol lector podrà reproduir la prova sense fer sis preguntes. Oculteu les galetes, les capçaleres d’autorització i els cossos dels missatges, i preferiu una captura de la columna de temps a una exportació completa de l’arxiu. Els marcs i els arxius de xarxa poden contenir missatges privats i testimonis de sessió, així que inspeccioneu abans d’adjuntar res.

Si el fracàs és un tancament silenciós, incloeu el codi de tancament i l’interval d’inactivitat que el va precedir, perquè aquesta parella sol identificar el propietari del temps d’espera. Lliureu el registre al propietari de l’aplicació o de la passarel·la en lloc d’endevinar un valor de temps d’espera. La seva resposta sobre el comportament de keepalive admès és la que tanca el tiquet.