A resolução da origem é invulgarmente clara: isto não foi uma falha do Docker que afetasse todas as aplicações. O utilizador tinha configurado o Tailscale com uma configuração de nó de saída, após o que o Jellyfin e os URLs de outras aplicações deixaram de funcionar, mesmo na rede local. Mais tarde, desinstalou o Tailscale, ligou-se através do IP da LAN do ZimaOS e comunicou que tudo voltara a funcionar.
Esse comportamento corresponde à documentação atual do Tailscale. Quando um cliente utiliza um nó de saída, o acesso à LAN local é desativado por predefinição, a menos que a opção Permitir acesso à rede local esteja ativada. Antes de reinstalar aplicações ou reiniciar o Docker, verifique a tabela de encaminhamento e confirme se o cliente está intencionalmente a enviar tráfego através de um nó de saída.
As portas diretas das aplicações também falharam
O utilizador tentou abrir diretamente as portas das aplicações e afirmou que nenhuma funcionava, exceto o Tailscale. Esta é uma pista útil: quando vários contentores não relacionados ficam inacessíveis ao mesmo tempo, teste primeiro as camadas de rede e encaminhamento partilhadas, antes de presumir que todas as aplicações falharam individualmente.
Um comando falhado de reinício do Docker foi uma distração
O ZimaOS não é um sistema Debian genérico em que todos os comandos de gestão de serviços encontrados em tutoriais online se aplicam. Se todas as aplicações falharem, verifique primeiro se os contentores estão efetivamente em execução e se as respetivas portas publicadas estão acessíveis a partir do anfitrião ou da LAN.
Os nós de saída alteram a rota predefinida do cliente
Os nós de saída do Tailscale encaminham o tráfego geral da Internet através de outro dispositivo da tailnet. A documentação atual do Tailscale afirma explicitamente que o acesso à rede local está desativado por predefinição enquanto um nó de saída está a ser utilizado.
Consulte o comportamento atual dos nós de saída do Tailscale.
Ative Permitir acesso à rede local quando precisar intencionalmente de ambos
Os clientes atuais do Tailscale disponibilizam a opção Permitir acesso à rede local. Nos clientes baseados na CLI, o equivalente pode ser configurado com a opção de acesso à LAN através do nó de saída.
Ative esta opção apenas quando a rede local for de confiança.
Desative o nó de saída para isolar o problema
Um diagnóstico rápido consiste em selecionar Nenhum como nó de saída ativo e tentar novamente aceder ao IP da LAN do ZimaOS e à porta de uma aplicação. Se o acesso local regressar imediatamente, o ponto mais importante a investigar é a configuração de encaminhamento — e não o Docker.
O autor da publicação original removeu o Tailscale e confirmou a recuperação
O utilizador afirmou que o computador se desligava do encaminhamento através do router ou do IP local quando se ligava através da configuração do Tailscale. Depois de desinstalar o Tailscale e utilizar o IP local, todas as aplicações voltaram a funcionar.
Esta é uma recuperação confirmada pela origem, embora o utilizador não tenha documentado as opções exatas do nó de saída que causaram o comportamento incorreto.
Uma ordem de resolução de problemas melhor
- abra diretamente o painel do ZimaOS através do IP da LAN;
- verifique se uma porta de aplicação funciona localmente;
- desative o nó de saída ativo do Tailscale;
- tente novamente aceder à aplicação local;
- só depois consulte os registos do Docker ou da aplicação se as portas continuarem indisponíveis.
Perguntas frequentes sobre o erro Serviço indisponível em todas as aplicações
A reinstalação das aplicações resolveu o problema na origem?
Não. As aplicações só começaram a funcionar depois de o estado de encaminhamento problemático do Tailscale ter sido removido.
Um nó de saída do Tailscale pode bloquear o acesso à LAN local?
Sim. A documentação atual do Tailscale indica que o acesso à LAN está desativado por predefinição quando se utiliza um nó de saída, a menos que o utilizador ative o acesso à rede local.
Foi confirmado que o próprio Docker estava avariado?
Não. A resolução na origem aponta para um problema de encaminhamento, e não para uma falha do daemon do Docker.
