A sua aplicação UniFi Network não precisa de ter o seu próprio endereço 192.168.x.x só porque o Docker atribui ao contentor um endereço de ponte 172.x. No modo de ponte normal, publique as portas necessárias no anfitrião e configure o Inform Host da UniFi para um nome de anfitrião ou endereço IP acessível a partir da LAN. Os dispositivos na LAN comunicam com o endereço do anfitrião, enquanto o Docker mantém o contentor na sua rede privada.
O tópico original de 2026 confundiu o endereço IP interno da ponte do contentor com o endereço que os dispositivos da LAN devem utilizar. A documentação atual da LinuxServer aborda explicitamente este caso: o contentor UniFi pode permanecer em modo de ponte, e a adoção dos dispositivos é feita através da configuração de um Inform Host acessível e da manutenção da porta 8080.
Por que motivo vê um endereço 172.x
As redes de ponte do Docker atribuem normalmente endereços privados aos contentores, como 172.17.x.x. Esse endereço destina-se à comunicação entre contentores, não é o endereço que os switches e pontos de acesso devem utilizar a partir da LAN física.
Utilize o endereço IP do anfitrião ZimaOS para as portas publicadas
Se o servidor ZimaOS tiver o endereço 192.168.1.20 e a UniFi publicar as portas 8443 e 8080, aceda à interface e ao endpoint inform através do anfitrião:
https://192.168.1.20:8443
http://192.168.1.20:8080/informConfigure o Inform Host da UniFi
A atual documentação da LinuxServer sobre a UniFi indica que os utilizadores do Docker devem definir o Inform Host/Override para um nome de anfitrião ou endereço IP acessível pelos dispositivos UniFi.
Normalmente, esse endereço é o IP do ZimaOS na LAN ou um nome DNS local estável.
Mantenha a porta 8080 mapeada 1:1
A LinuxServer avisa que a comunicação com os dispositivos UniFi espera 8080:8080, a menos que também faça alterações correspondentes nas propriedades do sistema da UniFi. Não mapeie simplesmente a porta 18080 do anfitrião para a porta 8080 do contentor esperando que a adoção continue estável.
O modo de anfitrião não é o mesmo que “dar ao contentor o seu próprio IP da LAN”
O modo de rede do anfitrião faz com que o contentor partilhe o espaço de nomes de rede do anfitrião. Não cria um segundo endereço 192.168.x.x para o contentor.
Se precisar realmente de um IP separado na LAN, isso corresponde a uma configuração macvlan/ipvlan, que introduz limitações de encaminhamento e de comunicação entre o anfitrião e o contentor.
O modo de ponte é normalmente a escolha mais simples
O modo de ponte mantém a aplicação isolada, torna explícita a gestão das portas e funciona com a substituição do Inform Host documentada. Normalmente, é suficiente para a adoção e a gestão do controlador.
Não se esqueça do requisito de um MongoDB externo
A atual aplicação UniFi Network da LinuxServer requer uma instância externa do MongoDB. Se o modo de anfitrião falhar enquanto o modo de ponte funciona, confirme que o nome do anfitrião do MongoDB e o caminho de rede continuam válidos no modo de rede selecionado.
Não exponha diretamente o controlador à Internet
Mantenha a gestão na LAN ou atrás de uma rede privada de acesso remoto. O guia de redes privadas fornece um contexto de rede mais seguro.
Utilize um endereço estável para o anfitrião
Como os dispositivos adotados recebem a localização do controlador, atribua ao anfitrião ZimaOS um IP estável na LAN através de uma reserva DHCP no router ou de um endereço estático cuidadosamente gerido. Se o endereço do anfitrião do controlador mudar de 192.168.1.20 para outro endereço, os dispositivos podem continuar a contactar o endpoint inform antigo.
Saiba que portas correspondem a cada função
A interface Web da UniFi na porta 8443 é apenas uma parte do sistema. O tráfego inform dos dispositivos utiliza a porta 8080, enquanto outros serviços de descoberta/STUN utilizam portas adicionais, dependendo da implementação. Por isso, um controlador pode parecer saudável num navegador enquanto os dispositivos não conseguem ser adotados.
Consulte a tabela de portas atual da LinuxServer e exponha apenas as portas necessárias no seu ambiente, mas mantenha exatamente as portas obrigatórias para a gestão dos dispositivos.
Restaure a partir de um Synology com cuidado
Se estiver a migrar o controlador de um Synology, restaure uma cópia de segurança da UniFi apenas depois de o novo contentor ZimaOS e o MongoDB externo estarem a funcionar corretamente. Em seguida, confirme o Inform Host e o estado dos dispositivos antes de desligar o controlador antigo.
Não mantenha dois controladores ativos a reclamar os mesmos sites/dispositivos durante a migração, a menos que compreenda as consequências para a adoção.
Quando é realmente útil ter um IP dedicado na LAN
Um endereço macvlan/ipvlan pode ser útil para uma segmentação rigorosa através da firewall, para evitar conflitos de portas ou para fazer com que o controlador se comporte como um dispositivo separado. Não é necessário apenas porque o Docker apresenta um endereço interno 172.x.
Se escolher macvlan, planeie a limitação comum de comunicação entre o anfitrião e o macvlan e confirme que o MongoDB continua acessível a partir da rede do controlador.
FAQ
O contentor UniFi precisa de um IP 192.168 na LAN?
Não. O modo de ponte, juntamente com as portas publicadas e um Inform Host acessível, é suficiente em muitas implementações.
Por que motivo os dispositivos UniFi não conseguem ser adotados no Docker?
Uma causa comum é anunciar um IP do contentor que não é acessível. Defina o Inform Host para o endereço do ZimaOS na LAN ou para outro nome de anfitrião acessível.
Devo utilizar a rede do anfitrião?
Apenas se tiver um motivo para isso. O modo de anfitrião partilha a rede do anfitrião ZimaOS; não cria um IP dedicado na LAN.
Quando devo utilizar macvlan?
Utilize-o apenas quando o contentor precisar realmente da sua própria identidade na LAN e compreender a complexidade adicional de encaminhamento e acesso a partir do anfitrião.
