Gemenskapslösning

Jellyfin 502 bakom Nginx Proxy Manager på ZimaOS: tre adresser att kontrollera

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.

Den fjärde sidan i en lång ZimaOS-supportdiskussion följer en användares återkommande problem med Jellyfin och Nginx Proxy Manager efter den första lyckade konfigurationen för fjärråtkomst. Den användbara lärdomen är inte en enda magisk port: ett 502-fel kan återkomma när reverse proxy-målet, Jellyfins portmappning, Docker-nätverket eller applikationens tillstånd ändras.

Den här sidan fokuserar enbart på inlägg 61–80. Den upprepar inte den tidigare konfigurationen av DuckDNS och certifikatet som behandlas på annat håll i samma tråd.

Separera NPM API-meddelandet från Jellyfins 502-fel

Användaren såg först ”Kommunikationen med API:et misslyckades, körs NPM korrekt?”. Genomgången av communityloggarna visade att Nginx Proxy Manager kördes och att förnyelsen av Let's Encrypt hade lyckats. Det tillfälliga API-meddelandet kunde därför bero på en inaktuell webbläsarsession eller ett kortvarigt avbrott i kommunikationen mellan gränssnittet och backend, medan det offentliga 502-felet förblev ett separat problem mellan proxyn och Jellyfin.

Telefonbild som visar Nginx Proxy Managers status under felsökning av Jellyfin 502
Skärmbilderna användes för att skilja ett NPM-gränssnittsmeddelande från det fortsatta routningsfelet i backend.

Håll isär tre adresstyper

Adresstyp Exempel på roll Ska NPM vidarebefordra till den?
Offentlig WAN-adress ISP-vänd adress som uppdateras av DuckDNS Nej
ZimaOS LAN-adress Stabil adress i hemnätverket, till exempel 192.168.1.50 Ja, när Jellyfin publicerar en värdport
Docker-containeradress eller -namn Intern slutpunkt, till exempel jellyfin:8096 Ja, endast när NPM kan nå samma Docker-nätverk

Tråden växlade upprepade gånger mellan ett containernamn, en värd-LAN-adress och en intern Docker-adress. Dessa är inte utbytbara. Välj en stödd väg och testa den från NPM-containern innan du ändrar TLS eller DNS.

Läs portmappningen i rätt riktning

Jellyfin-inställningarna visade värdport 8097 mappad till containerport 8096. När NPM ansluter via ZimaOS LAN-adress måste den använda den publicerade värdporten. När NPM ansluter direkt via containernamn i ett gemensamt Docker-nätverk använder den normalt Jellyfins interna port.

Jellyfin-containerinställningar fotograferade vid jämförelse av värdport 8097 och containerport 8096
Skärmbilden hjälpte till att förklara varför rätt port beror på om NPM når värden eller containernätverket direkt.

En anslutningsåterställning från insidan av NPM visade att den valda routningen fortfarande inte gav ett giltigt Jellyfin-svar. Det är mer användbar information än att bara starta om båda containrarna.

Använd en skiktad diagnostikordning

  1. Öppna Jellyfin lokalt och bekräfta uppspelningen innan du rör proxyn.
  2. Bekräfta att Jellyfin-containern körs och läs dess sparade mappning mellan värdport och containerport.
  3. Välj antingen den stabila ZimaOS LAN-adressen tillsammans med den publicerade värdporten, eller ett containernamn tillsammans med en intern port i ett delat nätverk.
  4. Testa den exakta slutpunkten från NPM-miljön.
  5. Först när HTTP-routningen fungerar ska du återaktivera TLS och testa den offentliga domänen.
  6. Efter varje appändring eller omstart ska du upprepa de lokala testerna och proxytesterna innan du ändrar DNS.

En ändring av mediesökvägen kan utlösa ett annat fel

Senare kunde fjärranvändare bläddra i Jellyfin men inte spela upp medier. Ägaren ändrade Jellyfins containerinställningar, och den offentliga webbplatsen slutade svara. En granskning av communityns loggar visade sedan att Jellyfin kördes och skannade /Media/Movies, vilket flyttade fokus tillbaka till proxymålet. Detta visar varför varje ändring bör dokumenteras och testas separat.

Linux-sökvägar är skiftlägeskänsliga vid säkerhetskopiering

En konfigurationssäkerhetskopia misslyckades eftersom kommandot hänvisade till /DATA/AppData/duckdns, medan den riktiga katalogen var /DATA/AppData/DuckDNS. Linux behandlar dessa som olika sökvägar. Källtråden föreslog ett arkiveringskommando skapat av communityn, men det tillhandahölls inte av IceWhale och återges därför inte här som en officiell säkerhetskopieringsmetod.

Terminalskärmbild som visar en sökväg för säkerhetskopiering av ZimaOS AppData som inte överensstämde med skiftläget i DuckDNS-mappen
Säkerhetskopieringsfelet berodde på en skillnad i skiftläge i AppData-katalognamnet, inte på ett trasigt arkiveringsverktyg.

Innan du arkiverar AppData ska du lista de exakta katalognamnen, stoppa program när deras databaser kräver en konsekvent ögonblicksbild och verifiera arkivet genom att återställa en kopia till en tillfällig plats.

Aktuellt stöd för fjärråtkomst

För administration och filåtkomst beskriver aktuella ZimaOS-dokument krypterad peer-to-peer-åtkomst via fjärråtkomst med ZimaClient. En offentlig omvänd proxy för Jellyfin är fortfarande ett avancerat arbetsflöde från tredje part och bör endast exponera medietjänsten, inte ZimaOS-instrumentpanelen.

Jellyfin 502 – vanliga frågor

Bevisar ”NPM API failed” att NPM är stoppat?

Nej. I tråden var NPM-loggarna och certifikatförnyelsen felfria medan webbläsaren visade det meddelandet.

Ska NPM använda port 8096 eller 8097?

Använd den interna porten med direkt containernätverk, eller den publicerade värdporten när du vidarebefordrar till ZimaOS LAN-adress.

Varför angav säkerhetskopian att DuckDNS inte fanns?

Den riktiga AppData-mappen använde ett stort D, och DNS; Linux-sökvägar är skiftlägeskänsliga.