Rozwiązanie społecznościowe

Błąd 502 Jellyfin za Nginx Proxy Manager na ZimaOS: trzy adresy do sprawdzenia

Posts 61–80 follow recurring Jellyfin 502 errors, clarify public, LAN, and Docker addresses, and show why proxy routing and case-sensitive backup paths must be diagnosed separately.

Czwarta strona długiej dyskusji dotyczącej wsparcia ZimaOS opisuje powtarzające się problemy jednego użytkownika z Jellyfin i Nginx Proxy Managerem po pierwszej udanej konfiguracji zdalnego dostępu. Najważniejsza lekcja nie dotyczy jednego magicznego portu: błąd 502 może powrócić za każdym razem, gdy zmieni się miejsce docelowe odwrotnego proxy, mapowanie portów Jellyfin, sieć Docker lub stan aplikacji.

Ta strona dotyczy wyłącznie postów 61–80. Nie powtarza wcześniejszych informacji o konfiguracji DuckDNS i certyfikatu omówionych w innym miejscu tego samego wątku.

Oddziel komunikat API NPM od błędu 502 Jellyfin

Użytkownik najpierw zobaczył komunikat „Komunikacja z API nie powiodła się. Czy NPM działa prawidłowo?”. Analiza logów społeczności pokazała, że sam Nginx Proxy Manager działał, a odnowienie certyfikatu Let's Encrypt zakończyło się powodzeniem. Tymczasowy komunikat API mógł więc wynikać z nieaktualnej sesji przeglądarki lub krótkotrwałej przerwy w komunikacji interfejsu z backendem, podczas gdy publiczny błąd 502 pozostawał odrębnym problemem między proxy a Jellyfin.

Zrzut ekranu telefonu przedstawiający status Nginx Proxy Managera podczas diagnozowania błędu 502 w Jellyfin
Zrzuty ekranu posłużyły do odróżnienia komunikatu interfejsu NPM od utrzymującego się problemu z trasowaniem do backendu.

Rozróżniaj trzy typy adresów

Typ adresu Przykładowa rola Czy NPM powinien przekierowywać do tego adresu?
Publiczny adres WAN Adres dostępny z Internetu, aktualizowany przez DuckDNS Nie
Adres LAN ZimaOS Stabilny adres sieci domowej, taki jak 192.168.1.50 Tak, gdy Jellyfin publikuje port hosta
Adres lub nazwa kontenera Docker Wewnętrzny punkt końcowy, taki jak jellyfin:8096 Tak, tylko gdy NPM może uzyskać dostęp do tej samej sieci Docker

Wątek wielokrotnie przełączał się między nazwą kontenera, adresem LAN hosta i wewnętrznym adresem Docker. Nie są one wymienne. Wybierz jedną obsługiwaną trasę i przetestuj ją z kontenera NPM, zanim zmienisz TLS lub DNS.

Odczytuj mapowanie portów we właściwym kierunku

Ustawienia Jellyfin wskazywały port hosta 8097 mapowany na port kontenera 8096. Gdy NPM łączy się za pośrednictwem adresu LAN ZimaOS, musi używać opublikowanego portu hosta. Gdy NPM łączy się bezpośrednio przy użyciu nazwy kontenera we współdzielonej sieci Docker, zwykle używa wewnętrznego portu Jellyfin.

Ustawienia kontenera Jellyfin sfotografowane podczas porównywania portu hosta 8097 z portem kontenera 8096
Zrzut ekranu pomógł wyjaśnić, dlaczego właściwy port zależy od tego, czy NPM łączy się z hostem, czy bezpośrednio z siecią kontenera.

Resetowanie połączenia z poziomu NPM pokazało, że wybrana trasa nadal nie zwracała prawidłowej odpowiedzi Jellyfin. To bardziej przydatna informacja niż samo ponowne uruchomienie obu kontenerów.

Stosuj warstwową kolejność diagnostyki

  1. Otwórz Jellyfin lokalnie i potwierdź odtwarzanie, zanim zaczniesz zmieniać ustawienia proxy.
  2. Potwierdź, że kontener Jellyfin działa, i odczytaj zapisane mapowanie portu hosta na port kontenera.
  3. Wybierz stabilny adres LAN ZimaOS wraz z opublikowanym portem hosta albo nazwę kontenera wraz z portem wewnętrznym we współdzielonej sieci.
  4. Przetestuj dokładnie ten punkt końcowy ze środowiska NPM.
  5. Dopiero gdy routing HTTP działa, ponownie włącz TLS i przetestuj domenę publiczną.
  6. Po każdej edycji aplikacji lub ponownym uruchomieniu powtórz testy lokalne i testy proxy przed zmianą DNS.

Edycja ścieżki multimediów może wywołać inny problem

Później użytkownicy zdalni mogli przeglądać Jellyfin, ale nie mogli odtwarzać multimediów. Właściciel zmienił ustawienia kontenera Jellyfin, a publiczna witryna przestała odpowiadać. Późniejszy przegląd logów przez społeczność wykazał, że Jellyfin działał i skanował /Media/Movies, co skierowało uwagę z powrotem na cel serwera proxy. Pokazuje to, dlaczego każdą zmianę należy zapisywać i testować niezależnie.

Ścieżki systemu Linux uwzględniają wielkość liter podczas tworzenia kopii zapasowej

Tworzenie kopii zapasowej konfiguracji nie powiodło się, ponieważ polecenie odwoływało się do /DATA/AppData/duckdns, podczas gdy rzeczywisty katalog znajdował się w /DATA/AppData/DuckDNS. Linux traktuje je jako różne ścieżki. Wątek źródłowy proponował polecenie archiwizacji utworzone przez społeczność, ale nie zostało ono dostarczone przez IceWhale, więc nie jest tu powielane jako oficjalna procedura tworzenia kopii zapasowej.

Zrzut ekranu terminala przedstawiający ścieżkę kopii zapasowej AppData w ZimaOS, która nie odpowiadała wielkości liter w nazwie folderu DuckDNS
Awaria kopii zapasowej wynikała z niezgodności wielkości liter w nazwie katalogu AppData, a nie z uszkodzonego narzędzia do archiwizacji.

Przed zarchiwizowaniem folderu AppData wyświetl dokładne nazwy katalogów, zatrzymaj aplikacje, gdy ich bazy danych wymagają spójnego obrazu, i zweryfikuj archiwum, przywracając jego kopię do lokalizacji tymczasowej.

Aktualnie obsługiwany zdalny dostęp

Do administracji i dostępu do plików aktualna dokumentacja ZimaOS opisuje szyfrowany dostęp typu peer-to-peer za pośrednictwem zdalnego dostępu ZimaClient. Publiczny odwrotny serwer proxy Jellyfin pozostaje zaawansowaną konfiguracją z użyciem narzędzi innych firm i powinien udostępniać wyłącznie usługę multimedialną, a nie panel ZimaOS.

FAQ: błąd 502 w Jellyfin

Czy komunikat „NPM API failed” dowodzi, że NPM jest zatrzymany?

Nie. W wątku logi NPM i odnawianie certyfikatu działały prawidłowo, podczas gdy przeglądarka wyświetlała ten komunikat.

Czy NPM powinien używać portu 8096 czy 8097?

Użyj portu wewnętrznego przy bezpośredniej komunikacji między kontenerami albo opublikowanego portu hosta przy przekierowaniu na adres LAN ZimaOS.

Dlaczego kopia zapasowa zgłosiła, że DuckDNS nie istnieje?

Rzeczywisty folder AppData używał wielkiej litery D, podobnie jak DNS; ścieżki w systemie Linux uwzględniają wielkość liter.