Jeśli logowanie do Plexa przestaje działać dopiero po ponownym uruchomieniu odwrotnego proxy, najpierw potwierdź bezpośredni lokalny dostęp do Plexa; działająca sesja bezpośrednia przenosi źródło problemu na proxy, DNS lub ścieżkę TLS.
Najczęstszym błędem jest resetowanie danych logowania do Plexa, gdy sam serwer nadal działa prawidłowo. Odwrotne proxy dodaje adres upstreamu, nazwę hosta, certyfikat, nagłówki żądań, a czasem także sieć Docker między przeglądarką a Plexem. Testuj te warstwy po kolei. Celem naprawy nie jest tylko jednorazowe przywrócenie strony logowania, lecz zapewnienie, że ta sama trasa proxy przetrwa kontrolowany restart bez zmiany tożsamości serwera Plex.
Sprawdź, czy sam Plex jest nadal dostępny
Otwórz Plexa bezpośrednio w sieci LAN, używając adresu serwera i portu, których zwykle używasz do lokalnego zarządzania. Jeśli to samo konto pozwala się zalogować, a serwer się ładuje, pozostaw uwierzytelnianie Plexa i dane serwera bez zmian. Problem został już zawężony do ścieżki dodanej przez proxy.
Plex udostępnia niestandardowe adresy dostępu do serwera dla nietypowych konfiguracji sieciowych, takich jak odwrotne proxy i VPN-y. Jeśli adres publikowany przez Plexa nie odpowiada już nazwie hosta lub schematowi używanemu przez klienta, wykrywanie serwera i działanie bezpiecznego połączenia mogą stać się niespójne, nawet gdy bezpośredni dostęp lokalny nadal działa prawidłowo.
Jeśli bezpośredni dostęp lokalny również nie działa, przestań traktować restartu proxy jako przyczyny. Najpierw sprawdź stan kontenera Plex, logi serwera i podpięcie danych. Zasada rozgałęzienia jest prosta: dostęp bezpośredni działa — problem dotyczy ścieżki proxy; dostęp bezpośredni nie działa — problem dotyczy serwera lub kontenera.
Sprawdź upstream proxy po restarcie
Przejrzyj cel proxy i potwierdź, że wskazuje on na aktualną usługę Plex. Proxy skonfigurowane z użyciem tymczasowego adresu IP kontenera może przestać działać po ponownym utworzeniu kontenera lub sieci. Zamiast kopiować zmienny adres IP do konfiguracji proxy, użyj stabilnego adresu hosta albo nazwy usługi Docker w ramach wspólnej, zdefiniowanej przez użytkownika sieci.
Zdefiniowane przez użytkownika działanie sieci mostkowej Dockera zapewnia kontenerom w tej samej sieci komunikację opartą na nazwach oraz jawną izolację. Dzięki temu nazwa usługi jest trwalszym upstreamem niż adres kontenera, który może zmienić się podczas zdarzeń związanych z cyklem życia kontenera.
Po poprawieniu upstreamu przeładuj tylko proxy i ponownie otwórz proxowany adres URL Plexa. Jeśli proxy dociera już do Plexa, ale logowanie nadal zapętla się, kolejną gałęzią diagnostyki jest publiczna nazwa hosta, TLS lub publikowany adres dostępu, a nie trasa do kontenera.
Zweryfikuj nazwę hosta i ścieżkę TLS bez obniżania bezpieczeństwa
Potwierdź, że przeglądarka używa właściwej nazwy hosta HTTPS oraz że proxy przedstawia prawidłowy certyfikat dla tej nazwy. Nie rozwiązuj problemu z niezgodnością certyfikatu lub nazwy hosta przez globalne wyłączanie bezpiecznych połączeń. Jeśli zmieniono domenę lub ścieżkę proxy, zaktualizuj niestandardowy adres dostępu w Plexie, aby wykrywanie serwera kierowało klientów na trasę, którą faktycznie utrzymujesz.
W szerszym kontekście projektowania zdalnego dostępu poradnik ZimaSpace dotyczący zdalnego dostępu do prywatnej chmury podkreśla znaczenie kontrolowanych bram, tuneli i jasno określonych granic zamiast bezmyślnego otwierania usług. Ta sama zasada obowiązuje tutaj: napraw właściwą ścieżkę wejściową zamiast omijać ją przez niebezpieczne tymczasowe wystawienie usługi.
Wyczyść sesję przeglądarki dopiero po pomyślnym przejściu kontroli routingu i TLS. Nieaktualny plik cookie może utrudniać testowanie, ale wyczyszczenie stanu przed naprawą ścieżki sieciowej może ukryć rzeczywistą przyczynę awarii. Użyj prywatnego okna przeglądarki jako czystego środowiska testowego, bez usuwania działającego stanu klienta wszędzie.
Uruchom proxy ponownie i powtórz pierwotny test logowania
Gdy logowanie zacznie działać, celowo uruchom odwrotne proxy ponownie. Poczekaj, aż odzyska sprawność, a następnie użyj dokładnie tej samej nazwy hosta i klienta, które pierwotnie powodowały problem. Pomyślna naprawa oznacza, że upstream się rozwiązuje, TLS jest prawidłowy, Plex jest wykrywany pod właściwym adresem URL, a konto może zalogować się bez ręcznych zmian po restarcie.
Jeśli drugi restart ponownie przerwie działanie trasy, sprawdź kolejność uruchamiania i rozwiązywanie nazw między proxy a Plexem. Problem nie jest rozwiązany, jeśli po każdym zdarzeniu związanym z cyklem życia kontenera człowiek musi ręcznie zmieniać adres IP. Ujawnij tę zależność w konfiguracji sieci Docker lub proxy.
Sięgnij po diagnostykę uwierzytelniania Plexa dopiero wtedy, gdy routing bezpośredni i proxowany działa prawidłowo, a mimo to logowanie nadal nie powiedzie się na różnych klientach. W takim przypadku zbierz logi Plexa z sygnaturami czasowymi oraz szczegółami konta i serwera, zamiast dalej zmieniać ustawienia proxy, które przeszły już weryfikację.
Wsparcie i wskazówki
Więcej do przeczytania

Czy Plex może współdzielić kartę graficzną z innym kontenerem Dockera?
Plex i inny kontener często mogą korzystać z tego samego układu GPU, ale należy przetestować obsługę sterowników, mapowanie urządzeń, obciążenie silnika wideo, pamięć oraz...

Jak ustalić, czy błąd Plex pochodzi od klienta, czy od serwera
Odtwórz ten sam przypadek na innym kliencie, porównaj ścieżkę sesji, a następnie zbierz dowody z serwera dopiero wtedy, gdy zakres analizy wskaże, gdzie faktycznie...

Jak skonfigurować pamięć podręczną Plex i tymczasową pamięć na transkodowane pliki
Chroń trwały stan Plex, umieszczając tymczasowe pliki transkodowania na odpowiedniej pamięci lokalnej, a następnie zweryfikuj czyszczenie, ilość wolnego miejsca i zachowanie podczas ponownego uruchamiania.

