So erkennen Sie, ob ein Immich-Fehler vom Client oder Server stammt

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 Tell Whether an Immich Error Comes From the Client or Server - Zima Store Online

Stellen Sie fest, ob ein Immich-Fehler clientseitig oder serverseitig auftritt, indem Sie dieselbe Aktion mit nur einer geänderten Variable reproduzieren und die fehlgeschlagene Anfrage über den gesamten Pfad verfolgen.

Ein mobiles Banner mit der Meldung „Serverfehler“ kann dennoch durch den Clientzustand, TLS, einen Reverse-Proxy oder eine vom Server korrekt abgelehnte Anfrage verursacht werden. Ebenso beweist ein ausschließlich im Browser auftretender Fehler nicht, dass der Browser defekt ist. Halten Sie Konto, Asset und Aktion konstant, vergleichen Sie Clients und Routen und ermitteln Sie anschließend mithilfe von Statuscodes und synchronisierten Protokollen die erste fehlerhafte Schicht.

Dieselbe Aktion auf einem zweiten Client reproduzieren

Wählen Sie eine eindeutig reproduzierbare Aktion, etwa die Anmeldung, das Öffnen eines bekannten Assets, das Hochladen desselben kleinen Fotos oder das Ausführen derselben Suche. Wiederholen Sie sie mit demselben Konto in einem Browser und einem mobilen Client, während die Netzwerkroute unverändert bleibt. Notieren Sie für beide Versuche die genaue Uhrzeit und das Ergebnis.

Ein aktueller Immich-Bericht, in dem ein Android-Client fehlschlug, während andere Zugriffswege getestet wurden, zeigt den Nutzen des Vergleichs zwischen Clients. Die Ursache in einem einzelnen Thread lässt sich nicht verallgemeinern, aber ein clientspezifisches Ergebnis grenzt den nächsten Prüfbereich deutlich ein.

Wenn jeder Client dieselbe Aktion zur selben Zeit nicht ausführen kann, rücken Server, Datenbank, Speicher oder ein gemeinsam genutzter Netzwerkpfad auf der Liste nach oben. Wenn nur ein Client fehlschlägt, während ein anderer denselben Endpunkt erfolgreich erreicht, prüfen Sie die Clientversion, den Cache-Zustand, Berechtigungen, das lokale Zertifikatsvertrauen und die genaue abweichende Anfrage.

Die Route ändern, ohne Konto oder Asset zu ändern

Vergleichen Sie anschließend eine vertrauenswürdige lokale Route mit der üblichen Route über Reverse-Proxy, VPN, Tunnel oder Fernzugriff. Verwenden Sie dasselbe Konto und dieselbe Aktion. Ein lokaler Erfolg bei gleichzeitigem Fehler aus der Ferne weist eher auf DNS-, TLS-, Proxy-, Firewall- oder Upstream-Routing-Schichten als auf den Mediendatensatz selbst hin.

Der ZimaSpace-Leitfaden zur Diagnose lokaler und entfernter Pfade erklärt, warum ein Erfolg im LAN und ein Erfolg über das Internet unterschiedliche Belege sind. Wenden Sie diese Abgrenzung auf Immich an, bevor Sie eine mobile App neu installieren oder den Server neu aufsetzen.

Wenn beide Routen identisch fehlschlagen, ändern Sie nicht weiter die Proxy-Einstellungen, sondern prüfen Sie die Anfrage auf Anwendungsebene. Wenn nur die Proxy-Route fehlschlägt, erfassen Sie den Proxy-Status, das TLS-Ergebnis, die Upstream-Antwort und den Timeout. Dieser Vergleich mit nur einer geänderten Variable verhindert, dass eine Clientmeldung die Untersuchung in die falsche Schicht lenkt.

Statuscodes als Hinweise, nicht als endgültiges Urteil verwenden

HTTP-Statusklassen helfen bei der Eingrenzung, identifizieren jedoch nicht automatisch die Komponente, die den Zustand verursacht hat. Ein 4xx bedeutet häufig, dass die Anfrage, Authentifizierung oder Autorisierung nicht akzeptiert wurde; ein 5xx zeigt an, dass eine serverseitige Komponente die Anfrage nicht erfüllen konnte. Proxys können beide Klassen erzeugen, bevor Immich die Anfrage überhaupt sieht.

Der Leitfaden zu Zugriffsprotokollen hebt Statuscode, URL-Pfad, Anfragezeit, entfernten Host und Anfragekennungen als nützliche Felder für die Fehlerbehebung hervor. Erfassen Sie diese Werte für die eine fehlschlagende Aktion, statt Tausende irrelevanter Zeilen zu durchsuchen.

Wenn der Proxy einen 502-Fehler oder Timeout ohne passende Immich-Anfrage protokolliert, verfolgen Sie den Upstream-Pfad. Wenn Immich eine Anfrage protokolliert und deterministisch mit 4xx antwortet, prüfen Sie Authentifizierung, Berechtigungen oder Anfrageinhalt. Wenn der Client einen Fehler meldet, aber alle serverseitigen Schichten 2xx anzeigen, untersuchen Sie die Clientverarbeitung, den lokalen Cache oder Folgeanfragen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Fehlerrate, Latenz und Serverprotokolle anhand eines Zeitpunkts korrelieren

Eine fehlgeschlagene Anfrage kann ein Ausreißer sein. Reproduzieren Sie die Aktion fünf- bis zehnmal und notieren Sie Erfolgsrate und Latenz, während Sie die relevanten Server- und Proxyprotokolle beobachten. Wenn die Fehler bei Ressourcenknappheit oder steigenden Warteschlangen auftreten, kann der Server zeitweise nicht verfügbar sein, auch wenn ein zweiter Versuch erfolgreich ist.

Die Better-Stack-Übersicht zu Fehlern und Latenz als Servicestatussignalen trennt Fehlerrate, Latenz und Datenverkehr. Diese Betrachtungsweise hilft dabei, eine einzelne fehlerhafte Clientanfrage von einem Serverpfad zu unterscheiden, der sich nur unter Last verschlechtert.

Wenn die Serverprotokolle bei mehreren Clients dieselbe Ausnahme enthalten, behandeln Sie den Fehler als serverseitig, bis das Gegenteil bewiesen ist. Wenn der Server die fehlschlagende Anfrage nie sieht, verfolgen Sie DNS, TLS, Proxy und Clientnetzwerk. Wenn nur ein Client eine andere Anfragestruktur erzeugt, aktualisieren oder setzen Sie diesen Client zurück, nachdem Sie genügend Belege gesichert haben, um den Unterschied zu bestätigen.

Die endgültige Einschätzung mit einem Zwei-mal-zwei-Test treffen

Verwenden Sie zwei Clients und zwei Routen: Browser-lokal, Browser-remote, mobil-lokal und mobil-remote. Behalten Sie dasselbe Konto und Test-Asset bei. Diese Matrix trennt clientspezifische Fehler von routenspezifischen Fehlern sowie von Serverfehlern, die jede Kombination betreffen.

Eine Clientursache wird dadurch gestützt, dass ein Client auf beiden Routen fehlschlägt, während ein anderer erfolgreich ist. Eine Routenursache wird dadurch gestützt, dass beide Clients nur über eine Route fehlschlagen. Eine Serverursache wird dadurch gestützt, dass alle vier Kombinationen denselben Anwendungsfehler reproduzieren und die Serverprotokolle denselben fehlschlagenden Vorgang zeigen.

Nachdem Sie die ermittelte Schicht repariert haben, führen Sie alle vier Kombinationen sowie einen Neustart der betroffenen Komponente erneut aus. Beenden Sie die Untersuchung, sobald die ursprünglich fehlschlagende Kombination funktioniert, ohne die Kontrollfälle zu beeinträchtigen. Eskalieren Sie mit der Matrix, Zeitstempeln, HTTP-Statuscodes, Auszügen aus Proxy- und Serverprotokollen, Clientversionen und einer reproduzierbaren Anfrage statt mit einem allgemeinen Screenshot.