La risoluzione del problema è insolitamente chiara: non si trattava di un errore di Docker che interessava tutte le applicazioni. L’utente aveva configurato Tailscale con un nodo di uscita, dopodiché Jellyfin e gli URL delle altre applicazioni avevano smesso di funzionare anche sulla rete locale. In seguito ha disinstallato Tailscale, si è connesso tramite l’indirizzo IP LAN di ZimaOS e ha riferito che tutto aveva ripreso a funzionare.
Questo comportamento corrisponde alla documentazione attuale di Tailscale. Quando un client utilizza un nodo di uscita, l’accesso alla LAN locale è disabilitato per impostazione predefinita, a meno che non sia attivata l’opzione Consenti accesso alla rete locale. Prima di reinstallare le applicazioni o riavviare Docker, verifica la tabella di routing e se il client sta intenzionalmente inviando il traffico attraverso un nodo di uscita.
Anche le porte dirette delle app non funzionavano
L’utente ha provato ad aprire direttamente le porte delle applicazioni e ha detto che nessuna funzionava, tranne Tailscale. È un indizio utile: quando più container indipendenti diventano irraggiungibili contemporaneamente, verifica prima i livelli di rete e routing condivisi, invece di presumere che ogni applicazione si sia guastata autonomamente.
Un comando di riavvio di Docker non riuscito era una distrazione
ZimaOS non è un sistema Debian generico su cui si applica ogni comando di gestione dei servizi trovato nei tutorial online. Se tutte le app non funzionano, verifica innanzitutto che i container siano effettivamente in esecuzione e che le relative porte pubblicate siano raggiungibili dall’host o dalla LAN.
I nodi di uscita modificano la route predefinita del client
I nodi di uscita Tailscale instradano il traffico Internet generale attraverso un altro dispositivo della tailnet. La documentazione attuale di Tailscale specifica chiaramente che l’accesso alla rete locale è disattivato per impostazione predefinita quando si utilizza un nodo di uscita.
Consulta il comportamento attuale dei nodi di uscita Tailscale.
Attiva Consenti accesso alla rete locale quando ti servono entrambe le connessioni
I client Tailscale attuali offrono l’opzione Consenti accesso alla rete locale. Nei client basati sulla CLI, l’equivalente può essere configurato con il flag per consentire l’accesso alla LAN tramite il nodo di uscita.
Attivala solo quando la rete locale è considerata attendibile.
Disattiva il nodo di uscita per isolare il problema
Una verifica rapida consiste nel selezionare Nessuno come nodo di uscita attivo e riprovare a utilizzare l’IP LAN di ZimaOS insieme alla porta di un’app. Se l’accesso locale torna immediatamente disponibile, il punto più utile da indagare è la configurazione del routing, non Docker.
L’autore originale ha rimosso Tailscale e confermato il ripristino
L’utente ha riferito che il computer si disconnetteva dal router o dal percorso tramite IP locale quando si connetteva usando la configurazione Tailscale. Dopo aver disinstallato Tailscale e utilizzato l’IP locale, tutte le app hanno ripreso a funzionare.
Si tratta di un ripristino confermato dalla fonte, anche se l’utente non ha documentato i flag esatti del nodo di uscita che hanno causato il comportamento errato.
Un ordine di troubleshooting migliore
- apri direttamente la dashboard di ZimaOS tramite l’IP LAN;
- verifica se una porta dell’app funziona localmente;
- disattiva il nodo di uscita Tailscale attivo;
- riprova ad accedere all’app localmente;
- solo dopo controlla i log di Docker o dell’app se le porte sono ancora indisponibili.
FAQ: Service Unavailable per tutte le app
La reinstallazione delle app ha risolto il problema originale?
No. Le app hanno iniziato a funzionare solo dopo la rimozione dello stato di routing problematico di Tailscale.
Un nodo di uscita Tailscale può bloccare l’accesso alla LAN locale?
Sì. La documentazione attuale di Tailscale afferma che l’accesso alla LAN è disabilitato per impostazione predefinita quando si utilizza un nodo di uscita, a meno che l’utente non abiliti l’accesso alla rete locale.
È stato confermato che Docker fosse guasto?
No. La risoluzione originale indica un problema di routing, non un guasto del demone Docker.
