Porque é que o início de sessão do Home Assistant falha depois de reiniciar um proxy inverso?

Se o início de sessão no Home Assistant falhar apenas depois de reiniciar um proxy inverso, teste primeiro o início de sessão diretamente na LAN e mantenha a base de dados de utilizadores inalterada até isolar o caminho do proxy.

Um reinício do proxy pode alterar o endereço do contentor, as informações do cliente encaminhadas, o funcionamento do WebSocket, o destino DNS ou o backend upstream, sem alterar qualquer palavra-passe do Home Assistant. Por isso, eliminar contas e repor todas as sessões não são boas primeiras medidas. Compare o URL direto do Home Assistant com o nome de anfitrião normal através do proxy, guarde os erros do navegador e do proxy e determine se a falha ocorre antes da autenticação, durante o pedido de início de sessão ou quando o frontend abre a ligação persistente.

Comece por Separar a Autenticação do Home Assistant do Caminho do Proxy

Utilize a mesma conta conhecida como válida através do endereço local direto do Home Assistant e do nome de anfitrião público ou interno através do proxy. Se o início de sessão direto funcionar enquanto o caminho do proxy falhar, a conta e o estado de autenticação do Core estão provavelmente suficientemente saudáveis para não serem alterados. Se ambos os caminhos falharem, retome a investigação no Home Assistant, no estado restaurado ou nas próprias credenciais.

Num caso de início de sessão através de proxy inverso, o comportamento direto divergia do caminho Apache até os detalhes do WebSocket e do proxy serem corrigidos. Esse tipo de comparação entre acesso direto e através do proxy é mais esclarecedor do que alterar repetidamente as palavras-passe.

Registe o estado HTTP, a cadeia de redirecionamentos, o erro da consola do navegador, a resposta upstream do proxy e o carimbo temporal correspondente no registo do Home Assistant antes de alterar a configuração. Um erro 400 causado por um proxy não confiável, um WebSocket falhado, um redirecionamento para o esquema errado e uma palavra-passe inválida são falhas diferentes, mesmo que o ecrã apresente a mesma mensagem genérica de impossibilidade de ligação.

As Quatro Causas do Lado do Proxy Deixam Assinaturas Diferentes

As causas comuns são uma alteração do endereço de origem do proxy, que deixa de corresponder à regra de proxy confiável, alterações nos cabeçalhos encaminhados ou no esquema, uma falha no tratamento da atualização do WebSocket e o encaminhamento para o backend errado do Home Assistant. A recriação de um contentor do proxy pode alterar um destes elementos enquanto a própria instância do Home Assistant permanece estável.

Um caso recente de resolução de problemas de um proxy inverso mostra o Home Assistant a rejeitar tráfego encaminhado até o proxy imediato ser colocado no intervalo confiável correto. Essa verificação da identidade do proxy confiável é mais segura do que alargar permanentemente o intervalo: confirme qual é o endereço do proxy que chega efetivamente ao Home Assistant e confie apenas nesse limite.

Utilize as assinaturas abaixo e altere um ramo de cada vez. Não deixe um intervalo amplo de proxies confiáveis configurado após o teste; isso remove uma proteção importante contra endereços de cliente encaminhados falsificados.

Causa 1: O Reinício Alterou o Endereço de Origem do Proxy

• Assinatura: os pedidos são rejeitados imediatamente e os registos do Home Assistant identificam um proxy inverso não confiável.
• Verificação: compare a sub-rede/o endereço do contentor do proxy com o intervalo confiável configurado.
• SE–ENTÃO: se restaurar o intervalo confiável restrito correto resolver o início de sessão, mantenha inalterados o estado da conta e das sessões.

Causa 2: O Host ou o Esquema Encaminhado Já Não Corresponde à Origem Pública

• Assinatura: os redirecionamentos alternam entre HTTP/HTTPS ou entre nomes de anfitrião diferentes, ou os cookies parecem associados a uma origem inesperada.
• Verificação: compare o Host e o esquema encaminhado antes e depois do reinício.
• SE–ENTÃO: se corrigir esses valores resolver o ciclo de redirecionamento/início de sessão, a falha estava na identidade de entrada e não nos utilizadores do Home Assistant.

Causa 3: A Página de Início de Sessão Carrega, mas a Atualização do WebSocket Falha

• Assinatura: a interface estática carrega, mas depois o frontend desliga-se ou não consegue concluir a inicialização.
• Verificação: inspecione o pedido WebSocket no navegador e os cabeçalhos de atualização do proxy.
• SE–ENTÃO: se o acesso direto mantiver o WebSocket aberto enquanto o nome de anfitrião não o fizer, continue a investigação na camada do proxy.

Causa 4: O Proxy Aponta para um Backend Diferente ou Recém-Criado

• Assinatura: o servidor parece estar configurado de novo, os utilizadores conhecidos desaparecem ou o estado específico do servidor é diferente através do proxy.
• Verificação: compare o endereço upstream, a identidade da instância e o caminho de configuração.
• SE–ENTÃO: se o proxy chegar ao contentor ou à instância restaurada errada, corrija o encaminhamento antes de alterar os dados de autenticação.

Utilize o Comportamento do WebSocket para Evitar Classificar Erradamente uma Falha do Frontend como Falha de Início de Sessão

O frontend do Home Assistant depende de uma ligação WebSocket persistente após a troca HTTP inicial. Por isso, um proxy pode apresentar corretamente a página de início de sessão, mas falhar momentos depois, quando a ligação é atualizada ou quando tenta permanecer aberta. Os utilizadores descrevem frequentemente essa sequência como uma falha de início de sessão, porque ocorre imediatamente após o envio das credenciais.

Uma configuração de proxy inverso do Home Assistant num Synology chegava ao caminho de início de sessão, mas continuava a falhar até o tratamento da atualização do WebSocket ser corrigido. Verificar o comportamento da atualização do WebSocket através do proxy evita perder tempo a repor utilizadores quando o caminho de início de sessão HTTP já está saudável.

Se o socket falhar, valide o tratamento da atualização HTTP/1.1, os tempos limite, a terminação TLS, o nome de anfitrião e qualquer middleware de CDN ou autenticação à frente do proxy. Mantenha o conjunto de alterações restrito. Não adicione cabeçalhos não relacionados, copiados de outra pilha de proxy, sem que o pedido falhado demonstre por que são necessários.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Valide a Correção Através de Dois Reinícios do Proxy e de um Cliente Limpo

Depois de aplicar a correção correspondente, inicie e termine sessão através do nome de anfitrião normal, abra um painel durante tempo suficiente para confirmar que o WebSocket permanece estável e repita a operação numa janela de navegação privada ou num segundo cliente. Em seguida, reinicie o proxy duas vezes e reinicie o anfitrião do proxy se o endereço ou a rede do contentor fizerem parte da causa suspeita.

A comparação da ZimaSpace entre os caminhos LAN e remotos do Home Assistant aplica o mesmo princípio de isolamento: preserve o caminho local saudável da aplicação enquanto testa as camadas adicionais de DNS, TLS, proxy e encaminhamento utilizadas remotamente.

A correção está validada quando o início de sessão direto e através do proxy chegam ambos à mesma instância do Home Assistant, o endereço restrito esperado do proxy é confiável, os redirecionamentos preservam o esquema e o anfitrião pretendidos, o WebSocket permanece ativo durante a utilização normal e um reinício do proxy não altera o resultado. Escale a investigação para a autenticação do Home Assistant apenas quando a mesma conta conhecida como válida também falhar no caminho direto.