Ein NXDOMAIN-Fehler bedeutet nicht immer, dass der DNS-Dienst des ZimaOS-Geräts selbst ausgefallen ist. In diesem Fall aus dem Januar 2026 funktionierte das ZimaBoard 2 des Benutzers im lokalen Netzwerk normal, aber ZimaOS Plus Remote Access erzeugte nie eine öffentliche URL, und ZimaClient blieb bei Geräteverbindung nicht bereit.
Der Benutzer setzte die Netzwerk-ID zurück, startete das Gerät neu, meldete sich ab und wieder an und testete sogar einen Alpha-Build von Version 1.5.4. Keiner dieser Schritte stellte die native Remote-Verbindung wieder her.
Der Fehler lag bei der Remote-Bereitstellung, nicht beim lokalen Zugriff
Der ursprüngliche Fall wies drei miteinander verbundene Symptome auf:
- Unter der Remote-ID erschien keine öffentliche
zimaos.link-URL; - das Öffnen des erwarteten Remote-Links führte zu NXDOMAIN;
- ZimaClient blieb in einer Verbindungsschleife und meldete, dass die Geräteverbindung nicht bereit war.
Das ZimaBoard blieb unter seiner lokalen IP-Adresse erreichbar und stellte weiterhin andere lokale Dienste bereit.
Das Update auf 1.5.4 Alpha behob das Problem nicht
Ein Community-Mitglied schlug vor, einen Alpha-Build zu testen. Der ursprüngliche Verfasser tat dies, setzte die Netzwerk-ID erneut zurück und reproduzierte denselben Fehler beim Remote-Zugriff. Das ist ein wichtiges negatives Indiz: In diesem Fall behob der Wechsel von 1.5.3 zu diesem Alpha-Build die Bereitstellung nicht.
Die alten Community-Update-Befehle curl | sh werden hier bewusst nicht wiederholt. Sie stammten in diesem Thread nicht von einem IceWhale-Teamkonto und verwiesen auf historische Builds.
Grundlegendes DNS, die Zeit, das Routing und HTTPS funktionierten
Die späteren Diagnoseergebnisse waren ungewöhnlich aufschlussreich. Das ZimaBoard konnte normale Domains auflösen, öffentliche IP-Adressen anpingen, eine gültige Standardroute verwenden, die Zeit per NTP synchronisieren und öffentliche HTTPS-Endpunkte erreichen. Es gab keine fehlgeschlagenen systemd-Dienste und keine offensichtliche Sperre der ausgehenden Firewall, die die fehlende Remote-URL erklärt hätte.
Dadurch lässt sich das Problem deutlich eingrenzen. Eine allgemeine Erklärung wie „Ihr DNS ist defekt“ erscheint dadurch wesentlich weniger überzeugend, obwohl das Browsersymptom selbst NXDOMAIN war.
Das stärkste Indiz waren wiederholte 401-JWT-Fehler
In den Protokollen des Benutzers erschienen wiederholt HTTP-401-Antworten mit der Meldung invalid or expired jwt, während das System mit dem ZimaOS-Backend zu kommunizieren versuchte.
Ein Community-Responder wertete dies als fehlgeschlagenen Backend-Authentifizierungs- oder Remote-ID-Registrierungs-Handshake. Die Beweislage ist überzeugend, aber der Thread enthält keine Bestätigung der serverseitigen Ursache durch einen IceWhale-Ingenieur. Daher sollte dies als Community-Diagnose und nicht als offizielle Stellungnahme zu einem Vorfall betrachtet werden.
Der Benutzer richtete eine separate Immich-Workaround-Lösung ein
Da der native Remote-Zugriff weiterhin nicht verfügbar war, machte der Benutzer Immich über eine Portweiterleitung am Router und DuckDNS erreichbar. Dadurch konnten Familienmitglieder wieder über den Browser auf Immich zugreifen, die ZimaOS-Remote-ID wurde dadurch jedoch nicht repariert.
Das direkte Veröffentlichen einer Anwendung im Internet verändert deren Sicherheitsmodell. Übernehmen Sie diesen Workaround nicht, ohne TLS, Authentifizierung, Anwendungsupdates, Firewall-Regeln und die Frage zu berücksichtigen, ob Ihr Internetanbieter eine erreichbare öffentliche Adresse bereitstellt.
Der aktuelle ZimaOS-Remotezugriff verwendet den ZimaClient-Verbindungsablauf
Das aktuelle ZimaOS beschreibt den Remotezugriff als verschlüsselten Peer-to-Peer-Kanal, der über ZimaClient eingerichtet und über die Einstellung „Remotezugriff“ gesteuert wird. Wenn ein aktuelles System diesen Kanal nicht herstellen kann, vergleichen Sie das Gerät mit dem aktuellen Verbindungsablauf für den Remotezugriff, bevor Sie die Fehlerbehebung aus einem Thread aus der Zeit von Version 1.5.3 anwenden.
Das aktuelle ZimaOS behandelt die Netzwerk-ID außerdem als vertrauliche Verbindungsinformation. Vermeiden Sie es, sie in Screenshots oder Supportbeiträgen zu veröffentlichen.
FAQ zur ZimaOS-Remote-ID
Beweist NXDOMAIN, dass der lokale DNS-Resolver defekt ist?
Nein. In diesem Ausgangsfall funktionierte die normale DNS-Auflösung korrekt, während der ZimaOS-Remote-Eintrag selbst nie veröffentlicht wurde.
Hat das Zurücksetzen der Netzwerk-ID das Problem behoben?
Nein. Der Benutzer erzeugte mehrmals neue IDs, ohne eine öffentliche URL zu erhalten.
Was war das stärkste technische Indiz?
Wiederholte HTTP-401-Antworten des Backends mit dem Hinweis auf ein ungültiges oder abgelaufenes JWT, während normale DNS-, Zeit-, Routing- und HTTPS-Verbindungen funktionierten.
Wurde ein JWT-Problem im Backend von IceWhale offiziell bestätigt?
Nein. Diese Schlussfolgerung stammte aus der Analyse der Protokolle des Benutzers durch die Community. Der veröffentlichte Thread enthielt keine offizielle serverseitige Diagnose.
