Een Docker-toepassing kan correct luisteren op ZimaOS en toch onbereikbaar zijn vanuit een dienst op het openbare internet. Dat was de belangrijkste les uit deze thread van mei 2026. De gebruiker dacht aanvankelijk dat poort 9696 “gesloten” was, maar uit containerinspectie bleek dat Prowlarr al op de host was gepubliceerd.
Nadat dit was vastgesteld, veranderde het probleem van een Docker-configuratievraag in een vraag over externe toegang en netwerkgrenzen.
Op de host gepubliceerd betekent niet publiek bereikbaar
De probleemoplossing in de community bevestigde dat Prowlarr een hostkoppeling voor poort 9696 had. In Docker-termen betekent dit dat de dienst vanuit de container beschikbaar was gemaakt op het netwerk van de ZimaOS-host.
Dat is voldoende voor apparaten op hetzelfde LAN om verbinding te maken met het ZimaOS-IP-adres en de gepubliceerde poort, ervan uitgaande dat de toepassing zelf correct luistert. Het creëert niet automatisch een route vanaf het openbare internet via je router.
Een privéadres van het LAN kan niet door een clouddienst worden gebruikt
De gebruiker verduidelijkte dat TorBox niet op de ZimaOS-server draaide. Het moest van buiten het thuisnetwerk verbinding maken. Een privéadres zoals 192.168.x.x is niet routeerbaar via internet, waardoor een clouddienst dat adres niet rechtstreeks kan bereiken.
Daarom kon de container uitgaande verbindingen met openbare indexers maken, terwijl de clouddienst geen nieuwe inkomende verbinding naar het LAN van de gebruiker kon openen.
Externe toegang vereist een extra netwerklaag
In de thread werden verschillende mogelijkheden besproken, waaronder port forwarding op de router, een openbaar IP-adres of domein, Tailscale, Cloudflare Tunnel en oplossingen met een reverse proxy.
Wees voorzichtig met het rechtstreeks openbaar maken van beheerdiensten. Zodra een dienst via internet bereikbaar is, zijn authenticatie, TLS, toegangsbeheer en applicatiebeveiliging allemaal belangrijk.
De huidige netwerkdocumentatie van ZimaOS biedt ook een ingebouwde optie voor externe toegang, die een beveiligde relay instelt voor het ZimaOS-dashboard zonder dat je handmatig port forwarding op de router hoeft in te stellen.
De huidige instellingen voor externe toegang en netwerken van ZimaOS
CGNAT kan traditionele port forwarding voor inkomende verbindingen verhinderen
In het communityantwoord werd Carrier-Grade NAT ook genoemd als mogelijke blokkade. Als een internetprovider geen rechtstreeks bereikbaar openbaar IPv4-adres levert, kan gewone port forwarding op de router geen bruikbare inkomende route creëren.
De oorspronkelijke gebruiker vergeleek het openbare IP-adres met het WAN-adres van de router en dacht dat CGNAT in dit geval niet het probleem was. Daarna verschoof de thread naar opties met overlaynetwerken of tunnels.
Ga er niet van uit dat ZimaOS de poort blokkeert wanneer Docker aangeeft dat deze is gepubliceerd
In de besproken situatie werd geen bewijs gevonden dat ZimaOS zelf lokale LAN-toegang tot poort 9696 blokkeerde. Zodra Docker de poort zichtbaar had gepubliceerd, moest de mislukte verbinding vanuit de cloud buiten de containertoewijzing worden onderzocht.
Dit is een nuttig diagnostisch patroon voor andere zelfgehoste apps: controleer eerst of de toepassing lokaal werkt voordat je openbare DNS, NAT, tunnels of externe integraties onderzoekt.
Veelgestelde vragen over externe poorten in ZimaOS
Is poort 9696 voor het hele internet toegankelijk als Docker deze publiceert?
Nee. De poort is op de host gepubliceerd. Of het internet deze kan bereiken, hangt af van routering, NAT, het gedrag van de internetprovider, firewallbeleid en een eventuele tunnel- of reverse-proxylaag.
Waarom kan Prowlarr openbare indexers bereiken, terwijl TorBox geen verbinding met Prowlarr kan maken?
Uitgaande en inkomende verbindingen zijn verschillend. Uitgaand verkeer verlaat een thuisnetwerk doorgaans via NAT zonder speciale configuratie, terwijl voor nieuw inkomend verkeer een route terug naar het LAN nodig is.
Moet ik Prowlarr rechtstreeks beschikbaar maken met port forwarding op de router?
In de thread werd gewaarschuwd tegen rechtstreekse blootstelling en werden veiligere methoden voor externe toegang voorgesteld, zoals Tailscale, Cloudflare Tunnel of een reverse proxy met authenticatie.
Was poort 9696 in de oorspronkelijke situatie verkeerd geconfigureerd?
Nee. De gebruiker bevestigde de verwachte host-naar-containerkoppeling, waarna de probleemoplossing verderging dan het publiceren van de Docker-poort.
