Logowanie do Immich nie działa po ponownym uruchomieniu odwrotnego serwera proxy

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Immich Login Fails After the Reverse Proxy Restarts - Zima Store Online

Jeśli logowanie do Immich nie działa dopiero po ponownym uruchomieniu odwrotnego proxy, najpierw sprawdź, czy problem dotyczy ścieżki proxy, podczas gdy aplikacja Immich i konto nadal działają bezpośrednio.

Ponowne uruchomienie może ujawnić nieaktualne adresy upstream, brak członkostwa we wspólnej sieci, zmiany nagłówków, sposób obsługi plików cookie lub proces proxy, który uruchomił się, zanim jego zależności stały się dostępne. Przetestuj to samo konto przez lokalny punkt końcowy Immich i zwykłą publiczną nazwę hosta, a następnie prześledź pierwszą warstwę, na której obie ścieżki się rozchodzą.

Użyj bezpośredniego dostępu, aby oddzielić problem uwierzytelniania od awarii proxy

Przetestuj znane konto na serwerze Immich przez zaufaną lokalną ścieżkę, która omija odwrotne proxy. Jeśli logowanie bezpośrednie się powiedzie, a publiczna nazwa hosta będzie się ładować bez końca, przekierowywać lub zwróci błąd upstream, rekord użytkownika i podstawowa ścieżka uwierzytelniania prawdopodobnie działają poprawnie. Skup się na proxy, TLS, routingu i stanie przeglądarki.

Przypadek społeczności, w którym dostęp bezpośredni działał, a logowanie przez proxy nie, ilustruje tę metodę izolacji. Zgłoszenie dotyczy konkretnej wersji, więc wykorzystaj je jako uzasadnienie porównania ścieżek, a nie jako podstawę do założenia tej samej przyczyny.

Jeśli logowanie nie działa zarówno bezpośrednio, jak i przez proxy, przestań zmieniać ustawienia proxy. Sprawdź stan usług Immich, połączenie z bazą danych, stan konta i logi serwera. Ponowne uruchomienie proxy, które nastąpiło w pobliżu awarii, może być przypadkowe; test z pominięciem proxy zapobiega wyciąganiu nieuzasadnionych wniosków na podstawie samego czasu wystąpienia.

Sprawdź, czy proxy może dotrzeć do bieżącego upstream Immich

Po ponownym uruchomieniu proxy potwierdź, że może ono rozpoznać i połączyć się z upstream Immich z własnej przestrzeni nazw sieciowej. W Dockerze upstream oparty na nazwie usługi we wspólnej sieci zdefiniowanej przez użytkownika jest zwykle stabilniejszy niż ręcznie skopiowany adres IP kontenera, który zmienia się po jego odtworzeniu.

Dyskusja o awarii odwrotnego proxy dotycząca łączności między proxy a Immich pokazuje, dlaczego dostępność upstream i obsługa proxy zdolna do pracy z WebSocketami powinny zostać sprawdzone przed odzyskiwaniem konta. Traktuj dokładną konfigurację jako przykład anegdotyczny, a nie szablon dla każdego proxy.

Uruchom ponownie samo proxy dwukrotnie i obserwuj, czy za każdym razem jego upstream jest rozpoznawany jako ta sama usługa. Wynik pozytywny oznacza natychmiastowe pomyślne połączenie bez ręcznej edycji adresów. Jeśli po odtworzeniu zmieniają się rozpoznawanie nazw, członkostwo w sieci lub port docelowy, popraw definicję sieci w Compose zamiast wielokrotnie uruchamiać cały stos.

Sprawdź przekazywane nagłówki, TLS i obsługę plików cookie

Logowanie może nie działać nawet wtedy, gdy proxy zwraca stronę Immich, ponieważ uwierzytelnianie zależy od całej ścieżki HTTP. Porównaj konfigurację proxy sprzed i po ponownym uruchomieniu, w tym przekazywanie hosta i schematu, terminowanie HTTPS, przekierowania, ewentualne przepisywanie plików cookie oraz to, czy drugie proxy lub tunel również modyfikuje odpowiedź.

Jedna z dyskusji społeczności Immich opisuje przypadek logowania z duplikatem pliku cookie, w którym obsługa plików cookie przez proxy powodowała zawieszanie logowania. To konkretny przypadek, ale przypomina, aby sprawdzić odpowiedź i pliki cookie w przeglądarce, zamiast zakładać, że prawidłowe dane uwierzytelniające gwarantują pomyślną sesję przez proxy.

Nie usuwaj wszystkich kont ani nie resetuj bazy danych tylko dlatego, że sesja w przeglądarce wygląda na zawieszoną. Zapisz oryginalne pliki cookie i odpowiedź, a następnie użyj okna prywatnego lub drugiej przeglądarki. Jeśli czysty klient działa, wyczyść tylko stan dotyczący danej witryny i popraw regułę proxy, która utworzyła nieprawidłowy plik cookie lub przekierowanie.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Przeanalizuj logi dostępu i błędów proxy dla czasu nieudanego żądania

Powtórz jedną próbę logowania i zanotuj dokładny czas, publiczną nazwę hosta, klienta oraz zwrócony status. Następnie sprawdź logi dostępu i błędów proxy z tego okresu. Rozróżnij żądanie, które nigdy nie dotarło do proxy, błąd 4xx lub 5xx wygenerowany przez proxy, błąd połączenia z upstream oraz żądanie, które dotarło do Immich, ale otrzymało odpowiedź aplikacji.

Procedura rozwiązywania problemów z logami NGINX pokazuje, jak status, błędy upstream, czas żądania i ukierunkowane logowanie dostarczają znacznie lepszych informacji niż wielokrotne odświeżanie strony logowania. Zastosuj tę samą zasadę do Caddy, Traefik lub innego proxy.

Jeśli log proxy pokazuje pomyślną odpowiedź upstream, a przeglądarka nie może dokończyć logowania, sprawdź przekierowania, pliki cookie, TLS i stan klienta. Jeśli proxy nie może połączyć się z upstream, napraw routing lub gotowość usługi. Jeśli błąd zwraca sam Immich, przeanalizuj odpowiedni log serwera zamiast uznawać proxy za przyczynę.

Potwierdź, że poprawka przetrwa ponowne uruchomienie, które pierwotnie spowodowało problem

Po usunięciu potwierdzonej przyczyny powtórz dokładnie pierwotny scenariusz: uruchom ponownie tylko odwrotne proxy, poczekaj na jego sprawdzenie stanu i zaloguj się przez publiczną nazwę hosta. Następnie otwórz istniejący zasób, prześlij mały plik i utrzymuj sesję wystarczająco długo, aby potwierdzić prawidłowy ruch API.

Przewodnik ZimaSpace dotyczący kontrolowanych ścieżek zdalnego dostępu wyznacza szerszą granicę: proxy jest tylko jedną warstwą zdalnego dostępu, dlatego DNS, TLS, uwierzytelnianie i prywatny upstream muszą pozostać celowe i możliwe do monitorowania.

Uznaj poprawkę za skuteczną dopiero wtedy, gdy logowanie przetrwa dwa ponowne uruchomienia proxy, a ta sama konfiguracja uruchomi się poprawnie po pełnym ponownym uruchomieniu stosu. Wycofaj ostatnie zmiany proxy, jeśli nowa reguła nagłówków lub plików cookie spowodowała problem. Zgłaszając problem, dołącz różnicę konfiguracji proxy, status żądania, błąd upstream, znacznik czasu z logu serwera oraz wynik testu bezpośredniego i przez proxy.