Este extenso hilo de soporte abarca muchos temas para principiantes, pero su resultado más útil para búsquedas aparece en la página 3: un servidor Jellyfin funcionaba localmente, DuckDNS resolvía y existía un certificado SSL, pero el dominio público devolvía 502 Bad Gateway. La comunidad terminó separando el problema en tres capas: la conexión de Nginx Proxy Manager con Jellyfin, la configuración de TLS y la gestión del puerto 443 por parte del router.
El avance decisivo se produjo cuando el usuario deshabilitó el servicio NAS propio del router en el puerto 443. Después de eso, tanto HTTP como HTTPS llegaban a Jellyfin.
Un error 502 significaba que el proxy no podía llegar a Jellyfin
La resolución de problemas de la comunidad se centró primero en el destino ascendente de Nginx Proxy Manager. El servicio HTTP normal de Jellyfin estaba en el puerto 8096; el proxy debía reenviar las solicitudes al contenedor de Jellyfin mediante HTTP, en lugar de tratar el puerto HTTPS opcional de Jellyfin como destino ascendente.
Las instrucciones actuales de Jellyfin siguen el mismo modelo: sus ejemplos de proxy inverso Nginx reenvían el tráfico normal y WebSockets a Jellyfin en el puerto 8096.
El proxy y Jellyfin necesitan una ruta Docker accesible
En un momento dado, usar el nombre del contenedor no funcionó, así que el asistente de la comunidad cambió el proxy a la dirección Docker interna de Jellyfin. Eso hizo que la ruta HTTP comenzara a funcionar.
Usar la IP interna cambiante de un contenedor es menos robusto que colocar ambos servicios en una red Docker compartida y controlada, con una resolución estable mediante nombres de servicio. El hilo original documenta lo que funcionó en esa instalación, no un diseño Compose ideal para todos los servidores.
Corrige el enrutamiento HTTP antes de añadir SSL
Una fuente importante de confusión fue cambiar las opciones de TLS mientras el proxy todavía no podía llegar a Jellyfin. La secuencia de la comunidad eliminó temporalmente el SSL del host proxy, verificó primero el enrutamiento HTTP sin cifrar y solo después restauró el certificado y forzó HTTPS.
Este orden de resolución es más valioso que copiar una IP concreta: primero demuestra el enrutamiento ascendente y después diagnostica TLS.
El router estaba ocupando el puerto 443
Después de que HTTP finalmente abriera Jellyfin, al volver a activar HTTPS el usuario era dirigido a la página de inicio de sesión del router. Esa fue la pista más clara del hilo: el puerto 443 entrante estaba siendo gestionado por la función NAS/administración del propio router, en lugar de reenviarse a Nginx Proxy Manager.
El usuario deshabilitó el servicio NAS interno del router en el puerto 443 y confirmó entonces que HTTPS funcionaba.
Que HTTPS remoto funcionara no garantizaba el descubrimiento local de aplicaciones
Más adelante, el hilo exploró los clientes de Roku y de teléfono. El acceso mediante navegador a través del dominio público funcionaba, pero el descubrimiento automático local y el comportamiento de hairpin/NAT loopback seguían siendo inconsistentes. Finalmente, la comunidad utilizó DLNA como solución práctica para Roku.
Este seguimiento no debe mezclarse con la ruta 502/HTTPS ya resuelta. El enrutamiento remoto mediante proxy inverso y el descubrimiento de dispositivos locales son comportamientos de red independientes.
Esta fue ayuda de red de la comunidad, no una receta de seguridad de IceWhale
Los pasos detallados del proxy inverso procedían de participantes de la comunidad. Exponer Jellyfin mediante un dominio requiere prestar atención a la configuración del router, TLS, la autenticación y las prácticas de actualización. No publiques servicios administrativos no relacionados de ZimaOS solo porque el puerto 443 esté reenviado a un proxy inverso.
Preguntas frecuentes sobre Jellyfin y NPM
¿Qué causó el error 502 Bad Gateway?
Al principio, Nginx Proxy Manager no podía llegar correctamente al servicio ascendente de Jellyfin. Una vez corregido el enrutamiento, Jellyfin se cargó mediante HTTP.
¿Por qué HTTPS abría la página de inicio de sesión del router?
El propio router estaba utilizando el puerto 443. Deshabilitar o cambiar de puerto ese servicio del router permitió que el puerto 443 llegara a Nginx Proxy Manager.
¿NPM debe usar HTTP o HTTPS internamente para el proxy de Jellyfin?
La configuración exitosa del hilo y los ejemplos actuales de Nginx de Jellyfin utilizan HTTP hacia el servicio de Jellyfin en el puerto 8096, terminando TLS en el proxy inverso.
¿El HTTPS remoto hace que Jellyfin se descubra automáticamente en Roku?
No. El descubrimiento del cliente, el aislamiento de la red Wi-Fi, la red Docker y el NAT loopback son problemas independientes.
