Après avoir changé de FAI et réinstallé ZimaOS, un membre de la communauté a constaté que l’hôte pouvait envoyer des requêtes ping vers des sites Internet et télécharger les images de l’App Store, tandis que les applications exécutées dans des conteneurs ne pouvaient pas accéder aux services externes. qBittorrent ne pouvait pas télécharger de fichiers et Jellyfin ne pouvait pas récupérer les métadonnées.
Le cas initial a été résolu en faisant passer les conteneurs concernés du réseau bridge au mode hôte. Des réponses ultérieures ont documenté un second cas présentant des symptômes similaires, mais dus à une autre cause : une adresse WAN publique avait été saisie comme passerelle, et le chemin réseau du FAI de l’utilisateur nécessitait également IPv6 en plus d’IPv4 pour Jellyfin.
La connectivité de l’hôte ne prouvait pas celle des conteneurs
L’auteur pouvait utiliser le terminal web de ZimaOS et installer des applications, ce qui démontrait que le système d’exploitation disposait lui-même d’une route sortante fonctionnelle. Cela ne suffisait pas à établir que chaque réseau Docker disposait d’un routage correct. Les échecs des applications devaient donc être testés depuis le conteneur, plutôt que déduits de la connectivité de l’hôte.
Giorgio, membre de l’équipe Zima, a suggéré de tester la connectivité à l’aide d’un conteneur de navigateur et d’essayer un autre mode réseau depuis le panneau des paramètres de l’application. La publication indique également que les boutiques tierces, l’installation via YAML et l’installation en ligne de commande peuvent fournir des applications de diagnostic, mais qu’il s’agit d’options et non d’une exigence confirmée.
Le mode hôte a résolu le problème initial lié au réseau bridge
L’auteur a fait passer tous les conteneurs concernés en mode hôte et a indiqué que l’accès à Internet fonctionnait de nouveau. La discussion ne détermine pas pourquoi le mode bridge a échoué après l’installation propre ; le mode hôte doit donc être considéré comme la modification qui a fonctionné dans cette configuration, et non comme la preuve d’un défaut généralisé du réseau bridge.
Un participant ultérieur a signalé un effet secondaire important : après le changement de mode, le lien du tableau de bord peut encore pointer vers l’ancien port publié sur l’hôte. Pour Jellyfin, le participant a dû accéder directement au port 8096, car le tableau de bord continuait d’ouvrir le port 8097.
Un cas ultérieur a révélé une passerelle incorrecte
Les journaux Jellyfin du deuxième utilisateur contenaient No route to host lors de la connexion à un service externe de métadonnées. Les membres de la communauté ont recommandé d’effectuer un test sans le VPN et de vérifier la passerelle affichée dans les paramètres réseau de ZimaOS.
Une capture d’écran a révélé que la passerelle configurée était l’adresse WAN publique de l’utilisateur. Les réponses ont expliqué que la passerelle devait plutôt être l’adresse du routeur local située sur le même sous-réseau LAN. L’utilisateur a corrigé la passerelle et activé IPv6 en plus d’IPv4 dans Jellyfin, car sa connexion AT&T privilégiait IPv6. Il a ensuite confirmé que la récupération des métadonnées et des images fonctionnait.
Il faut distinguer les deux résultats de la communauté
- Cas initial d’octobre 2025 : le réseau bridge échouait pour les conteneurs de l’auteur ; le mode hôte a rétabli l’accès.
- Cas de suivi de janvier 2026 : la passerelle était configurée avec une adresse IP publique, et Jellyfin devait également activer IPv6 pour ce chemin réseau du FAI.
Les deux cas produisaient le symptôme général « les applications ne peuvent pas accéder à Internet », mais ils ne partageaient pas une cause racine vérifiée. La discussion recommande de vérifier séparément le mode réseau, l’adresse utilisée après un changement de mode, la configuration de la passerelle, l’influence du VPN et la disponibilité des protocoles.
FAQ
Pourquoi ZimaOS peut-il télécharger des applications alors qu’un conteneur reste hors ligne ?
L’hôte et un conteneur Docker peuvent utiliser des configurations réseau et un routage différents. Dans le cas initial, la connectivité de l’hôte restait fonctionnelle tandis que les applications connectées au réseau bridge échouaient.
Le passage de Jellyfin en mode hôte conserve-t-il l’ancien port du tableau de bord ?
Pas nécessairement. Un participant a constaté que le tableau de bord continuait à pointer vers le port 8097, tandis que Jellyfin en mode hôte était directement accessible sur le port 8096.
