La resolución de origen es inusualmente clara: no se trataba de un fallo de Docker que afectara a todas las aplicaciones. El usuario había configurado Tailscale con un nodo de salida, después de lo cual Jellyfin y las URL de otras aplicaciones dejaron de funcionar incluso en la red local. Más tarde desinstaló Tailscale, se conectó mediante la IP de LAN de ZimaOS e informó de que todo volvía a funcionar.
Ese comportamiento coincide con la documentación actual de Tailscale. Cuando un cliente utiliza un nodo de salida, el acceso a la red LAN local está desactivado de forma predeterminada, a menos que se habilite Allow Local Network Access. Antes de reinstalar aplicaciones o reiniciar Docker, verifica la tabla de enrutamiento y si el cliente está enviando intencionadamente el tráfico a través de un nodo de salida.
Los puertos directos de las aplicaciones también fallaban
El usuario intentó abrir directamente los puertos de las aplicaciones y afirmó que ninguno funcionaba, excepto Tailscale. Esta es una pista útil: cuando varios contenedores no relacionados dejan de ser accesibles al mismo tiempo, comprueba primero las capas de red y enrutamiento compartidas antes de asumir que todas las aplicaciones se han averiado por separado.
Un comando fallido para reiniciar Docker fue una distracción
ZimaOS no es un sistema Debian genérico en el que se aplique cualquier comando de administración de servicios encontrado en tutoriales de Internet. Si todas las aplicaciones fallan, comprueba primero si los contenedores están realmente en ejecución y si sus puertos publicados son accesibles desde el host o la LAN.
Los nodos de salida cambian la ruta predeterminada del cliente
Los nodos de salida de Tailscale enrutan el tráfico general de Internet a través de otro dispositivo de tailnet. La documentación actual de Tailscale indica explícitamente que el acceso a la red local está desactivado de forma predeterminada mientras se utiliza un nodo de salida.
Consulta el comportamiento actual de los nodos de salida de Tailscale.
Activa Allow Local Network Access cuando necesites ambas conexiones intencionadamente
Los clientes actuales de Tailscale ofrecen la opción Allow Local Network Access. En los clientes basados en CLI, el equivalente se puede configurar mediante la opción de acceso a la LAN del nodo de salida.
Actívala únicamente cuando la red local sea de confianza.
Desactiva el nodo de salida para aislar el problema
Una prueba rápida consiste en seleccionar None como nodo de salida activo y volver a intentar acceder a la IP de LAN de ZimaOS y al puerto de una aplicación. Si el acceso local se restablece de inmediato, el lugar más importante que investigar es la configuración de enrutamiento, no Docker.
El autor original eliminó Tailscale y confirmó la recuperación
El usuario afirmó que el ordenador se desconectaba de la ruta del router o de la IP local cuando se conectaba mediante su configuración de Tailscale. Después de desinstalar Tailscale y utilizar la IP local, todas las aplicaciones volvieron a funcionar.
Se trata de una recuperación confirmada por el origen, aunque el usuario no documentó las opciones exactas del nodo de salida que provocaron el comportamiento incorrecto.
Un orden de resolución de problemas mejor
- abre directamente el panel de ZimaOS mediante la IP de LAN;
- comprueba si el puerto de alguna aplicación funciona localmente;
- desactiva el nodo de salida activo de Tailscale;
- vuelve a intentar acceder a la aplicación local;
- solo después revisa los registros de Docker o de la aplicación si los puertos siguen sin estar disponibles.
Preguntas frecuentes sobre Service Unavailable en todas las aplicaciones
¿Reinstalar las aplicaciones solucionó el problema del origen?
No. Las aplicaciones comenzaron a funcionar únicamente después de eliminar el estado de enrutamiento problemático de Tailscale.
¿Puede un nodo de salida de Tailscale bloquear el acceso a la LAN local?
Sí. La documentación actual de Tailscale indica que el acceso a la LAN está desactivado de forma predeterminada mientras se utiliza un nodo de salida, a menos que el usuario habilite el acceso a la red local.
¿Se confirmó que Docker estaba averiado?
No. La resolución del origen apunta a un problema de enrutamiento, no a un fallo del demonio de Docker.
