Dlaczego Jellyfin traci sesje po zmianie serwera proxy lub DNS?

Zmiana serwera proxy lub DNS nie powinna automatycznie unieważniać wszystkich logowań do Jellyfin. Utrata sesji zwykle występuje wtedy, gdy zmiana modyfikuje również nazwę hosta, schemat, ścieżkę, tożsamość serwera backendowego, warstwę uwierzytelniania lub trasę klienta, której oczekuje istniejący stan logowania.

Zacznij od rozróżnienia zwykłej aktualizacji rekordu DNS od zmiany serwera źródłowego. Pozostaw jedno znane konto i urządzenie bez zmian, porównaj bezpośredni dostęp z sieci LAN ze zwykłą publiczną nazwą hosta i przechwyć pierwsze nieudane żądanie, zanim wyczyścisz dane klienta. Celem jest ustalenie, która granica uległa zmianie, a nie resetowanie użytkowników do momentu ustąpienia objawu.

Najpierw ustal, czy publiczny serwer źródłowy faktycznie się zmienił

Zapisz stary i nowy schemat, nazwę hosta, port, ścieżkę bazową oraz trasę proxy. Rekord DNS A lub AAAA może wskazywać ten sam host na inny adres bez zmiany originu przeglądarki, natomiast przejście z jednej nazwy hosta na inną lub zmiana ścieżki bazowej aplikacji tworzy inną granicę klienta. Migracje domen niestandardowych wymagają również zgodności aplikacji i ścieżki uwierzytelniania z nową domeną; lista kontrolna migracji domeny niestandardowej jasno pokazuje tę zależność między DNS a aplikacją.

Stan uwierzytelniania zależy od miejsca, w którym jest prezentowany. Przydatna lista kontrolna zakresu plików cookie sesji zaczyna się od określenia domeny i ścieżki przypisanej do każdego mechanizmu uwierzytelniania. Klienci Jellyfin nie przechowują stanu dokładnie w ten sam sposób, dlatego przetestuj dotknięte problemem urządzenie, zamiast zakładać, że zachowanie przeglądarki opisuje każdą aplikację.

Jeśli stara nazwa hosta nadal działa, a nowa prosi o logowanie, uznaj to za oczekiwaną migrację originu, dopóki nie zostanie wykazane coś innego. Jeśli ta sama nazwa hosta wylogowuje wszystkich dopiero po zmianie proxy, zachowaj nazwę hosta i przejdź do sprawdzenia tożsamości serwera nadrzędnego, nagłówków oraz uwierzytelniania po stronie proxy.

Sprawdź, czy DNS nadal kieruje do tej samej zamierzonej instancji Jellyfin

Rozwiąż nazwę hosta z klienta w sieci LAN oraz, jeśli dostęp zdalny ma znaczenie, z zewnętrznego resolvera. Potwierdź, że zwrócony adres prowadzi do właściwego odwrotnego proxy i że proxy kieruje do oczekiwanej usługi Jellyfin, a nie do starego kontenera, instancji testowej, klona po odtworzeniu lub drugiego serwera z inną trwałą bazą danych.

Przełączenie DNS może wyglądać jak problem z sesją, gdy w rzeczywistości klient trafia do innego backendu. Przed modyfikacją uwierzytelniania porównaj odpowiedź identyfikującą serwer, zachowanie listy użytkowników, stan bibliotek oraz docelowy upstream proxy. Jeśli nowa trasa prowadzi do świeżej lub odtworzonej instancji Jellyfin, istniejące dane uwierzytelniające klienta mogą już nie reprezentować prawidłowej sesji na tym serwerze.

Powiązany proces ZimaSpace dotyczący oddzielania cyklu życia proxy od cyklu życia stanu sesji jest tutaj przydatny: restart warstwy wejściowej nie powinien po cichu zastępować tożsamości aplikacji ani stanu używanego do weryfikowania istniejących sesji.

Porównaj przekazywany host, schemat, ścieżkę i uwierzytelnianie proxy

Przechwyć skuteczną konfigurację proxy po zmianie. Porównaj publiczną wartość Host, przekazywany schemat, adres klienta, ścieżkę ulepszenia połączenia WebSocket, przekierowania oraz wszelkie oprogramowanie pośredniczące uwierzytelniania z ostatnią działającą konfiguracją. Przekierowanie z HTTPS do nieoczekiwanego adresu HTTP lub hosta alternatywnego może sprawić, że prawidłowe logowanie będzie wyglądać tak, jakby zniknęło.

Jeśli przed Jellyfin działa dodatkowa warstwa uwierzytelniania, zachowaj bez zmian jej klucz podpisujący, nazwę pliku cookie, domenę pliku cookie oraz magazyn sesji podczas wymiany proxy. Konstrukcje z modułem równoważenia obciążenia wykorzystują stan sesji trwałej i stan routingu, aby utrzymać żądanie na właściwym backendzie; zmiana tej warstwy może powodować wylogowanie lub pętlę, nawet gdy sam Jellyfin działa prawidłowo.

Nie kopiuj bezmyślnie nagłówków z niezwiązanego przykładu konfiguracji proxy. Zmieniaj jedną wartość tylko wtedy, gdy nieudane żądanie lub przekierowanie pokaże, że obecna wartość jest nieprawidłowa. Najbezpieczniejsza konfiguracja proxy to najmniejszy zestaw ustawień, który zachowuje publiczny origin i konsekwentnie dociera do właściwego backendu.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Wykonaj test na czystym kliencie bez usuwania pierwotnych dowodów

Zanim cokolwiek wyczyścisz, zapisz czas wystąpienia problemu, wersję przeglądarki lub aplikacji, kod żądania, łańcuch przekierowań, wpis z dziennika proxy oraz wpis z dziennika Jellyfin. Następnie użyj prywatnego okna przeglądarki lub drugiego urządzenia testowego, aby zalogować się przez nową trasę. Udane nowe logowanie potwierdza osiągalność, ale nie wyjaśnia, dlaczego stary stan stał się bezużyteczny.

Porównaj kolejno trzy ścieżki: bezpośredni adres Jellyfin w sieci LAN, zwykłą nazwę hosta z sieci LAN oraz zwykłą nazwę hosta spoza sieci LAN. Jeśli bezpośredni dostęp działa, a dostęp przez nazwę hosta nie, pozostaw użytkowników i stan bazy danych bez zmian i sprawdź DNS, TLS, proxy lub oprogramowanie pośredniczące. Jeśli wszystkie ścieżki odrzucają to samo znane, prawidłowe konto, problem ponownie znajduje się wewnątrz Jellyfin lub w jego trwałym stanie.

Wyczyść dane konkretnej witryny na problematycznym kliencie dopiero po zebraniu dowodów dotyczących ścieżki żądania. Nie usuwaj od razu wszystkich zarejestrowanych urządzeń ani nie unieważniaj wszystkich sesji, ponieważ usuniesz porównanie pozwalające odróżnić migrację routingu od awarii uwierzytelniania po stronie serwera.

Zweryfikuj zmianę po wygaśnięciu DNS, restarcie proxy i ponownym uruchomieniu

Po zastosowaniu właściwej poprawki odczekaj na wygaśnięcie poprzedniego okna TTL DNS, zrestartuj tylko proxy, następnie zrestartuj usługę Jellyfin i na końcu uruchom ponownie hosta. Po każdym zdarzeniu powtórz testy logowania, wylogowania, rozpoczęcia odtwarzania, przewijania oraz ponownego połączenia, korzystając z tej samej nazwy hosta.

Stabilny wynik oznacza, że nazwa hosta nadal rozwiązuje się do właściwego proxy, proxy ponownie łączy się z właściwą instancją Jellyfin, istniejące sesje przetrwają zwykłe restarty komponentów, gdy powinny, a nowe logowanie pozostaje ważne. Jeśli problemy pojawiają się wyłącznie podczas uruchamiania całego stosu, użyj ścieżki odzyskiwania połączenia proxy z usługą nadrzędną, aby oddzielić gotowość usługi od uwierzytelniania.

Zapisz w dokumentacji wdrożenia końcową nazwę hosta, nazwę upstreamu proxy, ścieżkę bazową, źródło certyfikatu oraz każdy sekret sesji po stronie proxy. Dzięki temu przyszłe zmiany DNS lub proxy będzie można testować względem znanego kontraktu tożsamości, zamiast ponownie odtwarzać go na podstawie objawów w przeglądarce.

FAQ

Czy sama zmiana rekordu DNS unieważnia sesje Jellyfin?

Zwykle nie, jeśli nadal używane są ta sama nazwa hosta, schemat, ścieżka i instancja Jellyfin. Zmiana DNS staje się istotna dla sesji, gdy kieruje klientów do innego backendu, zmienia publiczny origin, modyfikuje TLS lub przekierowania albo zmienia warstwę uwierzytelniania przed Jellyfin.

Czy po zmianie proxy powinienem unieważnić wszystkie sesje Jellyfin?

Nie jako pierwszy krok naprawczy. Zachowaj jeden problematyczny klient jako źródło dowodów, potwierdź, że nowa trasa prowadzi do właściwego serwera, i osobno przetestuj nowe logowanie. Unieważniaj sesje tylko wtedy, gdy celowo zmieniono dane uwierzytelniające, istnieje podejrzenie ujawnienia tokenów lub potwierdzono, że stare dane klienta nie powinny być już zaufane.