Din UniFi Network Application behöver inte en egen 192.168.x.x-adress bara för att Docker ger containern en 172.x-bryggadress. I normalt bryggläge publicerar du de nödvändiga värdportarna och konfigurerar UniFi:s Inform Host till ett värdnamn eller en IP-adress som kan nås från LAN-nätverket. Enheter på LAN-nätverket kommunicerar med värdadressen, medan Docker behåller containern i sitt privata nätverk.
Tråden från 2026 blandade ihop containerns interna brygg-IP med adressen som LAN-enheter ska använda. Den aktuella dokumentationen från LinuxServer tar uttryckligen upp detta: UniFi-containern kan fortsätta köras i bryggläge, och enhetsadoption hanteras genom att ange en åtkomlig Inform Host och bevara port 8080.
Varför du ser en 172.x-adress
Dockers bryggnätverk tilldelar normalt privata containeradresser som 172.17.x.x. Den adressen används för containerkommunikation, inte som adressen som dina switchar och åtkomstpunkter ska använda från det fysiska LAN-nätverket.
Använd ZimaOS-värdens IP för publicerade portar
Om ZimaOS-servern har adressen 192.168.1.20 och UniFi publicerar 8443 och 8080, använder du värden för att komma åt gränssnittet och inform-endpointen:
https://192.168.1.20:8443
http://192.168.1.20:8080/informAnge UniFi:s Inform Host
Den aktuella UniFi-dokumentationen från LinuxServer säger att Docker-användare bör ange Inform Host/Override till ett värdnamn eller en IP-adress som UniFi-enheter kan nå.
Det är vanligtvis ZimaOS LAN-IP eller ett stabilt lokalt DNS-namn.
Behåll port 8080 mappad 1:1
LinuxServer varnar för att UniFi-enheters kommunikation förutsätter 8080:8080, om du inte även gör motsvarande ändringar i UniFi:s systemegenskaper. Mappa inte utan vidare värdport 18080 till containerport 8080 och förvänta dig att adoptionen fortsätter fungera stabilt.
Värdläge är inte samma sak som att ge containern en egen LAN-IP
Dockers värdläge innebär att containern delar värdens nätverksnamnområde. Det skapar inte en andra 192.168.x.x-adress för containern.
Om du verkligen behöver en separat LAN-IP är det en macvlan/ipvlan-design, vilket medför begränsningar kring routning och kommunikation mellan värden och containern.
Bryggläge är vanligtvis det enklare valet
Bryggläge håller appen isolerad, gör portägarskapet tydligt och fungerar med den dokumenterade Inform Host-överskrivningen. Det räcker vanligtvis för adoption och hantering av kontrollern.
Kom ihåg kravet på extern MongoDB
Den aktuella UniFi Network Application från LinuxServer kräver en extern MongoDB-instans. Om värdläge misslyckas medan bryggläge fungerar bör du kontrollera att MongoDB-värdnamnet och nätverksvägen fortfarande är giltiga i det valda nätverksläget.
Exponera inte kontrollern direkt mot internet
Håll administrationen på LAN-nätverket eller bakom ett privat fjärråtkomstnätverk. Guiden om privata nätverk ger en säkrare nätverkskontext.
Använd en stabil värdadress
Eftersom adopterade enheter får information om var de ska hitta kontrollern bör du ge ZimaOS-värden en stabil LAN-IP genom en DHCP-reservation i routern eller en noggrant hanterad statisk adress. Om controller-värden ändras från 192.168.1.20 till en annan adress kan enheterna fortsätta att kontakta den gamla inform-endpointen.
Förstå vilka portar som används till vad
UniFi-webbgränssnittet på 8443 är bara en del. Enheternas inform-trafik använder 8080, och andra upptäckts- och STUN-tjänster använder ytterligare portar beroende på installationen. En controller kan därför se frisk ut i en webbläsare medan enheter misslyckas med adoptionen.
Använd den aktuella porttabellen från LinuxServer och exponera endast det din miljö behöver, men behåll de nödvändiga portarna för enhetshantering exakt som de är.
Återställ från Synology med försiktighet
Om du flyttar kontrollern från Synology bör du återställa en UniFi-säkerhetskopia först när den nya ZimaOS-containern och den externa MongoDB-instansen fungerar korrekt. Kontrollera sedan Inform Host och enhetsstatus innan du stänger av den gamla kontrollern.
Kör inte två aktiva controllers som gör anspråk på samma webbplatser/enheter under migreringen, om du inte förstår konsekvenserna för adoptionen.
När en dedikerad LAN-IP faktiskt är användbar
En macvlan/ipvlan-adress kan vara användbar för strikt brandväggssegmentering, för att undvika portkrockar eller för att få kontrollern att se ut som en separat nätverksenhet. Den krävs inte bara för att Docker visar en intern 172.x-adress.
Om du väljer macvlan bör du planera för den vanliga begränsningen i kommunikationen mellan värden och macvlan-nätverket samt kontrollera att MongoDB fortfarande kan nås från controller-nätverket.
Vanliga frågor
Behöver UniFi-containern en 192.168-LAN-IP?
Nej. Bryggläge med publicerade portar och en åtkomlig Inform Host räcker i många installationer.
Varför misslyckas UniFi-enheter med adoption i Docker?
En vanlig orsak är att en oåtkomlig container-IP annonseras. Ange Inform Host till ZimaOS LAN-adress eller ett annat åtkomligt värdnamn.
Bör jag använda värdnätverk?
Endast om du har ett särskilt skäl. Värdläge delar ZimaOS-värdens nätverk; det skapar inte en dedikerad LAN-IP.
När bör jag använda macvlan?
Använd det endast när containern verkligen behöver en egen LAN-identitet och du förstår den extra komplexiteten kring routning och åtkomst från värden.
