Om Plex fungerar via en nätverkssökväg men misslyckas via en annan, låt serverkonfigurationen vara oförändrad och testa den sökväg som ändras.
Wi-Fi-, Ethernet- och VPN-gränssnitt kan använda olika IP-adresser, DNS-servrar, rutter, MTU-värden, VLAN och brandväggspolicyer även på samma klient. En serveromfattande ändring är fel första åtgärd när samma media och konto fungerar via en sökväg. Jämför direkt åtkomst till servern, DNS-upplösning, ruttval och uppspelningsläge på varje gränssnitt.
Jämför adress och rutt innan du ändrar Plex-inställningar
Det felande gränssnittet kan nå ett annat subnät eller välja en annan standardrutt. Verifiera serverns IP-adress och rutten från klienten i stället för att lita på nätverkets etikett.
När både Ethernet och Wi-Fi är aktiva kan ruttmätvärden göra att gränssnitten väljer olika vägar till samma destination. Fokusera därför den första felsökningen på routing och gränssnittspolicy i stället för Plex-inställningar.
Pinga eller anslut till serveradressen via båda sökvägarna, jämför klientens IP-adress och subnät och kontrollera vilken rutt som används för port 32400. Om Ethernet inte kan nå servern direkt ska åtgärden ligga på nätverkslagret.
Kontrollera DNS och VPN-routing separat
Ett VPN kan ändra både ruttprioritet och DNS utan att Plex-programmet ändras. Split tunneling kan också skicka svar via ett annat gränssnitt än det som tog emot begäran.
Split tunneling kan misslyckas när svarstrafiken lämnar via VPN-rutten i stället för via gränssnittet som tog emot begäran, vilket bryter en annars fungerande Plex-sökväg.
Inaktivera VPN-anslutningen endast så länge att du kan fastställa ett kontrollresultat. Aktivera den sedan igen och jämför routningstabellerna. Åtgärda asymmetrisk routing eller split-tunnel-policyn innan du ändrar medie- eller databasinställningar.
Testa MTU när små begäranden fungerar men strömmar stannar
En sökväg kan släppa igenom små kontrollpaket medan större paket fragmenteras eller når tidsgränsen. Detta mönster är särskilt relevant i VPN-tunnlar och på vissa mobil- eller internetleverantörslänkar.
Begränsad anslutning kan bero på MTU-känsliga Plex-fel via en transport medan en annan sökväg fungerar. Därför är paketstorleken ett avgränsat test för VPN- eller internetleverantörsspecifika avbrott.
Använd ett test av sökvägens MTU eller sänk tillfälligt tunnelns MTU på ett kontrollerat sätt. Om uppspelningen blir stabil utan någon ändring i Plex ska felsökningen ligga på transportlagret.
Testa Plex igen först när den grundläggande anslutningen är stabil
När direkt åtkomst, routing, DNS och MTU är konsekventa testar du samma Plex-objekt och kvalitet via varje sökväg. Då undviker du att en nätverksåtgärd förväxlas med en ändring av klientens transkodning.
Innan du återgår till Plex-inställningarna ska du bekräfta att nätverksfel och överbelastning saknas på den åtgärdade sökvägen. Återskapa sedan samma objekt och kvalitet medan nätverksvariabeln hålls stabil.
Om nätverkssökvägen är stabil men en klient fortfarande misslyckas fortsätter du med klientkompatibilitet eller cachelagrat tillstånd. Behåll en känd sökväg för fjärrströmning med Plex som kontroll i stället för att åter öppna serveromfattande nätverksinställningar.
Support och tips
Mer att läsa

Bör du säkerhetskopiera Jellyfin medan tjänsten körs eller stoppa tjänsten först?
Föredra säkerhetskopior av stoppade tjänster för enkelhetens skull; använd live-ögonblicksbilder endast när applikationstillståndet fångas konsekvent och återställningar har testats.

Varför blir Jellyfin varmt eller högljutt när ingen streamar?
Värme vid inaktivitet beror vanligtvis på bakgrundsarbete eller en belastning från en delad värd, så identifiera den aktiva processen och den schemalagda uppgiften innan...

När bör du bygga om i stället för att reparera Jellyfin?
Välj ominstallation framför reparation när problemet är avvikelser i körmiljön och beständiga data är säkerhetskopierade; ”ominstallera” inte genom att radera den enda fungerande databasen.

