Dopo aver cambiato ISP e reinstallato ZimaOS, un membro della community ha scoperto che l’host riusciva a eseguire il ping di siti Internet e a scaricare le immagini dall’App Store, mentre le applicazioni nei container non riuscivano a raggiungere i servizi esterni. qBittorrent non riusciva a scaricare e Jellyfin non riusciva a recuperare i metadati.
Il caso originale è stato risolto spostando i container interessati dalla rete bridge alla modalità host. Risposte successive hanno documentato un secondo caso con sintomi simili ma una causa diversa: come gateway era stato inserito un indirizzo WAN pubblico e, inoltre, il percorso dell’ISP dell’utente richiedeva IPv6 insieme a IPv4 per Jellyfin.
La connettività dell’host non dimostrava quella dei container
L’autore poteva usare il terminale web di ZimaOS e installare app, dimostrando che il sistema operativo disponeva di un percorso in uscita funzionante. Ciò non dimostrava che ogni rete Docker avesse un instradamento corretto. Pertanto, i problemi delle app dovevano essere verificati dal lato del container, invece di essere dedotti dall’host.
Il membro del team Zima Giorgio ha suggerito di testare la connettività tramite un container browser e di provare un’altra modalità di rete dal pannello delle impostazioni dell’applicazione. Il post osserva inoltre che gli store di terze parti, l’installazione tramite YAML e l’installazione tramite CLI possono fornire applicazioni diagnostiche, ma si tratta di opzioni e non di requisiti confermati.
La modalità host ha risolto il caso originale relativo alla rete bridge
L’autore ha spostato tutti i container interessati in modalità host e ha riferito che l’accesso a Internet ha iniziato a funzionare. La discussione non determina perché la modalità bridge abbia smesso di funzionare dopo l’installazione pulita; pertanto, la modalità host va considerata la modifica riuscita per questa configurazione, non una prova di un difetto generale della rete bridge.
Un partecipante successivo ha segnalato un effetto collaterale importante: dopo il cambio di modalità, il collegamento nel pannello di controllo potrebbe continuare a puntare alla vecchia porta pubblicata sull’host. Nel caso di Jellyfin, il partecipante ha dovuto aprire direttamente la porta 8096, poiché il pannello continuava ad aprire la porta 8097.
Un caso successivo ha rivelato un gateway errato
I log di Jellyfin del secondo utente contenevano No route to host durante il tentativo di contattare un servizio esterno per i metadati. I membri della community hanno consigliato di eseguire il test senza VPN e di controllare il gateway mostrato nelle impostazioni di rete di ZimaOS.
Uno screenshot ha rivelato che il gateway configurato era l’indirizzo WAN pubblico dell’utente. Le risposte hanno spiegato che il gateway doveva invece essere l’indirizzo del router locale sulla stessa sottorete LAN. L’utente ha corretto il gateway e ha inoltre abilitato IPv6 insieme a IPv4 in Jellyfin, poiché la sua connessione AT&T preferiva IPv6. Ha quindi confermato che il recupero dei metadati e delle immagini funzionava.
Mantieni separati i due risultati della community
- Caso originale di ottobre 2025: la rete bridge non funzionava per i container dell’autore; la modalità host ha ripristinato l’accesso.
- Caso successivo di gennaio 2026: il gateway era configurato come IP pubblico e Jellyfin doveva inoltre avere IPv6 abilitato per quel percorso ISP.
Entrambi i casi hanno prodotto il sintomo generale “le app non riescono ad accedere a Internet”, ma non condividevano un’unica causa principale verificata. La discussione supporta il controllo della modalità di rete, dell’indirizzo utilizzato dopo il cambio di modalità, della configurazione del gateway, dell’influenza della VPN e della disponibilità dei protocolli come rami di indagine separati.
FAQ
Perché ZimaOS riesce a scaricare le app mentre un container rimane offline?
L’host e un container Docker possono utilizzare configurazioni di rete e instradamenti diversi. Nel caso originale, la connettività dell’host rimaneva funzionante mentre le applicazioni collegate alla rete bridge non riuscivano a comunicare.
Passare Jellyfin alla modalità host mantiene la vecchia porta del pannello di controllo?
Non necessariamente. Un partecipante ha riscontrato che il pannello continuava a collegarsi alla porta 8097, mentre Jellyfin in modalità host era raggiungibile direttamente sulla porta 8096.
