La résolution d’origine est inhabituellement claire : il ne s’agissait pas d’une panne de Docker affectant toutes les applications. L’utilisateur avait configuré Tailscale avec un nœud de sortie, après quoi Jellyfin et les URL des autres applications ont cessé de fonctionner, même sur le réseau local. Il a ensuite désinstallé Tailscale, s’est connecté via l’adresse IP LAN de ZimaOS et a signalé que tout fonctionnait à nouveau.
Ce comportement correspond à la documentation actuelle de Tailscale. Lorsqu’un client utilise un nœud de sortie, l’accès au réseau local est désactivé par défaut, sauf si Autoriser l’accès au réseau local est activé. Avant de réinstaller des applications ou de redémarrer Docker, vérifiez la table de routage et assurez-vous que le client envoie intentionnellement son trafic via un nœud de sortie.
Les ports directs des applications échouaient également
L’utilisateur a essayé d’ouvrir directement les ports des applications et a indiqué que seul Tailscale fonctionnait. C’est un indice utile : lorsque plusieurs conteneurs sans rapport deviennent tous inaccessibles simultanément, vérifiez d’abord les couches réseau et de routage communes avant de supposer que chaque application est tombée en panne indépendamment.
Une commande de redémarrage de Docker incorrecte a détourné l’attention
ZimaOS n’est pas un système Debian générique sur lequel toutes les commandes de gestion des services trouvées dans les tutoriels en ligne s’appliquent. Si toutes les applications échouent, vérifiez d’abord que les conteneurs sont réellement en cours d’exécution et que leurs ports publiés sont accessibles depuis l’hôte ou le réseau local.
Les nœuds de sortie modifient la route par défaut du client
Les nœuds de sortie Tailscale acheminent le trafic Internet général via un autre appareil du tailnet. La documentation actuelle de Tailscale indique explicitement que l’accès au réseau local est désactivé par défaut lorsqu’un nœud de sortie est utilisé.
Consultez le comportement actuel des nœuds de sortie Tailscale.
Activez l’accès au réseau local lorsque vous en avez intentionnellement besoin
Les clients Tailscale actuels proposent une option Autoriser l’accès au réseau local. Sur les clients utilisant la ligne de commande, l’équivalent peut être configuré avec l’option d’accès au réseau local du nœud de sortie.
Activez cette option uniquement lorsque le réseau local est fiable.
Désactivez le nœud de sortie pour isoler le problème
Un diagnostic rapide consiste à sélectionner Aucun comme nœud de sortie actif, puis à réessayer d’accéder à l’adresse IP LAN de ZimaOS et au port d’une application. Si l’accès local revient immédiatement, c’est la configuration du routage — et non Docker — qu’il faut examiner en priorité.
L’auteur du message d’origine a supprimé Tailscale et confirmé le rétablissement
L’utilisateur a indiqué que l’ordinateur se déconnectait du routeur ou du chemin passant par l’adresse IP locale lorsqu’il se connectait via sa configuration Tailscale. Après avoir désinstallé Tailscale et utilisé l’adresse IP locale, toutes les applications ont de nouveau fonctionné.
Il s’agit d’un rétablissement confirmé par la source, même si l’utilisateur n’a pas documenté les options exactes du nœud de sortie à l’origine du comportement incorrect.
Un meilleur ordre de dépannage
- ouvrez directement le tableau de bord ZimaOS via l’adresse IP LAN ;
- vérifiez si le port d’une application fonctionne localement ;
- désactivez le nœud de sortie Tailscale actif ;
- réessayez d’accéder à l’application en local ;
- examinez ensuite les journaux de Docker ou de l’application si les ports restent indisponibles.
FAQ : toutes les applications sont indisponibles
La réinstallation des applications a-t-elle résolu le problème d’origine ?
Non. Les applications ont recommencé à fonctionner uniquement après la suppression de l’état de routage Tailscale problématique.
Un nœud de sortie Tailscale peut-il bloquer l’accès au réseau local ?
Oui. La documentation actuelle de Tailscale indique que l’accès au réseau local est désactivé par défaut lorsqu’un nœud de sortie est utilisé, sauf si l’utilisateur active l’accès au réseau local.
Docker a-t-il été confirmé comme étant en panne ?
Non. La résolution d’origine pointe vers un problème de routage plutôt que vers une défaillance du démon Docker.
