Se Sonarr, Radarr, Lidarr, Transmission o altri container su ZimaOS riescono a raggiungersi tramite indirizzo IP, ma non possono usare nomi stabili come transmission:9091; il problema riguarda solitamente la risoluzione dei nomi, non la connettività di base tra i container. Questa distinzione è diventata il risultato chiave di questa discussione della community IceWhale del novembre 2025.
La rete predefinita di Docker bridge La rete non fornisce la risoluzione DNS automatica dei nomi dei container allo stesso modo di una rete bridge definita dall'utente. La discussione ha poi messo in luce una seconda complicazione specifica di ZimaOS: le reti bridge create manualmente potevano esistere in Docker prima di comparire correttamente nella WebUI di ZimaOS, e l'interfaccia poteva rifiutare reti Docker altrimenti valide a causa delle aspettative relative alle etichette Compose.
Il sintomo principale: l'IP funziona, ma il nome del container non funziona
L'utente originale voleva che Radarr raggiungesse Transmission utilizzando:
http://transmission:9091Gli indirizzi IP dei container cambiavano dopo i riavvii o gli aggiornamenti, quindi inserirli manualmente non era affidabile. I container riuscivano a raggiungersi tramite IP, ma le chiamate basate sul nome host fallivano.
Perché la rete bridge Docker predefinita non risolve il problema
L'attuale documentazione Docker sulle reti bridge afferma che i container sulla rete bridge predefinita possono comunicare tramite IP, mentre le reti bridge definite dall'utente forniscono la risoluzione DNS automatica tra i container.
Quindi, «tutte le app usano bridge» non significa necessariamente che stiano usando una rete bridge definita dall'utente con il DNS integrato di Docker.
Crea una rete bridge definita dall'utente
sudo -i
docker network create media-netI container collegati alla stessa rete bridge definita dall'utente possono normalmente risolversi a vicenda tramite il nome del container o l'alias di rete.
La documentazione attuale di ZimaOS utilizza lo stesso schema
La documentazione attuale di ZimaSpace utilizza esplicitamente una rete personalizzata nella guida a Zabbix, perché la rete bridge predefinita non offre il comportamento DNS desiderato per i container:
sudo docker network create zabbix-netConsulta l’attuale guida all’installazione di ZimaOS Zabbix.
Il problema specifico di ZimaOS: sincronizzazione della WebUI
Nel thread di origine, la creazione di una bridge personalizzata tramite Docker o Portainer non rendeva immediatamente la rete utilizzabile dalle impostazioni dell’app ZimaOS. Gli utenti visualizzavano errori come:
la rete internal-network è stata trovata, ma ha un’etichetta non corretta
com.docker.compose.network impostato su ""Dopo aver effettuato i test con un ingegnere, Zima-Giorgio ha affermato che il networking di Docker funzionava normalmente, ma che la WebUI poteva non essere sincronizzata con il backend Docker.
Il passaggio confermato dalla community: riavviare dopo aver creato la rete
sudo -i
docker network create net-a
docker network create net-b
riavvioDopo il riavvio, le reti appena create sono comparse nel pannello delle impostazioni dell’app. Un altro partecipante ha confermato che il riavvio mancante era il passaggio fondamentale nel suo test e che in seguito la risoluzione dei nomi funzionava sulla bridge personalizzata.
Docker standard normalmente non richiede il riavvio dell’intero host dopo docker network create; si trattava di un comportamento specifico di ZimaOS osservato nel thread del 2025.
Era ancora presente un problema di compatibilità delle etichette di Compose
Anche dopo il riavvio, che aveva chiarito il problema di sincronizzazione, rimaneva un’altra limitazione. ZimaOS poteva segnalare che una rete creata manualmente aveva un’ com.docker.compose.network etichetta.
Zima-Giorgio ha infine affermato che l’impossibilità di scegliere alcune reti create sembrava essere un problema e che sarebbe stato sottoposto al team. Nel thread non è presente una conferma successiva che tutti i casi limite relativi alla selezione delle reti siano stati risolti.
Verifica la rete da Docker, non solo dall’interfaccia
docker network inspect media-net
docker inspect CONTAINER_A
docker inspect CONTAINER_BQuindi testa la risoluzione dei nomi da un container:
docker exec CONTAINER_A ping -c 2 CONTAINER_BSe l’immagine non include pingusa un altro strumento diagnostico disponibile o un container di test temporaneo sulla stessa rete.
Usa nomi o alias invece di modificare gli indirizzi IP
Quando il DNS Docker funziona su un bridge definito dall’utente, configura le applicazioni con un endpoint stabile come:
http://transmission:9091o un alias di rete definito in Compose.
Cloudflared era la causa?
La discussione di origine non ha identificato Cloudflared come causa principale. La comunicazione tramite IP funzionava già e il problema era coerente con il comportamento del DNS e della risoluzione dei nomi di Docker.
Soluzione temporanea: IP dell’host e porte pubblicate
L’autore del post originale aveva temporaneamente riservato un IP LAN statico per l’host ZimaOS e configurato le app affinché usassero quell’IP insieme alle porte pubblicate. Questo può funzionare, ma instrada il traffico attraverso il percorso delle porte pubblicate dell’host invece di usare il routing interno a Docker basato sui nomi stabili dei servizi.
Checklist per la risoluzione dei nomi dei container ZimaOS
- Conferma che la comunicazione IP-IP funzioni.
- Controlla se i container si trovano sul bridge predefinito o su un bridge denominato definito dall’utente.
- Crea un bridge personalizzato quando è richiesto un DNS stabile.
- Collega tutti i servizi necessari alla stessa rete personalizzata.
- Nelle versioni di ZimaOS corrispondenti alla discussione di origine, riavvia il sistema affinché la WebUI aggiorni lo stato della rete Docker.
- Verifica con
docker inspectedocker network inspect. - Testa la risoluzione del nome del container dall’interno di un altro container.
- Se ZimaOS segnala una mancata corrispondenza dell’etichetta Compose, considerala un problema dell’interfaccia o dell’integrazione, non una prova che la rete Docker non sia valida.
FAQ sul bridge dei container ZimaOS
Perché i container sul bridge non riescono a risolversi a vicenda per nome?
Il bridge predefinito di Docker consente la comunicazione tramite IP, ma non fornisce la risoluzione DNS automatica dei nomi dei container come un bridge definito dall’utente.
Devo riavviare dopo docker network create?
Di norma Docker non lo fa. In questa discussione del 2025 su ZimaOS, era necessario riavviare per consentire alla WebUI di ZimaOS di recuperare il nuovo stato della rete.
Cloudflared interrompe il DNS del bridge Docker?
La discussione di origine non lo ha stabilito.
Devo assegnare IP Docker statici?
Di solito no. I DNS e gli alias Docker definiti dall’utente sono più portabili degli IP dei container codificati staticamente.
