Votre application UniFi Network n’a pas besoin de sa propre adresse 192.168.x.x simplement parce que Docker attribue au conteneur une adresse de pont 172.x. En mode pont normal, publiez les ports requis et configurez l’hôte Inform de UniFi avec un nom d’hôte ou une adresse IP accessible depuis le réseau local. Les appareils du réseau local communiquent avec l’adresse de l’hôte, tandis que Docker maintient le conteneur sur son réseau privé.
Le fil de discussion source de 2026 confondait l’adresse IP interne du pont du conteneur avec l’adresse que les appareils du réseau local doivent utiliser. La documentation actuelle de LinuxServer couvre explicitement ce point : le conteneur UniFi peut rester en mode pont, et l’adoption des appareils se fait en définissant un hôte Inform accessible et en conservant le port 8080.
Pourquoi voyez-vous une adresse 172.x ?
Les réseaux pont Docker attribuent normalement aux conteneurs des adresses privées telles que 172.17.x.x. Cette adresse sert à la communication entre conteneurs, et non d’adresse que vos commutateurs et points d’accès doivent utiliser depuis le réseau local physique.
Utilisez l’adresse IP de l’hôte ZimaOS pour les ports publiés
Si le serveur ZimaOS est 192.168.1.20 et qu’UniFi publie les ports 8443 et 8080, vous accédez à l’interface et au point de terminaison Inform via l’hôte :
https://192.168.1.20:8443
http://192.168.1.20:8080/informConfigurez l’hôte Inform d’UniFi
La documentation UniFi de LinuxServer indique que les utilisateurs de Docker doivent définir le remplacement de l’hôte Inform avec un nom d’hôte ou une adresse IP accessible par les appareils UniFi.
Il s’agit généralement de l’adresse IP du réseau local de ZimaOS ou d’un nom DNS local stable.
Conservez une correspondance directe pour le port 8080
LinuxServer avertit que la communication avec les appareils UniFi nécessite 8080:8080, sauf si vous apportez également les modifications correspondantes dans les propriétés système d’UniFi. Ne mappez pas simplement le port hôte 18080 vers le port 8080 du conteneur en espérant que l’adoption reste stable.
Le mode hôte ne revient pas à « attribuer sa propre IP réseau local au conteneur »
Le mode réseau hôte fait partager au conteneur l’espace de noms réseau de l’hôte. Il ne crée pas une deuxième adresse 192.168.x.x pour le conteneur.
Si vous avez réellement besoin d’une adresse IP réseau local distincte, il s’agit d’une conception macvlan/ipvlan, qui ajoute des contraintes de routage et de communication entre l’hôte et le conteneur.
Le mode pont est généralement le choix le plus simple
Le mode pont isole l’application, rend l’attribution des ports explicite et fonctionne avec le remplacement documenté de l’hôte Inform. Il suffit généralement pour l’adoption et la gestion du contrôleur.
N’oubliez pas la nécessité d’un MongoDB externe
L’application UniFi Network actuelle de LinuxServer nécessite une instance MongoDB externe. Si le mode hôte échoue alors que le mode pont fonctionne, vérifiez que le nom d’hôte MongoDB et le chemin réseau restent valides avec le mode réseau sélectionné.
N’exposez pas directement le contrôleur à Internet
Conservez la gestion sur le réseau local ou derrière un réseau d’accès distant privé. Le guide sur les réseaux privés fournit un contexte réseau plus sûr.
Utilisez une adresse d’hôte stable
Comme les appareils adoptés reçoivent l’adresse à laquelle trouver le contrôleur, attribuez à l’hôte ZimaOS une adresse IP réseau local stable au moyen d’une réservation DHCP sur le routeur ou d’une adresse statique soigneusement gérée. Si l’hôte du contrôleur passe de 192.168.1.20 à une autre adresse, les appareils peuvent continuer à contacter l’ancien point de terminaison Inform.
Comprenez le rôle de chaque port
L’interface web UniFi sur le port 8443 n’est qu’un élément. Le trafic Inform des appareils utilise le port 8080, tandis que d’autres services de découverte et STUN utilisent des ports supplémentaires selon le déploiement. Un contrôleur peut donc sembler fonctionner correctement dans un navigateur alors que les appareils échouent lors de l’adoption.
Consultez le tableau des ports actuel de LinuxServer et n’exposez que ceux dont votre environnement a besoin, mais conservez exactement les ports requis pour la gestion des appareils.
Effectuez soigneusement une restauration depuis Synology
Si vous migrez le contrôleur depuis Synology, restaurez une sauvegarde UniFi uniquement après vous être assuré que le nouveau conteneur ZimaOS et MongoDB externe fonctionnent correctement. Vérifiez ensuite l’hôte Inform et l’état des appareils avant d’arrêter l’ancien contrôleur.
Ne faites pas fonctionner deux contrôleurs actifs revendiquant les mêmes sites ou appareils pendant la migration, sauf si vous comprenez les conséquences sur l’adoption.
Quand une adresse IP réseau local dédiée est-elle réellement utile ?
Une adresse macvlan/ipvlan peut être utile pour une segmentation stricte du pare-feu, éviter les conflits de ports ou faire apparaître le contrôleur comme une appliance distincte. Elle n’est pas requise simplement parce que Docker affiche une adresse interne 172.x.
Si vous choisissez macvlan, prévoyez la limitation courante de communication entre l’hôte et macvlan et vérifiez que MongoDB reste accessible depuis le réseau du contrôleur.
FAQ
Le conteneur UniFi a-t-il besoin d’une adresse IP 192.168 sur le réseau local ?
Non. Le mode pont, associé aux ports publiés et à un hôte Inform accessible, suffit dans de nombreux déploiements.
Pourquoi les appareils UniFi échouent-ils lors de l’adoption dans Docker ?
Une cause fréquente est l’annonce d’une adresse IP de conteneur inaccessible. Définissez l’hôte Inform sur l’adresse réseau local de ZimaOS ou sur un autre nom d’hôte accessible.
Dois-je utiliser le réseau hôte ?
Uniquement si vous avez une raison précise. Le mode hôte partage le réseau de l’hôte ZimaOS ; il ne crée pas d’adresse IP réseau local dédiée.
Quand dois-je utiliser macvlan ?
Utilisez-le uniquement lorsque le conteneur a réellement besoin de sa propre identité sur le réseau local et que vous comprenez la complexité supplémentaire du routage et de l’accès depuis l’hôte.
