Jellyfin no entra desde fuera de casa: 9 causas y su prueba

Si en casa entras y desde fuera no, hay nueve causas que explican casi todos los casos, y conviene descartarlas de la más barata a la más cara. Las dos primeras se comprueban en un minuto: desde qué red estás probando, y si tu operador te tiene detrás de CGNAT. Si alguna sale positiva, el resto de la lista da igual.

Está escrito contra Jellyfin 10.11.11, la versión estable según el registro de publicaciones del proyecto (la 12.0 aún va por candidatas). Si todavía no has montado el acceso remoto, empieza por la guía para acceder a Jellyfin desde fuera de casa y vuelve aquí si se te atasca.

Busca tu síntoma en esta tabla

Localiza la frase que más se parezca a lo tuyo. Si encajas en dos, empieza por la de arriba: el orden es por lo rápido que se descarta cada cosa.

Antes de tocar el router: las tres direcciones de Jellyfin

Jellyfin no tiene una dirección propia: la dirección es la de tu servidor, y no es la misma según desde dónde entres.

• La local: algo como 192.168.1.40:8096. Vale solo dentro de casa. Si empieza por 192.168., 10. o 172.16. a 172.31., es local.
• La pública: la de tu router, la misma para todo lo que hay conectado en casa. Es la que se usa desde fuera, seguida del puerto.
• El dominio: un nombre que apunta a la pública y la sigue aunque cambie. Es lo que resuelve la causa 5.

Los puertos, según la documentación de red del proyecto: 8096/TCP para HTTP y 8920/TCP para HTTPS, los dos configurables, más el 7359/UDP con el que los clientes localizan el servidor dentro de la red local. El 8920 no se usa salvo que actives HTTPS.

Y esa misma página explica el botón de «buscar servidores»: «Automatic discovery only works locally and should not be exposed externally.» Desde la calle ese botón no encontrará tu servidor nunca: fuera de casa la dirección se escribe a mano.

Pedro contó en los comentarios de esta web, en junio de 2023, que había abierto el puerto 8096 y que aun así desde fuera no entraba. Al día siguiente volvió con el mejor resumen del lío:

«Me parece que me estoy haciendo un lio, donde digo ip pública es ip privada dinámica o estática que me vale para conectarme en casa, y lo que tendría que poner sería la ip pública seguida del puerto para hacerlo desde fuera. Estoy en lo cierto?»

Pedro, 27 de junio de 2023.

Estaba en lo cierto. Y cuando alguien pregunta «hola buenas no puedo entrar en la aplicación me podrías decir la dirección ip», como Alvaro en octubre de 2025, nadie de fuera puede dársela: esa dirección es la de su propio equipo. Si aún no tienes servidor, empieza por la guía de instalación en PC o Mac.

Causa 1 · Estás probando desde la red equivocada

Va primero porque es la más barata de descartar. Tiene dos caras del mismo error: probar la dirección pública sin haber salido de casa, o probar desde fuera con la dirección local guardada.

Prueba de un minuto: desde cualquier equipo de casa abre cuál es mi IP y apunta el número, que es tu dirección pública. Luego coge el móvil, apaga el wifi, déjalo solo con datos y entra en http://ESE-NUMERO:8096. Es la única prueba que cuenta: lo que quieres reproducir es estar fuera, y desde el wifi de casa no lo estás.

Sirve para diagnosticar, pero no para el día a día: por el 8096 la contraseña viaja sin cifrar. La documentación de red pide «Using https to access the Server is recommended» y recomienda terminar el HTTPS en un proxy inverso antes que en el propio servidor. Tus opciones, al final de esta página.

Y la prueba invertida. Enrique escribió en diciembre de 2025 que entraba desde su móvil con la IP pública, pero que «con otros moviles u otros dispositivos en otras casas» no había manera. Si a ti te funciona y a otra persona no, el fallo está en el otro extremo, no en tu router.

Pídele que lo pruebe con datos móviles en vez de con su wifi: si así entra, el bloqueo es de la red de esa persona. Si no entra de ninguna forma, mírale el usuario y el permiso: dar acceso a otra persona y causa 9.

Causa 2 · Tu operador te tiene detrás de CGNAT

Si esta sale positiva, invalida todo lo demás: no tienes dirección pública propia, la compartes con otros clientes del operador, y abrir el puerto del router no sirve porque las peticiones de fuera no llegan a tu línea.

Prueba de un minuto: entra en el router y busca la IP WAN (a veces aparece como «IP de internet», en la pantalla de estado). Compárala con la que te dio cuál es mi IP en la causa 1. Si las dos no coinciden, hay algo entre tu router e internet.

Si además la IP WAN cae entre 100.64.0.0 y 100.127.255.255, el diagnóstico está cerrado: la IETF reservó ese rango para esto. El RFC 6598 (abril de 2012) lo delimita, «The Shared Address Space address range is 100.64.0.0/10», y dice que sirve «to number the interfaces that connect CGN devices to Customer Premises Equipment»: los equipos de CGNAT del operador contra el router del cliente.

Cuidado con una trampa: si tienes Tailscale instalado verás direcciones que también empiezan por 100. en tus equipos. No es lo mismo. Aquí se mira la IP WAN del router, no la del ordenador.

Salidas hay dos. Preguntar a tu operador si te da dirección pública, que algunos ofrecen a petición y a veces con coste. O saltarse el router entero: el proyecto documenta Tailscale para este caso exacto, «an effective alternative in situations where opening ports is undesirable or not feasible, such as when the network is behind a carrier-grade NAT (CGNAT), or if your ISP blocks incoming traffic on certain ports».

Un lector lo resolvió de forma más laboriosa, con un VPS, una VPN y Nginx Proxy Manager (Oscar, 22 de junio de 2024); hoy hay caminos más cortos, al final. Qué es el CGNAT, en las preguntas frecuentes.

Causa 3 · La regla de puertos del router se perdió (o nunca se guardó)

Prueba de un minuto: la de la causa 1. Si en local entras, desde datos móviles no, y el CGNAT está descartado, el corte está en el camino: la regla del router o el cortafuegos del servidor.

Arreglo: vuelve a crear la regla de reenvío. Protocolo TCP, puerto 8096, apuntando a la dirección local que tiene hoy el equipo servidor (eso es la causa 4). Si acabas de crearla y no va, reinicia el router antes de seguir bajando por la lista.

Queda un caso que da este mismo síntoma con el CGNAT descartado: que tu operador filtre el tráfico entrante en ciertos puertos, algo que la documentación de Tailscale del proyecto nombra junto al CGNAT. Como muchos routers dejan mapear un puerto externo distinto del interno, se descarta en una prueba: crea una regla del 18096 externo al 8096 interno y entra desde datos con :18096. Si por ahí entras, el 8096 lo filtraba alguien por el camino.

Un aviso del propio proyecto antes de decidir: «Opening a port directly to the Internet is therefore insecure and not recommended.» Abrir un puerto directamente a internet es inseguro y no está recomendado. No es una prohibición; si prefieres no dejar nada abierto, las alternativas están en la última sección.

Causa 4 · La IP local del servidor cambió y el router reenvía a ninguna parte

El router reparte direcciones locales y las renueva. Si tu servidor era el 192.168.1.40 y tras un apagón pasó al .45, la regla sigue mandando el tráfico al .40, donde ya no escucha nadie. Desde fuera el síntoma es idéntico a no tener regla.

Prueba de un minuto: mira qué dirección local tiene el servidor ahora mismo y compárala con la que pusiste en la regla. En Windows, abre el Símbolo del sistema y escribe ipconfig: según Microsoft, sin parámetros muestra la dirección IPv4, la máscara de subred y la puerta de enlace de cada adaptador. En macOS y en Linux está en los ajustes de red de la conexión que uses.

Arreglo: corrige la regla y fija esa dirección. Según el fabricante se llama reserva DHCP, IP fija o asignación estática. Importa dónde se hace: en el router, que es el que reparte las direcciones, normalmente en el mismo menú donde ves la lista de equipos conectados, y no en el ordenador. Sin eso volverás aquí dentro de unos meses.

Causa 5 · Tu IP pública ha cambiado

Salvo que tengas contratada una dirección fija, la pública puede cambiar cuando el operador quiera. Desde ese momento la que tenías apuntada deja de llevar a tu casa.

Prueba de un minuto: mira tu dirección pública de hoy y compárala con la que estabas usando.

Arreglo: un nombre de dominio dinámico. En vez de memorizar números usas un nombre que se actualiza solo cuando la dirección cambia. DuckDNS se presenta como «free dynamic DNS hosted on AWS» y no pide tarjeta. No-IP mantiene plan gratuito con «1 Hostname» y «Dynamic DNS Updates», y lo describe como «no credit card required, ever». Mira las condiciones de renovación del que elijas antes de confiarle el acceso.

Aquí toca una corrección de la casa. Nuestro artículo sobre DynDNS te mandaba abrir una cuenta allí; ese consejo se escribió cuando DynDNS tenía nivel gratuito y hoy no lo tiene, así que seguirlo llevaba a un muro de pago. Lo corregimos el 13 de agosto de 2026 y ahora explica por qué no vale y qué poner en su lugar. Usa DuckDNS o No-IP.

Causa 6 · El cortafuegos de Windows tiene tu red marcada como «pública»

Windows aplica reglas distintas según considere «pública» o «privada» la red conectada. En perfil público bloquea tráfico entrante que en privado dejaría pasar, y tu servidor deja de responder desde fuera aunque el router esté perfecto.

Prueba de un minuto, sin bajar la guardia: en vez de apagar nada, crea la regla que falta. Pulsa Inicio, escribe wf.msc y pulsa Intro: se abre la consola del firewall con seguridad avanzada. A la izquierda, Reglas de entrada → Acción → Nueva regla → tipo Puerto → TCP con el puerto local 8096 → Permitir la conexión → en la página Perfil marca Privado → ponle nombre. El atajo y los pasos son los que documenta Microsoft.

Y el perfil de la red: Configuración → Red e Internet → Wi-Fi (o Ethernet) → la red a la que está conectado el servidor → Tipo de perfil de red → Red privada. Con la regla puesta y el perfil corregido, repite la prueba desde datos móviles.

Solo si aun así no entra, desactiva el cortafuegos del perfil de red que estés usando, prueba y vuelve a encenderlo en el mismo minuto, salga como salga: apagarlo deja sin filtro el equipo entero, no solo el 8096, y el arreglo nunca es dejarlo apagado. Mira también si tienes un antivirus con cortafuegos propio, tipo Avast, ESET o Norton: filtran por su cuenta y no salen en esa consola.

Si tu servidor no es Windows, el sitio es otro: la misma página de red del proyecto enlaza cómo abrir puertos en ufw, firewalld y nftables, los cortafuegos habituales en Linux y en muchos NAS.

Causa 7 · Ves Jellyfin pero no conecta al servidor: «Seleccionar servidor» o «Conexión fallida»

Esta es distinta a las anteriores y separarla ahorra días de pelea con el router. La regla: si escribiste la dirección en un navegador y aparece la interfaz de Jellyfin, el servidor ha respondido. El puerto está abierto y el CGNAT no es tu problema. Falla lo que viene después.

«despues de haber abierto el puerto puedo conectarme desde fuera, pero me sale una pagina pidiéndome conectar al servidor… y eso no me funciona, falla la conexión pero el servidor esta UP»

Hector, 23 de mayo de 2024.

El matiz que cambia el diagnóstico: eso vale para el navegador. En una app (la de la tele, el móvil, Roku) la pantalla «Seleccionar servidor» viene instalada con la aplicación, así que verla no demuestra que hayas llegado a ningún sitio: solo que la app no ha podido hablar con la dirección que le diste. Eso es la causa 8. Si el aparato que falla es el televisor, el repaso marca por marca está en Jellyfin en Smart TV, cuando la app no conecta.

En el navegador hay tres cosas que revisar, todas en Panel de control → Redes:

• «URI del servidor publicadas», así rotulado en el panel, dentro del bloque «Configuración de cortafuegos y proxy». Le dice a Jellyfin qué dirección entregar a los clientes según por dónde entren. Si no usas proxy inverso ni subruta, se queda vacío: viene vacío de fábrica y no es tu problema. Si sí lo usas, la ayuda del campo da el formato: internal=http://jellyfin.example.com, external=https://jellyfin.example.com, o all= con una sola dirección para los dos casos.
• «Proxies conocidos», si has montado un proxy inverso. La documentación no deja margen: «External access settings through a reverse proxy will only work if known proxies are set up correctly!» Si el proxy llega por Tailscale, ahí va su dirección de Tailscale.
• «URL base», solo si serviste Jellyfin en una subruta tipo /jellyfin: la documentación avisa de que rompe HDHomeRun, el plugin de DLNA, Sonarr, Radarr y MrMC, y de que en Android TV el campo «Host» debe incluirla.

De los mensajes sobre acceso remoto que llevan años acumulándose en los comentarios de esta web, dos describen exactamente esta pantalla. El otro es de julio de 2023: entraba por un túnel de un tercero y de un día para otro se encontró el «Seleccionar servidor». Cada intermediario que metes en medio puede cambiar sin avisarte.

Causa 8 · El cliente tiene guardada la dirección de casa

Las aplicaciones guardan el servidor que añadiste la primera vez. Si lo diste de alta desde el salón, tienen apuntada una dirección local, y fuera de casa esa dirección no lleva a ninguna parte.

Prueba de un minuto: abre el selector de servidor de la app y mira qué dirección tiene guardada. Si empieza por 192.168., localizado.

Arreglo: borra ese servidor guardado y añádelo otra vez con la dirección pública o con tu dominio. En casi todas las apps se hace en esa misma pantalla de «Seleccionar servidor».

Antes de dar por buena esta causa, comprueba algo si el aparato es una tele: cuando el PC y el móvil entran y la tele dice «imposible conectarse al servidor» también estando en casa, no es un fallo de acceso remoto. Es cosa de esa app y se mira por otro lado; el resto de guías, en el índice de ayuda.

Causa 9 · Ese usuario no tiene permiso para conectarse desde fuera

Lo anterior es de red y afecta a todos por igual. Esto es por persona, y explica al que entra desde su móvil mientras su familia se queda fuera.

Prueba de un minuto: entra como administrador, ve a Panel de control → Usuarios, abre ese usuario y mira la casilla «Permitir conexiones remotas a este servidor». Desactivada, esa cuenta solo funciona dentro de casa por muy bien que esté el router.

Aprovecha para dos ajustes hermanos, los dos en Redes. Uno es el interruptor general, «Opciones de Acceso Remoto». El otro es el delicado: «Redes locales», donde le dices a Jellyfin qué considera «casa» y, por tanto, cuándo aplica el permiso de arriba.

Se rellena con una lista separada por comas de direcciones o de rangos, y un rango se escribe con la dirección de la red, una barra y el número de bits fijos: la mayoría de las casas son 192.168.1.0/24 o 192.168.0.0/24.

Si dudas, déjalo en blanco, que no rompe nada: la ayuda del propio campo dice que entonces se consideran locales todas las direcciones privadas de la RFC 1918, que es lo que hay en una casa normal. El riesgo está en escribirlo mal, no en no escribirlo.

En enero de 2024 un lector llamado Jesus escribió en los comentarios de esta web, sin que nadie le contestara, que buscaba «la Entrada de Acceso para los usuarios fuera de casa». Si se refería a un permiso por usuario, es esta casilla. El resto de permisos por persona están en la documentación de gestión de usuarios.

«Usuario o contraseña incorrectos», pero solo en el móvil

Si con ese mismo usuario entras desde casa sin problema y el móvil insiste en que no son correctos, no es la contraseña: o es este permiso, o es la app de ese aparato. Antes de reinstalarla por tercera vez, entra sin escribir nada: pulsa Conexión rápida en la pantalla de acceso del móvil, apunta el código de seis caracteres que aparece y autorízalo desde el equipo que ya tiene sesión, en Ajustes → Conexión rápida. Viene activada de fábrica.

Un aviso para no perder el tiempo: la Conexión rápida ahorra el usuario y la contraseña, no la dirección del servidor; para que salga esa pantalla, la app ya tiene que estar hablando con tu Jellyfin. Y no todos los clientes hacen las dos mitades. La tabla oficial distingue entrar de autorizar:

Si estás intentando dar de alta la tele autorizando desde la propia tele, no lo estás haciendo mal: es que no se puede.

Quiero que entre otra persona: mi hermano, mi pareja

Es de lo más preguntado en los comentarios de esta web, y en cinco años solo lo contestó otro lector. No hay invitados ni enlaces para compartir: cada persona necesita su usuario en tu servidor. Son tres pasos.

1. En Panel de control → Usuarios, créale un usuario con su nombre y su contraseña.
2. Dentro de ese usuario, marca «Permitir conexiones remotas a este servidor». Sin eso solo entrará estando en tu casa.
3. Pásale tres cosas: la dirección pública o tu dominio con el puerto, su usuario y su contraseña. La aplicación no le cuesta nada, porque Jellyfin es software libre con licencia GPL-2.0, y hay cliente para móvil, escritorio y buena parte de las teles.

Que viva en otra ciudad o en otro país no cambia nada: lo que compartes es el acceso a tu servidor, no una cuenta de un servicio. Si a ti te funciona y a ella no, vuelve a la causa 1 y que lo pruebe con datos móviles.

Funcionaba y dejó de funcionar: por dónde empezar

«Me ha estado funcionando el servidor perfectamente durante meses, pero de un día para otro no puedo acceder desde fuera de la red wifi, he estado verificando todo, y todo parece correcto, no sé qué hacer.»

Natalia, 16 de septiembre de 2024.

Cuando algo funcionaba y deja de hacerlo sin que tú toques nada, lo que ha cambiado es una dirección o una regla. En este orden, de menos esfuerzo a más:

1. Tu dirección pública, si el operador te la ha renovado.
2. La dirección local del servidor, si hubo apagón, cambio de router o el equipo estuvo días apagado.
3. La regla de reenvío, que algunos routers pierden al actualizarse o al restaurarse.
4. Cualquier intermediario que estuvieras usando: un túnel, un proxy, un servicio de terceros.

Entro bien pero el vídeo se corta

Esto no es un fallo de acceso sino de ancho de banda, y por eso va aparte. «Me conecto perfectamente a mi red desde internet, pero los vídeos se paran al reproducir», escribió Paco en diciembre de 2024. Si entras, navegas por la biblioteca y ves las carátulas, la parte difícil está resuelta.

Lo que limita ahora es tu velocidad de subida, no la de bajada: el vídeo sale de tu casa. La guía de hardware del proyecto pide para acceso remoto «At least 20 Mbps upload bandwidth» y añade en la nota al pie: «If you have less than 100 Mbps of total upload bandwidth, a bandwidth limit of 70% of your upload speed for Jellyfin is recommended».

Ese tope se pone en Jellyfin. El valor general está en Panel de control → Reproducción y cada usuario puede tener el suyo, que anula al general, en Panel de control → Usuarios: «Límite de la transmisión de tasa de bits por internet (Mbps)».

Ojo a las dos cosas que suelen malinterpretarse, porque la documentación es literal: el tope es por flujo y solo afecta a los dispositivos de fuera de tu red. Con dos reproducciones a la vez, el consumo puede ser el doble del número que pongas.

Y el aviso que va detrás: si el fichero original supera el tope, el servidor transcodifica sobre la marcha y eso lo paga la CPU. Un límite demasiado bajo cambia un problema de red por uno de procesador.

Si nada de esto es tu caso: deja de pelearte con el router

El proyecto documenta cuatro maneras de llegar a tu servidor desde fuera, en este orden: reenviar los puertos directamente a internet (marcado «not recommended»), reenviar a través de un proxy inverso, entrar por VPN, o usar un VPS que haga de proxy inverso hacia tu red. Solo la primera obliga a abrir el router.

Tailscale es la que menos configuración pide. Su plan Personal cuesta 0 $, se anuncia como «Free forever», con «Unlimited user devices» y «Up to 6 users».

Los inconvenientes los reconoce la propia documentación de Jellyfin: hay que instalarlo en cada cliente, aislar unos clientes de otros exige configuración compleja, y dependes de un tercero.

Y el detalle que decide si te sirve para la familia: compartir está en todos los planes, pero el invitado necesita cuenta propia, «A recipient needs to be an Owner, Admin, or IT admin of a tailnet to accept a shared machine invitation». Tu cuñado tendrá que instalárselo y registrarse.

Cloudflare Tunnel tiene letra pequeña. Los términos específicos de servicio de Cloudflare, en su sección de CDN, se reservan el derecho de limitar el servicio a quien lo use para servir vídeo sin contratar los productos de pago pensados para eso. La palabra «Tunnel» no aparece en ese texto: el encaje exacto no está escrito, la restricción sí. Con eso delante, decides tú.

Y una vía cerrada, para que no la intentes: DLNA. «Using DLNA remotely is not possible.» Dejó además de venir de serie desde la 10.9 y hoy es un complemento.

Qué hacer ahora

Si la comprobación del CGNAT salió positiva, deja el router en paz: no hay regla que arregle eso, y tu camino es Tailscale o una VPN. Si salió negativa y en local entras, ve por orden: regla de puertos, dirección local del servidor, dirección pública, cortafuegos. Y en cuanto aparezca la interfaz de Jellyfin en pantalla, vete a la causa 7: desde ahí el router ya no pinta nada.

Si sigues atascado, cuéntalo en los comentarios con estos tres datos: qué ves exactamente (copia el mensaje de error tal cual), si aparece o no el logo de Jellyfin, y si la IP WAN de tu router coincide con la que te dice una web de «cuál es mi IP». Esta guía está escrita sobre lo que otros dejaron ahí, incluido un lector que preguntó lo mismo dos veces, en agosto y en septiembre de 2023, sin que nadie le respondiera. Los demás artículos, en el índice de ayuda.