A páxina do chat carga pero a conexión en directo falla: onde mirar

Abre o panel de rede antes de cargar a páxina do chat e despois atopa a petición que transporta as mensaxes en lugar da que debuxa a estrutura. O documento, os scripts, o intercambio de inicio de sesión e o transporte do chat poden ir a hosts distintos. A maioría dos informes de que a VPN rompeu o chat describen en realidade o fallo dunha desas catro peticións. Míraas en orde e a resposta adoita verse nos primeiros dous minutos.

Atopa a petición que transporta as mensaxes

Filtra por tipo cando a páxina se estabilice: un WebSocket aparece como a súa propia entrada, un fluxo de eventos permanece aberto cunha resposta crecente e unha sondaxe longa repítese a intervalos regulares. Anota o esquema, o host, o porto e o estado da que transporte as actualizacións. Fíxate en se comezou antes ou despois do inicio de sesión, porque un transporte aberto antes da autenticación adoita ter un deseño distinto do que se abre despois. Le as cabeceiras da petición de actualización ou do tipo de contido aceptado, porque identifican o transporte que a páxina despregada escolleu realmente.

As mensaxes antigas de foros describen transportes que os produtos deixaron de usar hai anos, así que confía no que rexistrou o navegador e non no artigo. Se a entrada falta por completo, pode que o código do cliente nunca tentase conectarse, o que apunta a un fallo anterior de script ou de configuración. Unha páxina que carga só demostra que o documento chegou, e esa distinción decide se estás depurando a rede ou non.

A configuración, a entrega e a duración fallan de xeito distinto

Un WebSocket ábrese cunha actualización HTTP que recibe un estado 101, e todo o posterior son mensaxes enmarcadas en lugar de descarga de páxinas, dúas etapas que RFC 6455 mantén explicitamente separadas. Un fluxo de eventos responde cun tipo de contido en streaming e mantén aberto o corpo da resposta. Ambos poden fallar ao abrirse, abrirse e non entregar nada, ou abrirse, entregar e despois morrer en silencio.

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

Captura o primeiro fallo significativo antes de tocar calquera perfil, porque os tres momentos apuntan a capas diferentes. Se o aperto de mans nunca se completa, compárao cunha petición HTTPS simple ao mesmo host para ver se algo chega ata alí. Se se completa e non chegan mensaxes, vixía as tramas ou o corpo do fluxo mentres alguén envía unha mensaxe de proba desde outra conta. Se funciona e despois se detén, anota a hora exacta e o código de peche, porque ese par identifica que extremo se rendeu.

O código 1006 significa que o socket se pechou sen unha trama de peche, que é o aspecto dun intermediario ou dun tempo de espera por inactividade desde dentro do navegador. Un latexo da VPN non demostra que a sesión interna da aplicación siga viva.

O host en directo é un destino á parte

Os backends de chat a miúdo viven no seu propio nome de host, ás veces nun porto distinto ou detrás dun certificado á parte. Ese destino necesita a súa propia resolución, ruta e tratamento de proxy, e o tunelado dividido pode incluír a páxina e excluír o socket. Resolve o nome do host en directo desde a máquina cliente e confirma que responde co enderezo que esperas nesa rede. Revisa a cadea de certificados especificamente para ese nome de host, porque un comodín que cobre o sitio non sempre cobre o punto final do socket.

Se hai un proxy no camiño, confirma que permite a actualización ou a resposta de longa duración en lugar de almacenala en búfer. Os proxys corporativos que reescriben HTML adoitan xestionar mal as actualizacións de WebSocket, o que produce unha páxina que se mostra mentres o chat nunca se conecta. Dúas peticións ao mesmo produto non son, polo tanto, dúas peticións ao mesmo host.

Corrixe a lista de destinos, non as comprobacións de seguridade

Corrixir unha lista de destinos é un cambio de enrutamento e corresponde a quen posúe a ruta. Relaxar a validación de certificados ou eliminar a cabeceira Origin é un cambio de seguridade e corresponde a quen posúe a política, que raramente é a persoa que depura o ticket. A forma máis rápida de facer aparecer unha conexión adoita ser a forma máis rápida de facer posible un incidente.

Pregunta ao propietario da aplicación que orixes acepta o backend antes de cambiar nada, e pasa esa resposta a quen controla o proxy. Se un erro de certificado aparece só a través do túnel, inspecciona o dispositivo que intercepta en lugar de instalar unha excepción.

Rexistra o suficiente para a entrega

O artefacto útil é breve: URL da páxina, punto final en directo, resultado do aperto de mans, hora do primeiro fallo e se se intentou reconectar. Engade o nome do perfil de VPN e a rede na que estabas, e calquera que o lea poderá reproducir a proba sen facer seis preguntas. Oculta as cookies, as cabeceiras de autorización e os corpos das mensaxes, e prefire unha captura da columna de tempos a unha exportación completa do arquivo. As tramas e os arquivos de rede poden conter mensaxes privadas e tokens de sesión, así que inspecciona antes de anexar calquera cousa.

Se o fallo é un peche silencioso, inclúe o código de peche e o intervalo de inactividade que o precedeu, porque ese par adoita identificar o propietario do tempo de espera. Entrega o rexistro ao propietario da aplicación ou da pasarela en lugar de adiviñar un valor de tempo de espera. A súa resposta sobre o comportamento de keepalive admitido é a que pecha o ticket.