Czy Jellyfin może działać za odwrotnym proxy w podkatalogu?

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.

Can Jellyfin Work Behind a Reverse Proxy on a Subpath? - Zima Store Online

Tak. Jellyfin może działać za odwrotnym serwerem proxy w ścieżce podrzędnej, takiej jak https://example.com/jellyfin, ale Jellyfin i proxy muszą używać tej samej ścieżki bazowej.

Awaria ścieżki podrzędnej zwykle wygląda jak częściowo działająca witryna: strona logowania może się wczytywać, podczas gdy JavaScript, obrazy, WebSockety, przekierowania lub klienci natywni nie działają. Testuj ścieżkę warstwami — najpierw Base URL, potem trasę proxy, a na końcu nagłówki przekazywane i adres klienta — aby odróżnić niezgodność ścieżki od problemu z TLS lub tożsamością proxy.

Dopasuj Base URL Jellyfin do publicznej ścieżki podrzędnej

Ustaw Base URL Jellyfin na dokładny publiczny prefiks, którego zamierzasz używać, na przykład /jellyfin. Nie dodawaj innego wewnętrznego prefiksu tylko dlatego, że proxy używa bloku named location; ścieżka widoczna w przeglądarce i Base URL Jellyfin muszą opisywać ten sam katalog główny aplikacji.

Oficjalna dokumentacja Apache dotycząca odwrotnego proxy dla Jellyfin zawiera przykład ścieżki podrzędnej i zaleca ustawienie Base URL na /jellyfin przed połączeniem klientów z pełnym adresem. oficjalny przykład ścieżki podrzędnej

Po zmianie Base URL uruchom ponownie Jellyfin, a następnie otwórz publiczną ścieżkę podrzędną w nowym prywatnym oknie przeglądarki. Jeśli początkowe przekierowanie natychmiast usuwa /jellyfin lub dodaje je podwójnie, napraw Base URL przed zmianą ustawień WebSocketów lub uwierzytelniania.

Przekieruj ten sam prefiks przez odwrotne proxy

Skonfiguruj odwrotne proxy tak, aby żądania zaczynające się od publicznego prefiksu były przekazywane do Jellyfin bez wprowadzania dodatkowej transformacji ścieżki. Najprostszy układ to jeden publiczny prefiks, jeden pasujący Base URL Jellyfin i jedna usługa upstream.

Przewodnik Caddy dla Jellyfin pokazuje ten sam schemat: skonfiguruj ścieżkę bazową Jellyfin, przekieruj prefiks bez końcowego ukośnika do wersji z końcowym ukośnikiem i przekazuj żądania w ramach tego prefiksu do backendu Jellyfin. zgodna ścieżka bazowa i trasa proxy

Jeśli przeglądarka otrzymuje błąd 404 od proxy, zanim Jellyfin zarejestruje żądanie, trasa jest nieprawidłowa na warstwie proxy. Jeśli Jellyfin otrzymuje żądanie, ale generuje linki bez prefiksu, nieprawidłowy jest Base URL na warstwie aplikacji. Nie mieszaj tych dwóch oznak awarii.

Sprawdź zasoby statyczne i WebSockety, nie tylko stronę logowania

Samo pomyślne otrzymanie odpowiedzi HTML nie wystarcza, aby uznać konfigurację ścieżki podrzędnej za poprawną. Otwórz narzędzia deweloperskie lub dziennik proxy i sprawdź, czy żądania JavaScript, CSS, obrazów, API i WebSocketów nadal używają tego samego publicznego prefiksu.

Przykłady odwrotnego proxy dla Jellyfin obejmują obsługę WebSocketów, ponieważ klienci interaktywni utrzymują połączenie gniazdowe oprócz zwykłych żądań HTTP. Reguła proxy obsługująca wyłącznie żądania stron może więc wyglądać poprawnie, dopóki nie przestaną działać informacje o odtwarzaniu, aktualizacje sesji lub zachowanie interfejsu na żywo. wymagania dotyczące odwrotnego proxy

Warunek poprawności jest prosty: brak powtarzających się odpowiedzi 404/502 dla zasobów z prefiksem, pomyślna aktualizacja połączenia WebSocket oraz nawigacja, która nie wychodzi do głównego katalogu witryny. Jeśli zawodzi tylko jedna klasa żądań, napraw odpowiednią regułę proxy zamiast zmieniać bibliotekę lub ustawienia uwierzytelniania Jellyfin.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Zachowaj tożsamość klienta przez proxy

Po uruchomieniu ścieżki sprawdź przekazywane informacje o kliencie. Jellyfin używa konfiguracji zaufania proxy, aby decydować, czy należy akceptować przekazywane adresy i protokoły, co wpływa na rozróżnianie ruchu lokalnego i zdalnego oraz reguły dostępu zewnętrznego.

Przewodnik sieciowy Jellyfin ostrzega, że nagłówki przekazywane przez niezaufane proxy są odrzucane, i zaleca skonfigurowanie adresu proxy w sekcji Known Proxies. ustawienie Known Proxies Osobna weryfikacja adresu IP klienta jest przydatna, gdy witryna działa, ale każde żądanie wygląda tak, jakby pochodziło od proxy.

Nie rozwiązuj problemu z tożsamością, ufając każdej prywatnej podsieci ani każdemu przekazywanemu nagłówkowi. Dodaj wyłącznie rzeczywisty przeskok proxy lub kontrolowaną sieć proxy, a następnie porównaj jedno żądanie z sieci LAN i jedno zdalne żądanie w dziennikach Jellyfin, aby potwierdzić ich prawidłową klasyfikację.

Testuj adresy przeglądarki i klientów natywnych osobno

Gdy klient Jellyfin poprosi o adres serwera, wpisz pełny adres serwera wraz ze ścieżką podrzędną. Klient zapisany jako https://example.com nie może samodzielnie ustalić, że Jellyfin działa pod adresem /jellyfin.

Przetestuj jedną przeglądarkę i jednego klienta natywnego z sieci LAN, a następnie powtórz test za pośrednictwem publicznej nazwy hosta. Jeśli nazwa hosta działa, ale bezpośredni dostęp przez lokalny adres IP nie, może to być oczekiwane, gdy trasa proxy i certyfikat zależą od nazwy hosta; testowanie nazwy hosta i adresu IP pomaga wyodrębnić ten przypadek bez osłabiania proxy.

Zakończ testy, gdy adres z prefiksem działa podczas logowania, nawigacji, korzystania z WebSocketów i odtwarzania na obsługiwanych przez Ciebie klientach. Jeśli zawodzi tylko jeden klient, podczas gdy przeglądarka i pozostali klienci działają, potraktuj to jako problem z adresem lub zgodnością klienta, zamiast przepisywać działającą konfigurację proxy.