Die Immich-Anmeldung schlägt nach dem Neustart des Reverse-Proxys fehl

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.

Wenn die Immich-Anmeldung erst nach einem Neustart des Reverse-Proxys fehlschlägt, sollten Sie zunächst nachweisen, ob der Proxy-Pfad unterbrochen ist, während die Immich-Anwendung und das Konto weiterhin direkt funktionieren.

Ein Neustart kann veraltete Upstream-Adressen, fehlende Mitgliedschaften im gemeinsamen Netzwerk, Änderungen an Headern, ein verändertes Cookie-Verhalten oder einen Proxy-Prozess sichtbar machen, der vor der Erreichbarkeit seiner Abhängigkeiten wieder gestartet wurde. Testen Sie dasselbe Konto über den lokalen Immich-Endpunkt und den normalen öffentlichen Hostnamen. Folgen Sie anschließend der ersten Ebene, auf der die beiden Pfade voneinander abweichen.

Direkten Zugriff verwenden, um Authentifizierung und Proxy-Fehler zu unterscheiden

Testen Sie ein bekanntes Konto über einen vertrauenswürdigen lokalen Pfad, der den Reverse-Proxy umgeht, gegen den Immich-Server. Wenn die direkte Anmeldung erfolgreich ist, während der öffentliche Hostname endlos lädt, umleitet oder einen Upstream-Fehler zurückgibt, sind der Benutzerdatensatz und der grundlegende Authentifizierungspfad wahrscheinlich intakt. Konzentrieren Sie die Untersuchung auf Proxy, TLS, Routing und den Browserstatus.

Ein Community-Fall, in dem der direkte Zugriff funktionierte, während die Anmeldung über den Proxy fehlschlug, veranschaulicht diese Isolationsmethode. Der Bericht ist versionsspezifisch. Verwenden Sie ihn daher als Begründung für den Vergleich der Pfade und nicht als Beweis für dieselbe Ursache.

Wenn sowohl die direkte Anmeldung als auch die Anmeldung über den Proxy fehlschlagen, ändern Sie keine weiteren Proxy-Einstellungen. Prüfen Sie stattdessen den Zustand des Immich-Dienstes, die Datenbankverbindung, den Kontostatus und die Serverprotokolle. Ein zeitnaher Proxy-Neustart kann zufällig mit dem Fehler zusammenfallen. Der Umgehungstest verhindert, dass dieser zeitliche Zusammenhang zu einer unbelegten Diagnose wird.

Prüfen, ob der Proxy den aktuellen Immich-Upstream erreichen kann

Bestätigen Sie nach dem Neustart des Proxys, dass er den Immich-Upstream aus seinem eigenen Netzwerk-Namespace auflösen und verbinden kann. In Docker ist ein Upstream auf Basis des Dienstnamens in einem gemeinsamen benutzerdefinierten Netzwerk im Allgemeinen stabiler als eine manuell kopierte Container-IP, die sich beim Neuerstellen eines Containers ändert.

Eine Diskussion über einen Reverse-Proxy-Ausfall im Zusammenhang mit der Verbindung zwischen Proxy und Immich zeigt, warum die Erreichbarkeit des Upstreams und eine WebSocket-fähige Proxy-Konfiguration vor der Kontowiederherstellung geprüft werden sollten. Betrachten Sie die konkrete Konfiguration als anekdotischen Hinweis und nicht als Vorlage für jeden Proxy.

Starten Sie den Proxy zweimal allein neu und beobachten Sie, ob sein Upstream jedes Mal zum selben Dienst aufgelöst wird. Der Test ist bestanden, wenn die Verbindung sofort erfolgreich hergestellt wird, ohne Adressen zu bearbeiten. Wenn sich Namensauflösung, Netzwerkmitgliedschaft oder Zielport nach einer Neuerstellung ändern, korrigieren Sie die Compose-Netzwerkdefinition, anstatt den Stack wiederholt neu zu starten.

Weitergeleitete Header, TLS und Cookie-Verhalten prüfen

Die Anmeldung kann auch dann fehlschlagen, wenn der Proxy die Immich-Seite zurückgibt, da die Authentifizierung vom vollständigen HTTP-Pfad abhängt. Vergleichen Sie die Proxy-Konfiguration vor und nach dem Neustart, einschließlich der Weiterleitung von Host und Schema, der HTTPS-Terminierung, etwaiger Cookie-Umschreibungen und der Frage, ob ein weiterer Proxy oder Tunnel die Antwort ebenfalls verändert.

Eine Immich-Community-Diskussion dokumentiert einen Anmeldefall mit doppelten Cookies, bei dem die Cookie-Verarbeitung des Proxys zu einer hängenden Anmeldung führte. Dies ist ein begrenzter Einzelfall, erinnert aber daran, die Browserantwort und Cookies zu prüfen, statt davon auszugehen, dass gültige Zugangsdaten automatisch eine erfolgreiche Sitzung über den Proxy garantieren.

Löschen Sie nicht alle Konten und setzen Sie nicht die Datenbank zurück, nur weil eine Browsersitzung festzustecken scheint. Verwenden Sie nach dem Sichern der ursprünglichen Cookies und Antwort ein privates Fenster oder einen zweiten Browser. Wenn ein sauberer Client funktioniert, löschen Sie nur den betroffenen Website-Status und korrigieren Sie die Proxy-Regel, die das fehlerhafte Cookie oder die fehlerhafte Weiterleitung erzeugt hat.

-15% OFF

Proxy-Zugriffs- und Fehlerprotokolle zum Zeitpunkt der fehlgeschlagenen Anfrage lesen

Wiederholen Sie einen Anmeldeversuch und notieren Sie die genaue Uhrzeit, den öffentlichen Hostnamen, den Client und den zurückgegebenen Status. Prüfen Sie anschließend die Zugriffs- und Fehlerprotokolle des Proxys rund um diese Anfrage. Unterscheiden Sie zwischen einer Anfrage, die den Proxy nie erreicht hat, einem vom Proxy erzeugten 4xx- oder 5xx-Fehler, einem Verbindungsfehler zum Upstream und einer Anfrage, die Immich erreicht und eine Anwendungsantwort erhalten hat.

Der Workflow zur Fehlerbehebung bei NGINX-Protokollen zeigt, wie Status, Upstream-Fehler, Anfragezeiten und gezielte Protokollierung deutlich aussagekräftigere Hinweise liefern als wiederholtes Aktualisieren der Anmeldeseite. Wenden Sie dasselbe Prinzip auf Caddy, Traefik oder einen anderen Proxy an.

Wenn das Proxy-Protokoll eine erfolgreiche Upstream-Antwort zeigt, der Browser die Anmeldung aber nicht abschließen kann, prüfen Sie Weiterleitungen, Cookies, TLS und den Clientstatus. Wenn der Proxy keine Verbindung zum Upstream herstellen kann, korrigieren Sie Routing oder Dienstbereitschaft. Wenn Immich selbst den Fehler zurückgibt, folgen Sie dem entsprechenden Serverprotokoll, statt den Proxy als Ursache zu behandeln.

Nachweisen, dass die Behebung den ursprünglichen Neustart übersteht

Wiederholen Sie nach der Korrektur der bestätigten Ursache genau den Auslöser: Starten Sie nur den Reverse-Proxy neu, warten Sie auf dessen Zustandsprüfung und melden Sie sich über den öffentlichen Hostnamen an. Öffnen Sie anschließend ein vorhandenes Asset, laden Sie eine kleine Datei hoch und lassen Sie die Sitzung lange genug aktiv, um den normalen API-Datenverkehr zu überprüfen.

Der ZimaSpace-Leitfaden zu kontrollierten Fernzugriffspfaden verdeutlicht den übergeordneten Rahmen: Der Proxy ist nur eine Ebene des Fernzugriffs. Daher müssen DNS, TLS, Authentifizierung und der private Upstream bewusst konfiguriert und beobachtbar bleiben.

Der Test ist nur bestanden, wenn die Anmeldung zwei Proxy-Neustarts übersteht und dieselbe Konfiguration nach einem vollständigen Neustart des Stacks sauber startet. Machen Sie kürzlich vorgenommene Proxy-Änderungen rückgängig, wenn eine neue Header- oder Cookie-Regel den Fehler verursacht hat. Eskalieren Sie den Fall mit dem Diff der Proxy-Konfiguration, dem Anfragestatus, dem Upstream-Fehler, dem Zeitstempel des Serverprotokolls sowie dem Ergebnis des direkten und des Proxy-Tests.

Support & Tipps

Mehr zum Lesen

So verhindern Sie doppelte Jobs oder Importe in Immich
Sep 08, 2026

So verhindern Sie doppelte Jobs oder Importe in Immich

Trennen Sie wiederholte Aufträge von doppelten Assets. Verwenden Sie einen einzigen kanonischen Aufnahmeweg, kontrollieren Sie Wiederholungsversuche und Pfadänderungen und testen Sie anschließend den erneuten...

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.