A Docker application can be listening correctly on ZimaOS and still be unreachable from a service on the public internet. That was the main lesson in this May 2026 thread. The user initially thought port 9696 was “closed,” but container inspection showed that Prowlarr was already published on the host.
Once that was established, the problem changed from a Docker configuration question into a remote-access and network-boundary question.
Published on the Host Does Not Mean Publicly Reachable
The community troubleshooting confirmed that Prowlarr had a host mapping for port 9696. In Docker terms, that means the service was exposed from the container to the ZimaOS host network.
That is enough for devices on the same LAN to connect to the ZimaOS IP and published port, assuming the application itself is listening correctly. It does not automatically create a route from the public internet through your router.
A Private LAN Address Cannot Be Used by a Cloud Service
The user clarified that TorBox was not running on the ZimaOS server. It needed to connect from outside the home network. A private address such as 192.168.x.x is not internet-routable, so a cloud service cannot directly reach that address.
This is why the container could make outbound connections to public indexers while the cloud service could not create a new inbound connection to the user's LAN.
Remote Access Requires an Additional Network Layer
The thread discussed several possibilities, including router port forwarding, a public IP or domain, Tailscale, Cloudflare Tunnel, and reverse proxy solutions.
Raw public exposure of administrative services should be approached carefully. Authentication, TLS, access control, and application security all matter once a service is reachable from the internet.
Current ZimaOS networking documentation also provides a built-in Remote Access option that establishes a secure relay for the ZimaOS dashboard without manual router port forwarding.
ZimaOS's current Remote Access and network settings
CGNAT Can Prevent Traditional Inbound Port Forwarding
The community reply also raised Carrier-Grade NAT as a possible blocker. If an ISP does not provide a directly reachable public IPv4 address, ordinary router port forwarding may not create a usable inbound path.
The original user compared the public IP with the router WAN address and believed CGNAT was not the issue in their case. The thread then moved toward overlay-network or tunnel options.
Do Not Assume ZimaOS Is Blocking the Port When Docker Shows It Published
The source discussion did not find evidence that ZimaOS itself was blocking local LAN access to port 9696. Once the port was visibly published by Docker, the remote cloud connection failure had to be investigated outside the container mapping.
This is a useful diagnostic pattern for other self-hosted apps: confirm the application works locally before troubleshooting public DNS, NAT, tunnels, or external integrations.
ZimaOS Remote Port FAQ
If Docker publishes 9696, is it open to the whole internet?
No. It is published on the host. Whether the internet can reach it depends on routing, NAT, ISP behavior, firewall policy, and any tunnel or reverse-proxy layer.
Why can Prowlarr reach public indexers while TorBox cannot reach Prowlarr?
Outbound and inbound connections are different. Outbound traffic normally leaves a home NAT without special configuration, while new inbound traffic needs a route back into the LAN.
Should I expose Prowlarr directly with router port forwarding?
The thread cautioned against raw exposure and suggested safer remote-access approaches such as Tailscale, Cloudflare Tunnel, or an authenticated reverse proxy.
Was port 9696 actually misconfigured in the source case?
No. The user confirmed the expected host-to-container mapping, so troubleshooting moved beyond Docker port publication.
