Jellyfin funziona tramite Wi-Fi, ma non tramite Ethernet o VPN

Se Jellyfin funziona tramite Wi-Fi ma non tramite Ethernet o VPN, il server è solitamente in buona salute: è cambiato il percorso per raggiungerlo. Le cause più comuni sono un IP/subnet o una risposta DNS diversi, una route che preferisce l'interfaccia sbagliata, regole firewall/rete locale che classificano la connessione in modo diverso oppure una route VPN che si sovrappone alla LAN.

Usa un unico URL Jellyfin sicuramente funzionante ed esegui i test dal client interessato, procedendo per livelli. Prima verifica l'IP di destinazione e la porta, poi confronta le route, quindi controlla il firewall e le Reti locali di Jellyfin e solo dopo analizza il comportamento specifico della VPN relativo alla subnet o al nodo di uscita. Non reinstallare Jellyfin finché lo stesso server è raggiungibile tramite un'altra interfaccia, perché questa evidenza indica già un problema di rete e non dello stato dell'applicazione.

Confronta l'indirizzo di destinazione su Wi-Fi ed Ethernet

Sulla connessione Wi-Fi funzionante, annota l'hostname Jellyfin, l'indirizzo IP risolto, la subnet del client e la porta. Passa a Ethernet e ripeti gli stessi controlli. Se l'hostname viene risolto in un indirizzo diverso o irraggiungibile, correggi il DNS o la route del client prima di modificare le impostazioni di Jellyfin.

La documentazione di rete di Jellyfin spiega che l'accesso normale utilizza l'IP dell'host e la porta HTTP(S) configurata, mentre il rilevamento locale è limitato alla subnet locale. Consulta il comportamento della rete locale quando un client cablato si trova su una VLAN o subnet diversa da quella Wi-Fi.

Testa direttamente l'IP del server da Ethernet. Se l'IP funziona ma l'hostname non funziona, il problema riguarda il DNS. Se non funziona nessuno dei due, continua con i controlli di routing e firewall; se la porta TCP si connette ma l'app si comporta diversamente, esamina la classificazione locale/remota di Jellyfin.

Controlla quale interfaccia e quale route sta effettivamente utilizzando il client

Un dispositivo con adattatori Wi-Fi, Ethernet e VPN può mantenere diverse route contemporaneamente. Quando Ethernet è connessa, il sistema operativo potrebbe preferire una nuova route predefinita o una route più specifica per la subnet, inviando il traffico Jellyfin verso una destinazione diversa rispetto al percorso Wi-Fi funzionante.

Esamina la route verso l'IP del server Jellyfin usando gli strumenti di routing del sistema operativo e confrontala con lo stato funzionante. Disattiva temporaneamente una sola interfaccia per verificare l'ipotesi, quindi riattivala; non eliminare definitivamente le route finché non sai quale regola è errata.

Se la route punta al gateway Ethernet corretto e il server è raggiungibile tramite ping ma la porta Jellyfin non funziona, il test successivo riguarda il firewall o il binding del servizio, non il DNS.

Verifica le regole del firewall e le Reti locali di Jellyfin

Confronta i criteri del firewall per la subnet Ethernet, la subnet VPN e la subnet Wi-Fi. Router domestici e switch gestiti applicano spesso regole VLAN o di rete guest diverse, anche quando tutte e tre le connessioni si trovano fisicamente nella stessa abitazione.

In Jellyfin, controlla i valori CIDR di Reti locali e i criteri di accesso remoto. Un client proveniente da una subnet non elencata può essere trattato come remoto, modificando eventualmente la possibilità di accesso per quell'utente anche se il server è normalmente in ascolto.

Per un esempio più ampio di distinzione tra successo locale e problema del percorso remoto, consulta i percorsi di accesso locale e remoto. La stessa metodologia si applica qui: verifica ogni passaggio di rete prima di modificare l'applicazione.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifica la sovrapposizione delle subnet VPN o il comportamento del nodo di uscita

Quando il problema si presenta solo con una VPN attiva, confronta le route VPN con la LAN fisica. Due reti che utilizzano la stessa subnet privata possono indurre il client a inviare il traffico Jellyfin nel tunnel, anche se il server si trova fisicamente nelle vicinanze.

Tailscale documenta casi in cui le route delle subnet, i nodi di uscita o le impostazioni di accesso alla LAN possono impedire a un client di raggiungere un dispositivo locale. Usa la relativa guida alla risoluzione dei problemi di connettività LAN come esempio di come il routing VPN possa sovrascrivere il percorso funzionante prima dell'attivazione del tunnel.

Disattiva temporaneamente l'accettazione delle route VPN o il nodo di uscita e riprova utilizzando lo stesso IP Jellyfin. Se l'accesso torna immediatamente, lascia invariato il server Jellyfin e correggi invece il routing VPN o i criteri di accesso alla LAN.

Ripeti il test del percorso client originale dopo ogni correzione di rete

Una volta individuata la causa, applica solo la modifica corrispondente: correggi il DNS, regola le metriche o i prefissi delle route, autorizza la subnet Ethernet/VPN nel firewall oppure correggi la voce Reti locali di Jellyfin. Quindi ripristina tutte le interfacce normali e ripeti la connessione con il metodo originale.

Verifica sia il client web Jellyfin sia un client nativo, se nella tua abitazione utilizzi entrambi, perché il rilevamento, gli URL dei server salvati e l'accesso HTTP diretto possono seguire percorsi diversi. Esegui inoltre il test dopo il riavvio o la riconnessione del client, così le route memorizzate nella cache non faranno sembrare permanente un successo temporaneo.

Procedi con un'escalation solo se l'IP di destinazione, la route, il firewall e la classificazione in Reti locali sono tutti corretti, ma la stessa interfaccia continua a non funzionare. Raccogli le tabelle di routing funzionanti e non funzionanti, gli IP dei client e i log del server relativi a un tentativo; queste informazioni sono molto più utili che reinstallare Jellyfin o ripristinare tutte le impostazioni di rete contemporaneamente.