Une application Docker peut être à l’écoute correctement sur ZimaOS tout en restant inaccessible depuis un service sur Internet. C’est la principale leçon de cette discussion de mai 2026. L’utilisateur pensait initialement que le port 9696 était « fermé », mais l’inspection du conteneur a montré que Prowlarr était déjà publié sur l’hôte.
Une fois ce point établi, le problème ne concernait plus la configuration de Docker, mais l’accès à distance et les limites du réseau.
Publié sur l’hôte ne signifie pas accessible publiquement
Le dépannage mené par la communauté a confirmé que Prowlarr disposait d’une redirection de l’hôte vers le port 9696. En termes Docker, cela signifie que le service était exposé du conteneur vers le réseau de l’hôte ZimaOS.
Cela suffit pour que les appareils du même réseau local se connectent à l’adresse IP de ZimaOS et au port publié, à condition que l’application soit elle-même correctement à l’écoute. En revanche, cela ne crée pas automatiquement un itinéraire permettant à Internet d’atteindre votre serveur à travers le routeur.
Une adresse LAN privée ne peut pas être utilisée par un service cloud
L’utilisateur a précisé que TorBox ne fonctionnait pas sur le serveur ZimaOS. Il devait se connecter depuis l’extérieur du réseau domestique. Une adresse privée telle que 192.168.x.x n’est pas routable sur Internet ; un service cloud ne peut donc pas atteindre directement cette adresse.
C’est pourquoi le conteneur pouvait établir des connexions sortantes vers des indexeurs publics, tandis que le service cloud ne pouvait pas créer de nouvelle connexion entrante vers le réseau local de l’utilisateur.
L’accès à distance nécessite une couche réseau supplémentaire
La discussion a évoqué plusieurs possibilités, notamment la redirection de ports sur le routeur, une adresse IP publique ou un domaine, Tailscale, Cloudflare Tunnel et les solutions de proxy inverse.
L’exposition directe de services d’administration sur Internet doit être abordée avec prudence. L’authentification, le TLS, le contrôle d’accès et la sécurité de l’application sont tous importants dès qu’un service devient accessible depuis Internet.
La documentation réseau actuelle de ZimaOS propose également une option intégrée d’accès à distance, qui établit un relais sécurisé pour le tableau de bord ZimaOS sans nécessiter de redirection manuelle de ports sur le routeur.
Options actuelles d’accès à distance et paramètres réseau de ZimaOS
Le CGNAT peut empêcher la redirection traditionnelle des ports entrants
La réponse de la communauté a également évoqué le NAT de niveau opérateur comme éventuel obstacle. Si un fournisseur d’accès ne fournit pas d’adresse IPv4 publique directement joignable, une simple redirection de ports sur le routeur peut ne pas créer de chemin entrant utilisable.
L’utilisateur d’origine a comparé l’adresse IP publique à l’adresse WAN du routeur et estimait que le CGNAT n’était pas en cause dans son cas. La discussion s’est ensuite orientée vers les réseaux superposés et les solutions de tunnel.
Ne supposez pas que ZimaOS bloque le port lorsque Docker indique qu’il est publié
La discussion d’origine n’a trouvé aucun élément indiquant que ZimaOS bloquait lui-même l’accès local au port 9696. Une fois que Docker avait clairement publié le port, l’échec de la connexion au service cloud distant devait être examiné en dehors de la redirection de ports du conteneur.
Il s’agit d’une méthode de diagnostic utile pour d’autres applications auto-hébergées : vérifiez que l’application fonctionne localement avant de dépanner le DNS public, le NAT, les tunnels ou les intégrations externes.
FAQ sur les ports distants de ZimaOS
Si Docker publie le port 9696, est-il ouvert à tout Internet ?
Non. Il est publié sur l’hôte. La possibilité pour Internet de l’atteindre dépend du routage, du NAT, du comportement du fournisseur d’accès, de la politique du pare-feu et de la présence éventuelle d’un tunnel ou d’une couche de proxy inverse.
Pourquoi Prowlarr peut-il atteindre des indexeurs publics alors que TorBox ne peut pas atteindre Prowlarr ?
Les connexions sortantes et entrantes sont différentes. Le trafic sortant quitte généralement un réseau domestique derrière un NAT sans configuration particulière, tandis qu’un nouveau trafic entrant nécessite un itinéraire de retour vers le réseau local.
Dois-je exposer directement Prowlarr avec une redirection de port sur le routeur ?
La discussion déconseillait l’exposition directe et suggérait des méthodes d’accès à distance plus sûres, comme Tailscale, Cloudflare Tunnel ou un proxy inverse authentifié.
Le port 9696 était-il réellement mal configuré dans le cas présenté ?
Non. L’utilisateur a confirmé la redirection attendue entre l’hôte et le conteneur ; le dépannage s’est donc poursuivi au-delà de la publication du port Docker.
