A página do chat carrega, mas a ligação ao vivo falha: onde olhar

Abra o painel de rede antes de carregar a página do chat e, em seguida, encontre o pedido que transporta as mensagens em vez do que desenha a estrutura da página. O documento, os scripts, a troca no início de sessão e o transporte do chat podem ir todos para anfitriões diferentes. A maioria dos relatos de que a VPN estragou o chat descreve, na realidade, a falha de um desses quatro pedidos. Observe-os por ordem e a resposta costuma ser visível nos primeiros dois minutos.

Encontre o pedido que transporta as mensagens

Filtre por tipo quando a página assentar: um WebSocket aparece como uma entrada própria, um fluxo de eventos fica aberto com uma resposta a crescer e um long poll repete-se a intervalos regulares. Registe o esquema, o anfitrião, a porta e o estado daquele que transporta as atualizações. Anote se começou antes ou depois do início de sessão, porque um transporte aberto antes da autenticação é, normalmente, um desenho diferente de um aberto depois. Leia os cabeçalhos do pedido de atualização ou do tipo de conteúdo aceite, porque identificam o transporte que a página publicada escolheu de facto.

Publicações antigas de fóruns descrevem transportes que os produtos abandonaram há anos, por isso confie no que o navegador registou e não no artigo. Se a entrada faltar por completo, o código do cliente pode nunca ter tentado uma ligação, o que aponta para uma falha anterior de script ou de configuração. Uma página que carrega prova apenas que o documento chegou, e essa distinção decide se está sequer a depurar a rede.

Configuração, entrega e tempo de vida falham de formas diferentes

Um WebSocket abre com uma atualização HTTP respondida com o estado 101, e tudo o resto são mensagens em quadros em vez de obtenção de páginas, duas fases que a RFC 6455 mantém explicitamente separadas. Um fluxo de eventos responde com um tipo de conteúdo em streaming e mantém o corpo da resposta aberto. Ambos podem falhar a abrir, abrir e não entregar nada, ou abrir, entregar e depois morrer em silêncio.

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

Apanhe a primeira falha significativa antes de tocar num perfil, porque os três momentos apontam para camadas diferentes. Se o handshake nunca terminar, compare-o com um pedido HTTPS simples ao mesmo anfitrião para ver se algo o alcança. Se terminar e não chegarem mensagens, observe os quadros ou o corpo do fluxo enquanto alguém envia uma mensagem de teste a partir de outra conta. Se funcionar e depois parar, anote a hora exata e o código de fecho, porque esse par identifica que extremidade desistiu.

O código 1006 significa que a tomada fechou sem quadro de fecho, e é assim que um intermediário ou um tempo limite de inatividade se parece do interior do navegador. Um heartbeat da VPN não prova que a sessão interna da aplicação continua viva.

O anfitrião ao vivo é um destino separado

As costas do chat vivem frequentemente no seu próprio nome de anfitrião, por vezes noutra porta ou atrás de um certificado separado. Esse destino precisa da sua própria resolução, rota e tratamento de proxy, e a tunelagem dividida pode incluir a página e excluir a tomada. Resolva o nome do anfitrião ao vivo a partir da máquina cliente e confirme que responde com o endereço que espera nessa rede. Verifique a cadeia de certificados especificamente para esse nome de anfitrião, porque um wildcard que cobre o site não cobre sempre o ponto final da tomada.

Se houver um proxy no caminho, confirme que permite a atualização ou a resposta duradoura em vez de a colocar em memória intermédia. Os proxies empresariais que reescrevem HTML costumam tratar mal as atualizações WebSocket, o que produz uma página que é desenhada enquanto o chat nunca liga. Dois pedidos ao mesmo produto não são, por isso, dois pedidos ao mesmo anfitrião.

Corrija a lista de destinos, não as verificações de segurança

Corrigir uma lista de destinos é uma alteração de encaminhamento e pertence a quem é dono da rota. Relaxar a validação de certificados ou retirar o cabeçalho Origin é uma alteração de segurança e pertence a quem é dono da política, que raramente é a pessoa que está a depurar o pedido. A forma mais rápida de fazer uma ligação parecer bem-sucedida é, normalmente, a forma mais rápida de tornar um incidente possível.

Pergunte ao dono da aplicação que origens a parte de trás aceita antes de alterar seja o que for, e passe essa resposta a quem controla o proxy. Se um erro de certificado aparecer apenas através do túnel, inspecione o dispositivo que intercepta em vez de instalar um desvio.

Registe o suficiente para entregar

O artefacto útil é curto: URL da página, ponto final ao vivo, resultado do handshake, hora da primeira falha e se foi tentada uma religação. Acrescente o nome do perfil VPN e a rede em que estava, e qualquer leitor consegue reproduzir o teste sem fazer seis perguntas. Oculte cookies, cabeçalhos de autorização e corpos de mensagens, e prefira uma captura de ecrã da coluna de tempos a uma exportação completa do arquivo. Quadros e arquivos de rede podem conter mensagens privadas e tokens de sessão, por isso inspecione antes de anexar seja o que for.

Se a falha for um fecho silencioso, inclua o código de fecho e o intervalo de inatividade que o antecedeu, porque esse par identifica normalmente o dono do tempo limite. Entregue o registo ao dono da aplicação ou da porta de entrada em vez de adivinhar um valor de tempo limite. A resposta deles sobre o comportamento de keepalive suportado é a que fecha o pedido.