Porque é que o Home Assistant perde as sessões após uma alteração no proxy ou no DNS?

A perda de sessão após uma alteração no proxy ou no DNS resulta normalmente de uma incompatibilidade entre a origem do URL utilizada pelo cliente e a rota que o Home Assistant vê agora, e não de contas de utilizador danificadas.

Um navegador pode ainda manter cookies e o estado do frontend relativos ao nome de anfitrião antigo, enquanto um telemóvel resolve o novo endereço, ou o proxy pode apresentar a página de início de sessão, mas falhar o WebSocket autenticado. Comece com uma janela privada e um teste direto através da LAN, registe o esquema e o nome de anfitrião exatos de cada resultado e evite eliminar todas as sessões até identificar a camada que está a falhar.

Separe o estado de um único cliente de uma falha do caminho partilhado

Abra o Home Assistant numa janela privada utilizando o URL final pretendido e compare-o com o navegador e a aplicação móvel afetados. Registe se o início de sessão é concluído, se o painel permanece ligado durante cinco minutos e se uma atualização da página mantém a sessão. Esta comparação reversível testa o estado desatualizado do cliente sem alterar o servidor.

Um proxy pode devolver a página de início de sessão enquanto o frontend autenticado comunica posteriormente que não consegue estabelecer ligação. Esta falha de ligação após início de sessão bem-sucedido demonstra por que motivo apresentar HTML não prova que todo o caminho da sessão funciona.

Se apenas o navegador antigo falhar e a janela privada permanecer estável, remova os dados do site relativos às origens antiga e nova do Home Assistant nesse cliente e inicie sessão novamente. Se todos os clientes falharem no URL do proxy, mas o acesso direto através da LAN funcionar, preserve o estado dos clientes e passe ao caminho do proxy.

Verifique o WebSocket e o processamento da origem reencaminhada

Inspecione a vista de rede do navegador ou o registo do proxy durante o início de sessão e observe a atualização para WebSocket, o estado, o momento da desligação, o esquema reencaminhado, o anfitrião reencaminhado e o endereço do cliente. A distinção útil é entre uma página HTTP que carrega e um canal autenticado persistente que é atualizado e permanece aberto.

A resolução de problemas de proxy inverso do Home Assistant identifica repetidamente o reencaminhamento de WebSocket como um requisito separado do proxy HTTP normal. Utilize esse mecanismo apenas para interpretar o caminho de atualização, não como prova de que uma configuração do Nginx serve para todos os proxies.

Se a atualização falhar, corrija apenas a rota do proxy, os cabeçalhos de atualização, o esquema reencaminhado ou o limite do proxy fidedigno que os registos indiquem estar incorreto. Se for bem-sucedida e permanecer ligada, não altere o proxy e investigue antes o DNS e o estado da origem no cliente.

Compare as respostas DNS e os URL finais

Resolva o nome de anfitrião do Home Assistant a partir do cliente que falha, de um cliente funcional e do anfitrião do proxy. Compare IPv4, IPv6, respostas de DNS dividido, nome do certificado, destino do redirecionamento e o URL guardado na aplicação complementar. Uma alteração de DNS só está concluída quando os clientes chegam ao endpoint pretendido utilizando o mesmo nome de anfitrião canónico.

A relação mais ampla entre descoberta, resolução de nomes e encaminhamento está representada no modelo de acessibilidade do Home Assistant. Utilize-o para separar uma resposta DNS desatualizada de uma falha na camada da sessão.

Se os clientes resolverem endpoints diferentes, aguarde o TTL documentado ou limpe a cache do resolvedor apenas no cliente afetado e no resolvedor local. Não crie nomes de anfitrião temporários concorrentes, pois cada origem adicional cria outro limite de cookies e redirecionamentos.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Volte a testar o caminho da sessão original e escale de forma limitada

Inicie sessão através do URL público ou privado final, mantenha um painel ativo aberto, recarregue uma vista aninhada, mude de rede uma vez se o acesso remoto fizer parte da configuração e repita após reiniciar um cliente. Um resultado positivo exige o mesmo URL canónico, um WebSocket estável e a manutenção da sessão após o acionador original.

Se o cliente limpo funcionar, mas um cliente existente continuar a falhar, repare apenas o perfil desse cliente ou a ligação da aplicação. Se todos os clientes do proxy falharem com as mesmas evidências de atualização ou redirecionamento, reverta a última alteração no proxy ou DNS e preserve os registos antes de tentar outra alteração.

Escale o problema com a classe exata do URL que falha, as respostas DNS, os códigos de estado do proxy, o resultado do WebSocket, os carimbos de data/hora e a comparação entre clientes. Pare quando dois clientes diferentes mantiverem as sessões após uma atualização e uma reconexão; alterações adicionais aos cookies ou ao proxy acrescentarão então risco sem valor de diagnóstico.