WebSocket 1006 não diz qual elo quebrou
Leia o fechamento anormal do WebSocket como falta de prova do Close handshake e depois determine se falhou a configuração do proxy ou uma sessão já estabelecida.
O código 1006 do WebSocket indica um fechamento anormal sem o quadro Close esperado. Está reservado: um endpoint não deve enviar 1006 como estado num quadro Close de WebSocket. Vê-lo num evento de API não é uma mensagem do servidor que aponte o proxy como causa.
Se a conexão nunca abriu
Siga a configuração por ordem: conexão ao proxy, negociação do proxy, TLS de destino para WSS e depois o handshake de abertura do WebSocket. Um desafio do proxy ou uma recusa de túnel podem parar a sequência antes da etapa WebSocket.
Se abriu e transportou mensagens
Registe a duração útil e o que aconteceu antes do fechamento. Uma interrupção do transporte, o encerramento da aplicação e a política de um intermediário podem deixar o recetor sem uma troca de fechamento limpa.
Preserve o endpoint, o identificador de sessão, a última atividade e se foi observado um quadro Close normal. Compare os erros de rede do navegador ou da biblioteca com os registos de destino que controla. Apenas o código do evento não consegue identificar o fornecedor, o operador do proxy ou o servidor de aplicação como origem.
Uma página HTTPS normal através do mesmo proxy testa uma troca curta, não o tempo de vida desta sessão. Mantenha estáveis o estado do navegador e o código da aplicação ao mudar de rota; caso contrário, uma nova tentativa bem-sucedida é difícil de interpretar.
Repare o limite que as provas sustentam. A autenticação do proxy, a confiança no TLS e a reconexão da aplicação são trabalhos separados, e aumentar todos os tempos limite não faz o 1006 identificar um deles.