La tua applicazione UniFi Network non ha bisogno di un proprio indirizzo 192.168.x.x solo perché Docker assegna al container un indirizzo bridge 172.x. In modalità bridge normale, pubblica le porte host richieste e configura l’Inform Host di UniFi con un hostname o un indirizzo IP raggiungibile dalla LAN. I dispositivi sulla LAN comunicano con l’indirizzo dell’host, mentre Docker mantiene il container sulla propria rete privata.
Il thread di origine del 2026 confondeva l’IP bridge interno del container con l’indirizzo che i dispositivi LAN devono utilizzare. La documentazione attuale di LinuxServer lo chiarisce esplicitamente: il container UniFi può rimanere in modalità bridge e l’adozione dei dispositivi viene gestita impostando un Inform Host accessibile e mantenendo la porta 8080.
Perché visualizzi un indirizzo 172.x
Le reti bridge di Docker assegnano normalmente indirizzi privati ai container, come 172.17.x.x. Questo indirizzo serve per la rete del container, non è l’indirizzo che switch e access point devono usare dalla LAN fisica.
Usa l’indirizzo IP dell’host ZimaOS per le porte pubblicate
Se il server ZimaOS è 192.168.1.20 e UniFi pubblica le porte 8443 e 8080, accedi all’interfaccia e all’endpoint inform tramite l’host:
https://192.168.1.20:8443
http://192.168.1.20:8080/informImposta l’Inform Host di UniFi
L’attuale documentazione LinuxServer per UniFi indica che gli utenti Docker devono impostare l’Inform Host/Override su un hostname o un indirizzo IP raggiungibile dai dispositivi UniFi.
Di solito si tratta dell’indirizzo IP LAN di ZimaOS o di un nome DNS locale stabile.
Mantieni la mappatura 1:1 della porta 8080
LinuxServer avverte che la comunicazione con i dispositivi UniFi prevede 8080:8080, a meno che non vengano apportate modifiche corrispondenti anche nelle proprietà di sistema di UniFi. Non mappare senza criterio la porta host 18080 sulla porta container 8080 aspettandoti che l’adozione rimanga stabile.
La modalità host non equivale a “assegnare al container un proprio IP LAN”
La modalità host di Docker fa condividere al container lo spazio dei nomi di rete dell’host. Non crea un secondo indirizzo 192.168.x.x per il container.
Se hai davvero bisogno di un IP LAN separato, devi adottare una configurazione macvlan/ipvlan, che introduce alcune limitazioni di routing e di comunicazione tra host e container.
La modalità bridge è generalmente la scelta più semplice
La modalità bridge mantiene l’app isolata, rende esplicita la gestione delle porte e funziona con l’override documentato dell’Inform Host. Nella maggior parte dei casi è sufficiente per l’adozione e la gestione del controller.
Ricorda il requisito di MongoDB esterno
L’attuale UniFi Network Application di LinuxServer richiede un’istanza MongoDB esterna. Se la modalità host non funziona mentre quella bridge sì, verifica che il nome host di MongoDB e il percorso di rete rimangano validi nella modalità di rete selezionata.
Non esporre direttamente il controller a Internet
Mantieni la gestione sulla LAN o dietro una rete privata per l’accesso remoto. La guida alla rete privata offre il contesto più sicuro per la configurazione di rete.
Usa un indirizzo host stabile
Poiché ai dispositivi adottati viene comunicato dove trovare il controller, assegna all’host ZimaOS un IP LAN stabile tramite una prenotazione DHCP sul router o un indirizzo statico gestito con attenzione. Se l’host del controller passa da 192.168.1.20 a un altro indirizzo, i dispositivi potrebbero continuare a contattare il vecchio endpoint inform.
Comprendi quali porte servono per ciascuna funzione
L’interfaccia web UniFi sulla porta 8443 è solo una parte della configurazione. Il traffico inform dei dispositivi utilizza la porta 8080, mentre altri servizi di rilevamento/STUN usano porte aggiuntive a seconda della distribuzione. Di conseguenza, un controller può sembrare funzionante nel browser mentre i dispositivi non riescono a completare l’adozione.
Consulta la tabella delle porte aggiornata di LinuxServer ed esponi solo quelle necessarie nel tuo ambiente, mantenendo però esattamente le porte richieste per la gestione dei dispositivi.
Ripristina da Synology con attenzione
Se stai trasferendo il controller da Synology, ripristina un backup UniFi solo dopo aver verificato che il nuovo container ZimaOS e MongoDB esterno funzionino correttamente. In seguito, verifica l’Inform Host e lo stato dei dispositivi prima di spegnere il vecchio controller.
Non eseguire due controller attivi che rivendicano gli stessi siti o dispositivi durante la migrazione, a meno che tu non conosca le conseguenze sull’adozione.
Quando è effettivamente utile un IP LAN dedicato
Un indirizzo macvlan/ipvlan può essere utile per una segmentazione firewall rigorosa, per evitare conflitti tra porte o per far apparire il controller come un’appliance separata. Non è necessario semplicemente perché Docker mostra un indirizzo interno 172.x.
Se scegli macvlan, considera la comune limitazione della comunicazione tra host e macvlan e verifica che MongoDB rimanga raggiungibile dalla rete del controller.
Domande frequenti
Il container UniFi ha bisogno di un IP LAN 192.168?
No. In molte distribuzioni sono sufficienti la modalità bridge, le porte pubblicate e un Inform Host raggiungibile.
Perché i dispositivi UniFi non riescono a completare l’adozione in Docker?
Una causa comune è la pubblicizzazione di un IP del container non raggiungibile. Imposta l’Inform Host sull’indirizzo LAN di ZimaOS o su un altro hostname raggiungibile.
Devo usare la rete host?
Solo se hai una motivazione precisa. La modalità host condivide la rete dell’host ZimaOS, ma non crea un IP LAN dedicato.
Quando dovrei usare macvlan?
Usalo solo quando il container ha davvero bisogno di una propria identità sulla LAN e comprendi la maggiore complessità di routing e accesso dall’host.
