Jellyfin funciona con Wi-Fi, pero falla con Ethernet o VPN

Si Jellyfin funciona mediante Wi‑Fi, pero falla por Ethernet o a través de una VPN, normalmente el servidor está bien; lo que ha cambiado es la ruta hasta él. Las causas más comunes son una IP o subred diferente, una respuesta DNS distinta, una ruta que prioriza la interfaz equivocada, reglas del firewall o de la red local que clasifican la conexión de forma diferente, o una ruta VPN que se solapa con la LAN.

Usa una URL de Jellyfin conocida y funcional, y prueba desde el cliente afectado por etapas. Primero confirma la IP de destino y el puerto, después compara las rutas, luego comprueba el firewall y las redes locales de Jellyfin y, solo después, revisa el comportamiento específico de la subred o del nodo de salida de la VPN. No reinstales Jellyfin mientras se pueda acceder al mismo servidor mediante otra interfaz, porque esa evidencia ya apunta a un problema de red y no al estado de la aplicación.

Compara la dirección de destino mediante Wi‑Fi y Ethernet

Con la conexión Wi‑Fi funcional, registra el nombre de host de Jellyfin, la dirección IP resuelta, la subred del cliente y el puerto. Cambia a Ethernet y repite las mismas comprobaciones. Si el nombre de host se resuelve en una dirección diferente o inaccesible, corrige el DNS o la ruta del cliente antes de modificar la configuración de Jellyfin.

La documentación de red de Jellyfin explica que el acceso normal utiliza la IP del host y el puerto HTTP(S) configurado, mientras que la detección local está limitada a la subred local. Consulta el comportamiento de la red local cuando un cliente conectado por cable se encuentre en una VLAN o subred diferente de la red Wi‑Fi.

Prueba directamente la IP del servidor desde Ethernet. Si la IP funciona, pero el nombre de host falla, el problema está en el DNS. Si no funciona ninguno de los dos, continúa con las comprobaciones de rutas y firewall; si el puerto TCP acepta la conexión, pero la aplicación se comporta de forma diferente, revisa la clasificación local/remota de Jellyfin.

Comprueba qué interfaz y ruta utiliza realmente el cliente

Un equipo con adaptadores de Wi‑Fi, Ethernet y VPN puede mantener varias rutas a la vez. Cuando se conecta Ethernet, el sistema operativo puede priorizar una nueva ruta predeterminada o una ruta de subred más específica que envíe el tráfico de Jellyfin a un destino diferente del de la ruta Wi‑Fi funcional.

Inspecciona la ruta hacia la IP del servidor Jellyfin mediante las herramientas de enrutamiento de tu sistema operativo y compárala con el estado funcional. Desactiva temporalmente una sola interfaz para confirmar la causa y vuelve a activarla; no elimines rutas de forma permanente hasta saber qué regla es incorrecta.

Si la ruta apunta a la puerta de enlace Ethernet correcta y el servidor responde al ping, pero el puerto de Jellyfin falla, la siguiente prueba debe centrarse en el firewall o en la vinculación del servicio, no en el DNS.

Verifica las reglas del firewall y las redes locales de Jellyfin

Compara la política del firewall para las subredes Ethernet, VPN y Wi‑Fi. Los routers domésticos y los switches administrados suelen aplicar reglas VLAN o de red de invitados diferentes, aunque las tres conexiones se encuentren físicamente dentro del mismo hogar.

En Jellyfin, revisa los valores CIDR de Redes locales y la política de acceso remoto. Un cliente que llegue desde una subred no incluida puede tratarse como remoto, lo que podría cambiar si se permite el acceso a ese usuario, aunque el servidor esté escuchando con normalidad.

Para ver un ejemplo más amplio de cómo separar el éxito local de un fallo en la ruta remota, consulta las rutas de acceso local y remoto. La misma disciplina se aplica aquí: confirma cada salto de red antes de cambiar la aplicación.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Busca una superposición de subredes de la VPN o un comportamiento del nodo de salida

Cuando el fallo aparece únicamente con la VPN activada, compara las rutas de la VPN con la LAN física. Dos redes que utilizan la misma subred privada pueden hacer que el cliente envíe el tráfico de Jellyfin por el túnel, aunque el servidor esté físicamente cerca.

Tailscale documenta casos en los que las rutas de subred, los nodos de salida o la configuración de acceso a la LAN pueden impedir que un cliente llegue a un dispositivo local. Usa su guía de solución de problemas de conectividad LAN como ejemplo de cómo el enrutamiento de la VPN puede anular la ruta que funcionaba antes de activar el túnel.

Desactiva temporalmente la aceptación de rutas VPN o el nodo de salida y vuelve a probar la misma IP de Jellyfin. Si el acceso se recupera de inmediato, no modifiques el servidor Jellyfin y corrige en su lugar el enrutamiento de la VPN o la política de acceso a la LAN.

Vuelve a probar la ruta original del cliente después de cada corrección de red

Una vez identificada la causa, aplica únicamente el cambio correspondiente: corrige el DNS, ajusta las métricas o los prefijos de las rutas, permite la subred Ethernet/VPN en el firewall o corrige la entrada de Redes locales de Jellyfin. Después, restaura todas las interfaces normales y repite el método de conexión original.

Verifica tanto el cliente web de Jellyfin como un cliente nativo si en tu hogar se utilizan ambos, porque la detección, las URL de servidor guardadas y el acceso HTTP directo pueden seguir rutas diferentes. También realiza la prueba después de reiniciar o volver a conectar el cliente para que las rutas almacenadas en caché no hagan que un éxito temporal parezca permanente.

Solicita asistencia adicional solo si la IP de destino, la ruta, el firewall y la clasificación de Redes locales son correctos, pero la misma interfaz sigue fallando. Captura las tablas de rutas funcional y fallida, las IP de los clientes y los registros del servidor durante un intento; esa información es mucho más útil que reinstalar Jellyfin o restablecer todos los ajustes de red a la vez.