Una aplicación de Docker puede estar escuchando correctamente en ZimaOS y aun así ser inaccesible desde un servicio en Internet público. Esa fue la principal conclusión de este hilo de mayo de 2026. Al principio, el usuario pensaba que el puerto 9696 estaba «cerrado», pero la inspección del contenedor mostró que Prowlarr ya estaba publicado en el host.
Una vez confirmado esto, el problema dejó de ser una cuestión de configuración de Docker y pasó a ser una cuestión de acceso remoto y límites de la red.
Que esté publicado en el host no significa que sea accesible públicamente
La investigación de la comunidad confirmó que Prowlarr tenía un mapeo del host para el puerto 9696. En términos de Docker, esto significa que el servicio estaba expuesto del contenedor a la red del host ZimaOS.
Esto basta para que los dispositivos de la misma LAN se conecten a la IP y al puerto publicado de ZimaOS, siempre que la propia aplicación esté escuchando correctamente. Sin embargo, no crea automáticamente una ruta desde Internet a través del router.
Una dirección LAN privada no puede ser utilizada por un servicio en la nube
El usuario aclaró que TorBox no se ejecutaba en el servidor ZimaOS. Necesitaba conectarse desde fuera de la red doméstica. Una dirección privada como 192.168.x.x no es enrutable por Internet, por lo que un servicio en la nube no puede acceder directamente a ella.
Por eso el contenedor podía establecer conexiones salientes con indexadores públicos, mientras que el servicio en la nube no podía crear una nueva conexión entrante a la LAN del usuario.
El acceso remoto requiere una capa de red adicional
En el hilo se analizaron varias posibilidades, incluido el reenvío de puertos del router, una IP pública o un dominio, Tailscale, Cloudflare Tunnel y soluciones de proxy inverso.
La exposición directa de servicios administrativos en Internet debe abordarse con cuidado. La autenticación, TLS, el control de acceso y la seguridad de la aplicación son importantes cuando un servicio queda accesible desde Internet.
La documentación de red actual de ZimaOS también ofrece una opción integrada de Acceso remoto que establece un relé seguro para el panel de ZimaOS sin necesidad de configurar manualmente el reenvío de puertos del router.
Opciones actuales de Acceso remoto y configuración de red de ZimaOS
CGNAT puede impedir el reenvío de puertos entrantes tradicional
La respuesta de la comunidad también planteó la posibilidad de que la NAT de grado de operador (CGNAT) fuera un obstáculo. Si el proveedor de Internet no proporciona una dirección IPv4 pública directamente accesible, el reenvío de puertos normal del router puede no crear una ruta entrante utilizable.
El usuario original comparó la IP pública con la dirección WAN del router y consideró que CGNAT no era el problema en su caso. A partir de ahí, el hilo se orientó hacia opciones de redes superpuestas o túneles.
No des por hecho que ZimaOS está bloqueando el puerto cuando Docker muestra que está publicado
La discusión original no encontró pruebas de que ZimaOS estuviera bloqueando el acceso local desde la LAN al puerto 9696. Una vez que Docker mostraba claramente el puerto publicado, el fallo de conexión desde la nube remota debía investigarse fuera del mapeo del contenedor.
Este es un patrón de diagnóstico útil para otras aplicaciones autoalojadas: confirma que la aplicación funciona localmente antes de investigar el DNS público, la NAT, los túneles o las integraciones externas.
Preguntas frecuentes sobre puertos remotos de ZimaOS
Si Docker publica el puerto 9696, ¿está abierto a todo Internet?
No. Está publicado en el host. Que Internet pueda acceder a él depende del enrutamiento, la NAT, el comportamiento del proveedor de Internet, la política del firewall y cualquier capa de túnel o proxy inverso.
¿Por qué Prowlarr puede acceder a indexadores públicos, pero TorBox no puede acceder a Prowlarr?
Las conexiones salientes y entrantes son diferentes. Normalmente, el tráfico saliente puede salir de una NAT doméstica sin una configuración especial, mientras que el tráfico entrante nuevo necesita una ruta de regreso a la LAN.
¿Debería exponer Prowlarr directamente mediante el reenvío de puertos del router?
El hilo advirtió contra la exposición directa y sugirió métodos de acceso remoto más seguros, como Tailscale, Cloudflare Tunnel o un proxy inverso autenticado.
¿Estaba realmente mal configurado el puerto 9696 en el caso original?
No. El usuario confirmó el mapeo esperado entre el host y el contenedor, por lo que la investigación pasó a centrarse más allá de la publicación del puerto de Docker.
