Soluzione della community

L'ID remoto di ZimaOS mostra NXDOMAIN: diagnosi di «Connessione del dispositivo non pronta»

A January 2026 ZimaBoard 2 case where local access worked but ZimaOS Remote ID never produced a public URL. Extensive community diagnostics ruled out basic DNS, time, routing, and outbound HTTPS, while logs repeatedly showed 401 invalid-or-expired-JWT errors during backend communication.

Un errore NXDOMAIN non significa sempre che il dispositivo ZimaOS abbia problemi con il DNS. In questo caso del gennaio 2026, la ZimaBoard 2 dell'utente funzionava normalmente sulla rete locale, ma ZimaOS Plus Remote Access non generava mai un URL pubblico e ZimaClient rimaneva bloccato sul messaggio Device connection not ready.

L'utente ha reimpostato il Network ID, riavviato il dispositivo, effettuato la disconnessione e il nuovo accesso e ha persino testato una build alpha 1.5.4. Nessuno di questi passaggi ha ripristinato il collegamento remoto nativo.

Il problema riguardava il provisioning remoto, non l'accesso locale

Il caso originale presentava tre sintomi collegati:

  • non compariva alcun URL pubblico zimaos.link sotto il Remote ID;
  • l'apertura del collegamento remoto previsto restituiva NXDOMAIN;
  • ZimaClient rimaneva in un ciclo di connessione e segnalava che la connessione al dispositivo non era pronta.

Nel frattempo, la ZimaBoard rimaneva raggiungibile tramite IP locale e continuava a fornire altri servizi locali non correlati.

L'aggiornamento alla versione alpha 1.5.4 non ha risolto il problema

Un membro della community ha suggerito di provare una build alpha. L'autore del post originale lo ha fatto, ha reimpostato nuovamente il Network ID e ha riprodotto lo stesso problema di accesso remoto. Si tratta di un elemento negativo utile: in questo caso, il semplice passaggio dalla versione 1.5.3 a quella build alpha non ha risolto il provisioning.

I vecchi comandi di aggiornamento della community curl | sh non vengono volutamente ripetuti qui. In questa discussione non erano stati pubblicati da un account del team IceWhale e fanno riferimento a build storiche.

DNS, ora, routing e HTTPS di base funzionavano tutti

I risultati diagnostici successivi sono stati particolarmente indicativi. La ZimaBoard riusciva a risolvere domini normali, effettuare il ping di IP pubblici, utilizzare una route predefinita valida, sincronizzare l'ora tramite NTP e raggiungere endpoint HTTPS pubblici. Nessuna unità systemd non funzionante o regola firewall in uscita evidente spiegava l'assenza dell'URL remoto.

Questo restringe notevolmente il campo. Rende molto meno convincente una spiegazione generica del tipo “il DNS non funziona”, anche se il sintomo visualizzato dal browser era NXDOMAIN.

L'indizio più forte erano i ripetuti errori JWT 401

I log dell'utente mostravano ripetutamente risposte HTTP 401 con il messaggio invalid or expired jwt mentre il sistema tentava di comunicare con il backend ZimaOS.

Un membro della community ha interpretato questo comportamento come un errore di autenticazione del backend o dell'handshake di registrazione del Remote ID. Gli elementi a sostegno sono solidi, ma la discussione non contiene una conferma da parte di un ingegnere IceWhale della causa principale lato server; pertanto, deve essere considerata una diagnosi della community e non una dichiarazione ufficiale relativa a un incidente.

L'utente ha creato una soluzione alternativa separata per Immich

Poiché l'accesso remoto nativo rimaneva indisponibile, l'utente ha reso Immich accessibile tramite port forwarding del router e DuckDNS. Questo ha ripristinato l'accesso a Immich tramite browser per la famiglia, ma non ha riparato il Remote ID di ZimaOS.

L'esposizione diretta di un'applicazione su Internet ne modifica il modello di sicurezza. Non adottare questa soluzione senza comprendere TLS, autenticazione, aggiornamenti dell'applicazione, regole firewall e l'eventuale disponibilità di un indirizzo pubblico raggiungibile fornito dal proprio ISP.

L'accesso remoto attuale di ZimaOS utilizza il flusso di connessione di ZimaClient

La documentazione attuale di ZimaOS descrive l'accesso remoto come un canale peer-to-peer crittografato, configurato tramite ZimaClient e controllato dall'impostazione Remote Access. Se un sistema attuale non riesce a stabilire questo canale, confronta il dispositivo con il flusso di connessione attuale di Remote Access prima di applicare procedure di risoluzione dei problemi provenienti da una discussione dell'epoca della versione 1.5.3.

Le versioni attuali di ZimaOS considerano inoltre il Network ID un'informazione sensibile per la connessione. Evita di pubblicarlo in screenshot o post di supporto.

Domande frequenti sul Remote ID di ZimaOS

NXDOMAIN dimostra che il resolver DNS locale non funziona?

No. Nel caso in esame, la risoluzione DNS ordinaria funzionava correttamente, mentre il record remoto di ZimaOS non era mai stato pubblicato.

La reimpostazione del Network ID ha risolto il problema?

No. L'utente ha generato nuovi ID più volte senza ottenere un URL pubblico.

Qual era l'indizio tecnico più forte?

Le ripetute risposte HTTP 401 del backend, che segnalavano un JWT non valido o scaduto, mentre DNS, ora, routing e connettività HTTPS normali funzionavano.

Un problema JWT del backend è stato confermato ufficialmente da IceWhale?

No. Questa conclusione derivava dall'analisi della community dei log dell'utente. La discussione pubblicata non includeva una diagnosi ufficiale lato server.