Suspeite de um erro do cliente do Home Assistant quando um cliente falha, mas outro é bem-sucedido no mesmo caminho do servidor; suspeite do servidor quando a mesma operação falha em todo o lado.
Esta primeira distinção é mais eficaz do que limpar a cache ou reiniciar o Core por hábito. Um ecrã do Home Assistant depende do estado do navegador ou da aplicação, da rota de rede, do comportamento do proxy e do WebSocket, das APIs do Core, das integrações e, por vezes, do armazenamento. Crie uma matriz simples que mantenha o servidor e o URL constantes enquanto altera o cliente e, em seguida, mantenha o cliente constante enquanto altera a rota. A primeira dimensão que altera o erro identifica a camada seguinte a inspecionar.
Comece por testar o mesmo caminho com clientes diferentes
Abra o mesmo URL do Home Assistant e a mesma página num segundo navegador, num perfil privado, na aplicação complementar ou noutro dispositivo da mesma rede. Se um cliente falhar enquanto o segundo funciona imediatamente, o servidor já provou que consegue executar a operação através desse caminho, o que torna a cache, o armazenamento local, as extensões do navegador, os recursos personalizados do frontend ou a apresentação no cliente as hipóteses principais.
Um relatório do frontend de 2026 mostrou as definições a falharem num caminho de navegador, enquanto os outros modos de acesso se comportavam de forma diferente; os testes posteriores envolveram a cache e os controlos do navegador. Este tipo de comparação entre clientes é útil porque restringe a origem da falha antes de alterar a configuração do servidor.
Não declare o cliente culpado com base numa única atualização bem-sucedida. Repita a mesma ação várias vezes e preserve os erros da consola do navegador. Se todos os clientes falharem quando o mesmo cartão do painel ou os dados da integração forem carregados, o recurso comum do lado do servidor poderá ser o verdadeiro desencadeador.
Os erros do lado do cliente costumam mudar com a cache, o navegador ou um estado seguro do frontend
As falhas do cliente deixam frequentemente uma assinatura reconhecível: um navegador fica preso em recursos antigos, um cartão personalizado gera um erro de JavaScript ou a aplicação complementar comporta-se de forma diferente de um navegador limpo. Uma atualização forçada, um perfil privado ou as ferramentas de desenvolvimento do navegador podem alterar o resultado sem reiniciar o Home Assistant.
As orientações de resolução de problemas do frontend do Home Assistant tratam a cache do frontend como estado do navegador no lado do cliente. Utilize esta verificação como uma medida reversível, não como uma solução universal. Se limpar a cache não alterar nada em vários clientes, deixe de repetir o procedimento.
Quando o modo de segurança ou a remoção de um recurso de frontend de terceiros altera a página, mantenha a investigação nos cartões personalizados, temas ou recursos do navegador. Não reconfigure o Recorder nem substitua o SSD por uma falha exclusivamente de JavaScript. Por outro lado, se o cliente comunicar uma resposta 500 do servidor ou se todos os dispositivos perderem a mesma ação de uma entidade, avance para as camadas seguintes.
Os erros do lado do servidor repetem-se entre clientes e aparecem nos registos do Core ou da integração
Uma falha do lado do servidor normalmente mantém-se mesmo quando o cliente muda, porque o pedido chega à mesma operação de backend avariada. São exemplos uma integração que gera uma exceção, uma falha no acesso à base de dados, uma ação de automação que devolve um erro ou a indisponibilidade do Core. O navegador pode apresentar uma mensagem genérica, mas a linha correspondente no registo do Home Assistant identifica o responsável no lado do servidor.
Num caso da comunidade em que vários clientes de navegador e móveis acabaram por apresentar a mesma falha nas definições, a causa foi a remoção de uma integração de terceiros corrompida. A lição útil de ver o mesmo erro em clientes diferentes é que a reprodução entre clientes desloca o limite de diagnóstico de volta para o estado partilhado da aplicação.
Compare os carimbos de data e hora entre a ação do utilizador e os registos do Home Assistant. Se o cliente falhar, mas não houver qualquer registo no Core, o pedido poderá não ter chegado ao Home Assistant. Se o mesmo erro de API ou integração aparecer em todos os clientes, preserve a configuração do cliente e diagnostique o componente de backend.
Os erros de proxy, DNS e WebSocket ficam entre o cliente e o servidor
A falsa dicotomia mais comum é chamar problema do servidor do Home Assistant a qualquer problema que não seja do cliente. Um proxy inverso, um resolvedor DNS, uma VPN, um endpoint TLS ou uma atualização para WebSocket pode falhar depois de o navegador sair do dispositivo, mas antes de o Core processar o pedido. Esse caminho intermédio pode fazer um URL falhar enquanto o endereço local direto funciona.
Um guia independente sobre proxy inverso do Home Assistant mostra que o caminho público acrescenta cabeçalhos de cliente encaminhados e uma camada de atualização para WebSocket que o acesso direto pela LAN não utiliza. Esse caminho de entrada adicional pode falhar enquanto o mesmo servidor do Home Assistant continua acessível diretamente.
Compare o IP ou nome de anfitrião direto da LAN com o URL normal do proxy a partir do mesmo cliente. Se o acesso direto funcionar e o proxy falhar, preserve o Core e investigue o DNS, o TLS, a cache do proxy, os cabeçalhos encaminhados ou os WebSockets. Se ambos falharem de forma idêntica e os registos do servidor confirmarem o mesmo, volte a investigar dentro do Home Assistant.
Utilize uma matriz dois por dois antes de reiniciar o servidor
Teste o Cliente A e o Cliente B no Caminho 1 e, em seguida, o Cliente A e o Cliente B no Caminho 2. Registe o estado de carregamento da página, a resposta da API, o estado do WebSocket, o erro da consola do navegador e a entrada correspondente no registo do Home Assistant. Esta matriz simples separa padrões de falha exclusivos do cliente, exclusivos da rota e abrangentes ao servidor, com menos alterações destrutivas.
A análise da ZimaSpace sobre o comportamento do Home Assistant na LAN e remotamente utiliza a mesma separação de caminhos quando a capacidade de resposta percebida muda entre clientes ou rotas de entrada.
Considere o diagnóstico concluído quando uma variável alterar o erro de forma consistente e a correção proposta modificar apenas essa camada. Reinicie o Core apenas quando as evidências apontarem para o servidor ou quando o reinício fizer parte da validação após a correção. Ao pedir ajuda, inclua a matriz guardada e os registos quando as quatro combinações falharem de formas diferentes, pois esse padrão significa frequentemente que está envolvida mais do que uma dependência.
Suporte e Dicas
Mais para Ler

O Home Assistant pode partilhar uma GPU ou acelerador com outro contentor?
A partilha da GPU depende da carga de trabalho: os contentores podem frequentemente partilhar nós de renderização, enquanto a passagem da GPU inteira para...

Como configurar a cache e o armazenamento temporário do Home Assistant
Mantenha o estado persistente do Home Assistant em armazenamento durável; utilize tmpfs apenas para caminhos comprovadamente descartáveis e dimensione-o dentro do orçamento de memória...

Como impedir que as cópias de segurança do Home Assistant capturem um estado inconsistente da base de dados
Utilize cópias de segurança compatíveis com o Home Assistant para sistemas em funcionamento; se criar cópias diretas dos ficheiros, coloque a base de dados...

