Immich-Netzwerk: Wie Erkennung, DNS und Routing Erreichbarkeit ermöglichen

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Immich Networking: How Discovery, DNS, and Routing Produce Reachability

Die Erreichbarkeit von Immich ergibt sich aus einer geordneten Kette: Endpunktauswahl, DNS-Auflösung, Paketrouting, Proxy- oder NAT-Weiterleitung und Anwendungsantwort.

Ein Telefon kann Immich über die lokale IP-Adresse erreichen, während derselbe Hostname im WLAN fehlschlägt, oder remote funktionieren, während zu Hause ein längerer Pfad verwendet wird. Diese Ergebnisse entstehen durch unterschiedliche Namens- und Routenentscheidungen, nicht durch einen einheitlichen Zustand „Netzwerk ist verfügbar“.

Die Erreichbarkeit beginnt mit dem vom Client ausgewählten Endpunkt

Ein Client kann nicht zu „Immich“ als abstraktem Dienst routen. Er verwendet ein Schema, einen Hostnamen oder eine Adresse, einen Port und manchmal einen Pfad. Native Anwendungen, Browser, Lesezeichen und geteilte Links können unterschiedliche Endpunkte speichern. Ihre Erreichbarkeit kann voneinander abweichen, bevor überhaupt ein Paket den Server erreicht.

Ein Community-Thread zur lokalen und remote Bereitstellung von Immich beschreibt Schwierigkeiten, wenn ein Router kein Split-Horizon-Verhalten bereitstellen kann und dem Client die automatische Umschaltung auf einen lokalen Endpunkt fehlt. Der Fall zeigt, dass die Endpunktauswahl und die lokalen DNS-Funktionen gemeinsam bestimmen, welchen Pfad ein Client im Heimnetz versucht.

Notiere die exakte URL, die jeder Client verwendet, und halte fest, ob sie eingegeben, über einen Link aufgerufen oder zuvor gespeichert wurde. Vergleiche Schema, Host, Port und Pfad. Fasse eine funktionierende lokale IP-Adresse und einen fehlschlagenden öffentlichen Hostnamen nicht zu einem einzigen Ergebnis zusammen; es handelt sich um unterschiedliche Zielvorgaben.

DNS wählt eine Adresse aus, keinen funktionierenden Dienst

DNS wandelt den ausgewählten Hostnamen in eine Adresse um. Öffentliche und lokale Resolver können absichtlich unterschiedliche Antworten liefern, während veraltete Caches eine alte Router- oder Serveradresse beibehalten. Eine korrekte Antwort identifiziert lediglich ein Ziel; sie beweist nicht, dass Port, Proxy, Zertifikat oder Anwendung dort verfügbar sind.

Ein Fall aus der Caddy-Community beschreibt, dass Immich über die lokale IP-Adresse funktioniert, während ein lokaler Pfad über DuckDNS fehlschlägt und Fragen zu Hairpin-NAT aufwirft. Die Details sind umgebungsspezifisch, zeigen aber, dass sich Namensauflösung und Rückwege des Routers selbst im selben Heimnetz unterscheiden können.

Frage den Hostnamen über das Netzwerk des betroffenen Telefons oder Browsers ab und vergleiche ihn mit der erwarteten lokalen oder öffentlichen Adresse. Wiederhole den Test über mobile Daten. Wenn sich die Antworten absichtlich unterscheiden, dokumentiere Split-DNS. Wenn sie unerwartet abweichen, korrigiere den autoritativen Eintrag oder den Cache, bevor du Immich-Container änderst.

Routing, NAT und Proxys schließen die Zustellungskette ab

Nach der DNS-Auflösung benötigt der Client eine Route. Der Remote-Datenverkehr kann über einen Internetanbieter, Router, eine Portweiterleitung, einen Tunnel oder einen Reverse-Proxy laufen; lokaler Datenverkehr kann direkt verlaufen oder über den öffentlichen Rand zurückgeführt werden. Jede Schicht muss den richtigen Port zustellen und den von der Anwendung erwarteten Anfragekontext erhalten.

Der Immich-Datenpfad-Artikel von ZimaSpace trennt Abhängigkeiten von Client, Netzwerk, Anwendung, Datenbank und Medien. Dieses Schichtenmodell verhindert einen häufigen Fehler: Immich neu zu starten, obwohl die Anwendung lokal bereits antwortet und die erste fehlerhafte Abhängigkeit außerhalb des Containers liegt.

Verfolge den Pfad der Reihe nach: Adresse, Route, lauschender Port, Proxy-Ziel, TLS-Name und Anwendungsantwort. Ein erfolgreicher Ping reicht nicht aus, da der Web- oder API-Port weiterhin blockiert sein kann. Ebenso beweist eine vom Proxy angezeigte Startseite nicht, dass Anfragen den Immich-Dienst erreichen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Verwende eine schichtenweise Erreichbarkeitsprüfung

Erstelle zwei Spalten für Heim-WLAN und mobile Daten. Notiere in jeder Spalte die ausgewählte URL, die DNS-Antwort, Route oder Gateway, TCP-Verbindung, das TLS-Ergebnis, den HTTP-Status und eine authentifizierte Immich-API-Antwort. Verwende dasselbe Konto und dasselbe Asset, damit Identität oder Berechtigungen den Netzwerkvergleich nicht verändern.

Eine Anleitung zu Immich auf einem Heimserver zeigt DNS-Routing als Voraussetzung vor den Schritten für Zertifikat und Anwendungszugriff. Ihre Reihenfolge bestätigt die Diagnose-Regel: Spätere Schichten können eine falsche Zuordnung von Namen zu Adressen nicht ausgleichen, während korrektes DNS allein weder Weiterleitung noch Zustand der Anwendung bestätigt.

Halte bei der ersten Schicht an, deren beobachteter Wert vom erwarteten Pfad abweicht. Korrigiere nur diese Schicht und wiederhole anschließend beide Spalten, da eine Remote-Korrektur das lokale Hairpin-Verhalten beeinträchtigen kann. Die Erreichbarkeit gilt als bestätigt, wenn beide vorgesehenen Pfade dieselbe Anwendungsanfrage vollständig ausführen, nicht lediglich dann, wenn ein Hostname aufgelöst wird.