Um erro NXDOMAIN nem sempre significa que o DNS do próprio dispositivo ZimaOS está avariado. Neste caso de janeiro de 2026, o ZimaBoard 2 do utilizador funcionava normalmente na rede local, mas o Acesso remoto do ZimaOS Plus nunca gerava um URL público e o ZimaClient permanecia em A ligação do dispositivo não está pronta.
O utilizador repôs o ID de rede, reiniciou o dispositivo, terminou e iniciou novamente a sessão e até testou uma versão alfa 1.5.4. Nenhum desses passos repôs a ligação remota nativa.
A falha estava no aprovisionamento remoto, não no acesso local
O caso original apresentava três sintomas relacionados:
- não aparecia nenhum URL público
zimaos.linksob o ID remoto; - abrir a ligação remota esperada devolvia NXDOMAIN;
- o ZimaClient permanecia num ciclo de ligação e indicava que a ligação do dispositivo não estava pronta.
Entretanto, o ZimaBoard continuava acessível através do IP local e continuava a disponibilizar outros serviços locais não relacionados.
A atualização para a versão alfa 1.5.4 não resolveu o problema
Um membro da comunidade sugeriu testar uma versão alfa. O autor original fê-lo, repôs novamente o ID de rede e reproduziu a mesma falha de acesso remoto. Isto constitui uma evidência negativa útil: neste caso, passar simplesmente da versão 1.5.3 para essa versão alfa não resolveu o aprovisionamento.
Os comandos de atualização antigos curl | sh não são repetidos aqui intencionalmente. Não foram publicados por uma conta da equipa da IceWhale nesta discussão e referem-se a versões históricas.
O DNS, a hora, o encaminhamento e o HTTPS básicos funcionavam
Os resultados de diagnóstico posteriores foram particularmente esclarecedores. O ZimaBoard conseguia resolver domínios normais, fazer ping a IPs públicos, utilizar uma rota predefinida válida, sincronizar a hora através de NTP e aceder a pontos finais HTTPS públicos. Não havia unidades systemd com falhas nem um bloqueio óbvio da firewall às ligações de saída que explicasse a ausência do URL remoto.
Isto restringe significativamente o problema. Torna muito menos convincente a explicação genérica de que “o seu DNS está avariado”, apesar de o sintoma apresentado pelo navegador ser NXDOMAIN.
A pista mais forte foram os erros 401 JWT repetidos
Os registos do utilizador mostravam repetidamente respostas HTTP 401 com a mensagem invalid or expired jwt enquanto o sistema tentava comunicar com o backend do ZimaOS.
Um membro da comunidade interpretou isso como uma falha na autenticação do backend ou no processo de registo do ID remoto. As evidências são fortes, mas a discussão não contém a confirmação de um engenheiro da IceWhale sobre a causa principal no lado do servidor. Por isso, deve ser considerado um diagnóstico da comunidade, e não uma declaração oficial sobre um incidente.
O utilizador criou uma solução alternativa separada para o Immich
Como o Acesso remoto nativo continuava indisponível, o utilizador expôs o Immich através do reencaminhamento de portas no router e do DuckDNS. Isso repôs o acesso ao Immich através do navegador da família, mas não reparou o ID remoto do ZimaOS.
A exposição direta de uma aplicação à internet altera o respetivo modelo de segurança. Não adote essa solução sem compreender o TLS, a autenticação, as atualizações da aplicação, as regras da firewall e se o seu ISP disponibiliza um endereço público acessível.
O acesso remoto atual do ZimaOS utiliza o fluxo de ligação do ZimaClient
O ZimaOS atual descreve o acesso remoto como um canal ponto a ponto encriptado, configurado através do ZimaClient e controlado pela definição Acesso remoto. Se um sistema atual não conseguir estabelecer esse canal, compare o dispositivo com o fluxo atual de ligação do Acesso remoto antes de aplicar procedimentos de resolução de problemas de uma discussão da época da versão 1.5.3.
O ZimaOS atual também considera o ID de rede informações de ligação sensíveis. Evite publicá-lo em capturas de ecrã ou publicações de suporte.
Perguntas frequentes sobre o ID remoto do ZimaOS
NXDOMAIN prova que o resolvedor DNS local está avariado?
Não. Neste caso de origem, a resolução DNS normal funcionava corretamente, enquanto o próprio registo remoto do ZimaOS nunca era publicado.
A reposição do ID de rede resolveu o problema?
Não. O utilizador gerou novos IDs várias vezes sem obter um URL público.
Qual foi a pista técnica mais forte?
Respostas HTTP 401 repetidas do backend, indicando um JWT inválido ou expirado, enquanto o DNS, a hora, o encaminhamento e a conectividade HTTPS normais funcionavam.
Foi oficialmente confirmado pela IceWhale um problema de JWT no backend?
Não. Essa conclusão resultou da análise da comunidade aos registos do utilizador. A discussão publicada não incluía um diagnóstico oficial no lado do servidor.
