So testen Sie, ob DNS die Verbindungsfehler von Immich verursacht

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.

How to Test Whether DNS Is Causing Immich Connection Failures - Zima Store Online

DNS ist nur dann ein wahrscheinlicher Verursacher bei Immich, wenn der fehlschlagende Client den genauen Immich-Hostnamen nicht in die Adresse auflösen kann, über die er erreichbar sein sollte, oder wenn sich diese Antwort je nach Resolver, Netzwerk oder Zeitpunkt ändert.

Teste die Namensauflösung getrennt von der Erreichbarkeit der Anwendung. Eine erfolgreiche Verbindung auf IP-Ebene kann zeigen, dass eine Route und ein Port vorhanden sind, beweist aber nicht, dass HTTPS, Reverse-Proxy-Routing, Zertifikate oder hostbasierte Regeln ohne den Hostnamen funktionieren. Der sicherste Ablauf dokumentiert den genau fehlschlagenden Namen, fragt ihn vom betroffenen Client ab, vergleicht Resolver und wiederholt anschließend die ursprüngliche Immich-Aktion nach genau einer Änderung auf DNS-Ebene.

Den genauen Hostnamen und Fehlerpfad festlegen

Notiere den Hostnamen, den der fehlschlagende Immich-Client tatsächlich verwendet, das verwendete Netzwerk, den Zeitpunkt des Fehlers und ob die Webanwendung, die mobile App oder beide betroffen sind. Beginne nicht mit einem allgemeinen Test wie der Auflösung einer beliebigen öffentlichen Domain, da dies nur beweist, dass irgendein DNS-Pfad funktioniert.

Vergleiche denselben Hostnamen von einem funktionierenden und dem fehlschlagenden Client aus. Notiere jede A- und AAAA-Antwort, den antwortenden Resolver und ob sich der Client im Heimnetz, im Mobilfunknetz oder hinter einem VPN befindet. Unterschiedliche Antworten können bei Split-DNS beabsichtigt sein, müssen jeden Client jedoch trotzdem zu einem erreichbaren Endpunkt führen.

Teste als Kontrolle, ob die erwartete Serveradresse und der Port erreichbar sind, ohne auf die normale DNS-Abfrage angewiesen zu sein. Betrachte dies nur als Unterscheidung des Netzwerkpfads: HTTPS-Zertifikate, SNI, Reverse-Proxys und virtuelle Hosts können eine Anfrage über eine IP-Adresse weiterhin ablehnen, selbst wenn der Dienst fehlerfrei läuft.

DNS vom fehlschlagenden Client abfragen, nicht nur vom Server

Führe eine DNS-Abfrage auf dem Gerät oder in der Umgebung aus, in der der Fehler tatsächlich auftritt. Wenn sich der Immich-Client hinter einem VPN, einem privaten DNS-Profil, einem Container-Stub oder einem vom Router bereitgestellten Resolver befindet, kann eine Abfrage direkt vom Server einen anderen Resolverpfad verwenden und das Problem verbergen.

Frage den fehlschlagenden Hostnamen zuerst über den Standardresolver des Clients ab und anschließend ausdrücklich über einen bekannten Vergleichsresolver oder den vorgesehenen internen Resolver. Eine gezielte dig-Abfrage zeigt die zurückgegebene Antwort, den antwortenden Server, den Status und die Abfragezeit. So lässt sich erkennen, ob der Fehler einem bestimmten Resolver folgt.

Wiederhole die Abfrage mehrmals, anstatt einer einzigen erfolgreichen Antwort zu vertrauen. Notiere NXDOMAIN, SERVFAIL, Zeitüberschreitungen, veraltete Adressen oder uneinheitliche A-/AAAA-Antworten. Eine stabile, korrekte Antwort lenkt den Verdacht weg von der grundlegenden DNS-Auflösung und hin zu Routing, Proxy, TLS, Firewall oder Anwendungskonfiguration.

Resolver-Ergebnisse und Fehlertypen vergleichen

Interpretiere den Antwortcode, bevor du Einstellungen änderst. NXDOMAIN bedeutet, dass der abgefragte Name aus Sicht dieses Resolvers nicht existiert; SERVFAIL bedeutet, dass die Auflösung nicht abgeschlossen werden konnte; eine Zeitüberschreitung bedeutet, dass der Resolver nicht rechtzeitig geantwortet hat. Eine syntaktisch erfolgreiche Antwort kann trotzdem falsch sein, wenn sie auf eine alte Routeradresse oder einen nicht erreichbaren Endpunkt verweist.

Fehler wegen eines nicht gefundenen Namens und vorübergehende Resolver-Fehler sind unterschiedliche Fälle. Nutze die Unterschiede bei Namensauflösungsfehlern, um zu entscheiden, ob ein fehlender Eintrag, ein nicht erreichbarer Resolver oder ein instabiler DNS-Pfad behoben werden muss, statt jeden Auflösungsfehler als dasselbe Problem zu behandeln.

Wenn nur der Heimnetz-Resolver die alte oder falsche Adresse zurückgibt, während ein anderer Resolver den vorgesehenen öffentlichen Wert liefert, prüfe lokale Überschreibungen, Split-DNS-Einträge, per DHCP bereitgestelltes DNS, Filterdienste und Caches. Wenn jeder Resolver dieselbe korrekte Adresse zurückgibt, ändere DNS nicht weiter und wende dich dem Dienstpfad zu.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Mit einer kontrollierten Umgehung DNS bestätigen oder ausschließen

Erstelle eine vorübergehende, rückgängig machbare Kontrolle, die nur die Namensauflösung für den fehlschlagenden Client ändert. Frage beispielsweise direkt einen anderen Resolver ab oder verwende vorübergehend einen Hosts-Datei-Eintrag, der den genauen Immich-Hostnamen der bekannten vorgesehenen Zieladresse zuordnet. Bewahre die ursprünglichen Einstellungen auf, damit der Test sofort rückgängig gemacht werden kann.

Wenn der ursprüngliche Immich-Ablauf funktioniert, während der Hostname identisch bleibt und sich nur sein Auflösungspfad geändert hat, ist DNS stark verdächtig. Wenn derselbe Hostname weiterhin fehlschlägt, nachdem er zur überprüften Zieladresse aufgelöst wird, liegt der Fehler hinter DNS. Prüfe dann Proxy-Routing, Zertifikate, NAT, Firewall-Regeln oder den Immich-Dienst selbst.

Wenn eine einzelne saubere Abfrage das Fehlerfenster im Haushalt nicht reproduzieren kann, vergleiche Host, Container, lokalen Resolver, übergeordneten Resolver, DHCP, VPN und Cache-Zustand über einen längeren Zeitraum. Eine mehrschichtige Prüfung von DNS-Fehlern hilft dabei, intermittierende Fälle zu erkennen, die bei einem einmaligen Test verschwinden.

Den richtigen Cache leeren und den ursprünglichen Immich-Ablauf erneut testen

Nachdem du einen DNS-Eintrag, Resolver, eine DHCP-Option, eine Split-DNS-Regel oder eine lokale Überschreibung korrigiert hast, leere nach Möglichkeit nur den relevanten Client- oder Resolver-Cache. Leere nicht wiederholt jede Ebene, ohne zu dokumentieren, was geändert wurde, da sich ein vorübergehender Erfolg sonst nicht mehr erklären lässt.

Löse den Hostnamen erneut vom betroffenen Client aus auf und überprüfe die vorgesehene A-/AAAA-Antwort, den Resolver und die Antwortzeit. Öffne anschließend Immich über den normalen Hostnamen, lade ältere Dateien, führe eine Suche durch und starte einen sicheren Upload oder eine andere Schreibaktion, damit der Test mehr als nur die Anmeldeseite abdeckt.

Wiederhole die Prüfung unter dem Netzwerkzustand, bei dem der Fehler ursprünglich auftrat, etwa im Mobilfunknetz, im Heim-WLAN, im per VPN verbundenen WLAN oder nach einer Router-/DHCP-Erneuerung. DNS ist nur dann als Grundursache ausgeschlossen, wenn der normale Hostname während des Auslösers, der den Fehler zuvor verursacht hat, korrekt bleibt. Andernfalls bewahre die neuen Erkenntnisse auf und setze die Untersuchung auf der nächsten Netzwerkschicht fort.