Ett NXDOMAIN-fel betyder inte alltid att DNS på själva ZimaOS-enheten har slutat fungera. I det här fallet från januari 2026 fungerade användarens ZimaBoard 2 normalt i det lokala nätverket, men ZimaOS Plus Remote Access skapade aldrig någon offentlig URL och ZimaClient fastnade på Enhetsanslutningen är inte klar.
Användaren återställde nätverks-ID:t, startade om enheten, loggade ut och in igen och testade till och med en alfaversion av 1.5.4. Inget av detta återställde den inbyggda fjärranslutningen.
Felet låg i fjärrprovisioneringen, inte i den lokala åtkomsten
Källfallet hade tre relaterade symtom:
- ingen offentlig
zimaos.link-URL visades under fjärr-ID:t; - den förväntade fjärrlänken gav NXDOMAIN när den öppnades;
- ZimaClient förblev i en anslutningsloop och rapporterade att enhetsanslutningen inte var klar.
Samtidigt förblev ZimaBoard-enheten nåbar via lokal IP-adress och fortsatte att tillhandahålla andra lokala tjänster.
Uppdatering till 1.5.4 Alpha löste inte problemet
En communitymedlem föreslog att testa en alfaversion. Den ursprungliga skribenten gjorde det, återställde nätverks-ID:t igen och återskapade samma problem med fjärråtkomsten. Det är användbar negativ evidens: i det här fallet löste en enkel uppgradering från 1.5.3 till den alfaversionen inte provisioneringen.
De gamla uppdateringskommandona för communityn i formatet curl | sh återges inte här med avsikt. De publicerades inte av ett IceWhale-teamkonto i den här tråden och hänvisar till historiska versioner.
Grundläggande DNS, tid, routing och HTTPS fungerade
De senare diagnostikresultaten var ovanligt informativa. ZimaBoard-enheten kunde slå upp vanliga domännamn, pinga offentliga IP-adresser, använda en giltig standardrutt, synkronisera tiden med NTP och nå offentliga HTTPS-slutpunkter. Inga misslyckade systemd-enheter eller uppenbara blockeringar av utgående trafik i brandväggen förklarade den saknade fjärr-URL:en.
Det begränsar problemet avsevärt. Det gör en generell förklaring som ”din DNS fungerar inte” betydligt mindre övertygande, även om webbläsarsymtomet i sig var NXDOMAIN.
Den starkaste ledtråden var upprepade 401-fel med JWT
Användarens loggar visade upprepade HTTP 401-svar med meddelandet invalid or expired jwt medan systemet försökte kommunicera med ZimaOS-backendservern.
En communitysvarare tolkade detta som ett misslyckat autentiseringsförsök mot backendservern eller ett misslyckat registreringshandslag för fjärr-ID:t. Bevisläget är starkt, men tråden innehåller ingen bekräftelse från en IceWhale-tekniker av den bakomliggande orsaken på serversidan. Det bör därför förbli en communitydiagnos och inte ett officiellt incidentuttalande.
Användaren byggde en separat Immich-lösning
Eftersom den inbyggda fjärråtkomsten fortfarande inte var tillgänglig gjorde användaren Immich åtkomligt genom portvidarebefordran i routern och DuckDNS. Det återställde familjens åtkomst till Immich via webbläsare, men reparerade inte ZimaOS Remote ID.
Att exponera en applikation direkt mot internet förändrar dess säkerhetsmodell. Kopiera inte den lösningen utan att förstå TLS, autentisering, programuppdateringar, brandväggsregler och om din internetleverantör tillhandahåller en nåbar offentlig adress.
Aktuell fjärråtkomst i ZimaOS använder ZimaClients anslutningsflöde
Aktuella versioner av ZimaOS beskriver fjärråtkomst som en krypterad peer-to-peer-kanal som konfigureras via ZimaClient och styrs av inställningen för fjärråtkomst. Om ett aktuellt system inte kan upprätta den kanalen bör du jämföra enheten med det aktuella anslutningsflödet för fjärråtkomst innan du använder felsökningsanvisningar från en tråd från tiden kring version 1.5.3.
Aktuella versioner av ZimaOS betraktar också nätverks-ID:t som känslig anslutningsinformation. Undvik att publicera det i skärmbilder eller supportinlägg.
Vanliga frågor om ZimaOS Remote ID
Bevisar NXDOMAIN att den lokala DNS-resolvern är trasig?
Nej. I det här källfallet fungerade vanlig DNS-upplösning korrekt, medan själva fjärrposten för ZimaOS aldrig publicerades.
Löste det problemet att återställa nätverks-ID:t?
Nej. Användaren skapade nya ID:n flera gånger utan att få någon offentlig URL.
Vilken var den starkaste tekniska ledtråden?
Upprepade HTTP 401-svar från backendservern med uppgift om en ogiltig eller utgången JWT, samtidigt som normal DNS-, tids-, routing- och HTTPS-anslutning fungerade.
Bekräftade IceWhale officiellt att det var ett JWT-problem i backendservern?
Nej. Den slutsatsen kom från communityns analys av användarens loggar. Den publicerade tråden innehöll ingen officiell diagnos av serverproblemet.
