Die Ausgangslage ist ungewöhnlich eindeutig: Dies war kein Docker-Fehler, der alle Anwendungen betraf. Der Benutzer hatte Tailscale mit einer Exit-Node-Konfiguration eingerichtet. Danach funktionierten Jellyfin und die URLs anderer Anwendungen selbst im lokalen Netzwerk nicht mehr. Später deinstallierte er Tailscale, stellte die Verbindung über die LAN-IP von ZimaOS her und berichtete, dass wieder alles funktionierte.
Dieses Verhalten stimmt mit der aktuellen Tailscale-Dokumentation überein. Wenn ein Client eine Exit-Node verwendet, ist der Zugriff auf das lokale LAN standardmäßig deaktiviert, sofern Zugriff auf das lokale Netzwerk erlauben nicht aktiviert ist. Bevor Sie Anwendungen neu installieren oder Docker neu starten, überprüfen Sie die Routing-Tabelle und ob der Client den Datenverkehr absichtlich über eine Exit-Node sendet.
Auch direkte App-Ports waren nicht erreichbar
Der Benutzer versuchte, die Anwendungs-Ports direkt zu öffnen, und sagte, dass außer Tailscale keiner funktionierte. Das ist ein wichtiger Hinweis: Wenn mehrere voneinander unabhängige Container gleichzeitig nicht erreichbar sind, sollten Sie zunächst die gemeinsam genutzten Netzwerk- und Routing-Ebenen prüfen, bevor Sie annehmen, dass jede Anwendung einzeln ausgefallen ist.
Ein fehlgeschlagener Docker-Neustartbefehl war eine Ablenkung
ZimaOS ist kein gewöhnliches Debian-System, auf dem jeder Dienstverwaltungsbefehl aus Online-Tutorials funktioniert. Wenn alle Anwendungen ausfallen, prüfen Sie zunächst, ob die Container tatsächlich laufen und ob ihre veröffentlichten Ports vom Host oder LAN aus erreichbar sind.
Exit-Nodes ändern die Standardroute des Clients
Tailscale-Exit-Nodes leiten den allgemeinen Internetverkehr über ein anderes Gerät im Tailnet. Die aktuelle Tailscale-Dokumentation weist ausdrücklich darauf hin, dass der Zugriff auf das lokale Netzwerk während der Verwendung einer Exit-Node standardmäßig deaktiviert ist.
Siehe das aktuelle Verhalten von Tailscale-Exit-Nodes.
Aktivieren Sie „Zugriff auf das lokale Netzwerk erlauben“, wenn Sie beides benötigen
Aktuelle Tailscale-Clients bieten die Option Zugriff auf das lokale Netzwerk erlauben. Bei CLI-basierten Clients lässt sich dies entsprechend über das Exit-Node-Flag für den LAN-Zugriff konfigurieren.
Aktivieren Sie diese Option nur, wenn Sie dem lokalen Netzwerk vertrauen.
Deaktivieren Sie die Exit-Node, um das Problem einzugrenzen
Eine schnelle Diagnose besteht darin, als aktive Exit-Node Keine auszuwählen und anschließend die ZimaOS-LAN-IP sowie einen App-Port erneut aufzurufen. Wenn der lokale Zugriff sofort wieder funktioniert, sollte die Routing-Konfiguration – und nicht Docker – vorrangig untersucht werden.
Der ursprüngliche Verfasser entfernte Tailscale und bestätigte die Wiederherstellung
Der Benutzer sagte, dass die Verbindung des Computers zum Router bzw. zum lokalen IP-Pfad unterbrochen wurde, sobald er über seine Tailscale-Konfiguration verbunden war. Nach der Deinstallation von Tailscale und der Verwendung der lokalen IP funktionierten wieder alle Anwendungen.
Damit ist die Wiederherstellung durch die Ausgangsquelle bestätigt, auch wenn der Benutzer die genauen Exit-Node-Flags, die das fehlerhafte Verhalten verursacht hatten, nicht dokumentierte.
Eine bessere Reihenfolge zur Fehlerbehebung
- Öffnen Sie das ZimaOS-Dashboard direkt über die LAN-IP;
- prüfen Sie, ob ein App-Port lokal funktioniert;
- deaktivieren Sie die aktive Tailscale-Exit-Node;
- versuchen Sie erneut, auf die lokale Anwendung zuzugreifen;
- prüfen Sie erst danach Docker- und App-Protokolle, falls die Ports weiterhin nicht erreichbar sind.
FAQ: „Service nicht verfügbar“ bei allen Anwendungen
Hat die Neuinstallation der Anwendungen das ursprüngliche Problem behoben?
Nein. Die Anwendungen funktionierten erst wieder, nachdem der problematische Tailscale-Routing-Zustand entfernt worden war.
Kann eine Tailscale-Exit-Node den Zugriff auf das lokale LAN blockieren?
Ja. Laut aktueller Tailscale-Dokumentation ist der LAN-Zugriff bei Verwendung einer Exit-Node standardmäßig deaktiviert, sofern der Benutzer den Zugriff auf das lokale Netzwerk nicht aktiviert.
Wurde bestätigt, dass Docker selbst defekt war?
Nein. Die Lösung laut Ausgangslage deutet auf ein Routing-Problem und nicht auf einen Ausfall des Docker-Daemons hin.
