¿Puede Jellyfin funcionar detrás de un proxy inverso en una subruta?

Sí. Jellyfin puede funcionar detrás de un proxy inverso en una subruta como https://example.com/jellyfin, pero Jellyfin y el proxy deben coincidir en la misma ruta base.

Un fallo de subruta normalmente se manifiesta como un sitio que funciona a medias: la página de inicio de sesión puede cargarse mientras fallan JavaScript, las imágenes, los WebSockets, las redirecciones o los clientes nativos. Prueba la ruta por capas —primero la URL base, después la ruta del proxy y, por último, los encabezados reenviados y la dirección del cliente— para distinguir un desajuste de rutas de un problema de TLS o de identidad del proxy.

Haz coincidir la URL base de Jellyfin con la subruta pública

Configura la URL base de Jellyfin con el prefijo público exacto que pretendes usar, por ejemplo /jellyfin. No añadas otro prefijo interno simplemente porque el proxy utilice un bloque de ubicación con nombre; la ruta visible en el navegador y la URL base de Jellyfin deben describir la misma raíz de la aplicación.

La documentación oficial de Apache para el proxy inverso de Jellyfin proporciona explícitamente un ejemplo de subruta e indica a los administradores que establezcan la URL base en /jellyfin antes de conectar los clientes a esa dirección completa. ejemplo oficial de subruta

Reinicia Jellyfin después de cambiar la URL base y, a continuación, abre la subruta pública en una ventana privada nueva del navegador. Si la redirección inicial elimina inmediatamente /jellyfin o lo duplica, corrige la URL base antes de modificar la configuración de WebSocket o autenticación.

Dirige el mismo prefijo a través del proxy inverso

Configura el proxy inverso para que las solicitudes que comiencen con el prefijo público se reenvíen a Jellyfin sin inventar una transformación de ruta adicional. El diseño más sencillo consiste en un prefijo público, una URL base de Jellyfin coincidente y un servicio ascendente.

La guía de Caddy para Jellyfin muestra el mismo patrón: configura la ruta base de Jellyfin, redirige el prefijo sin barra final a la forma con barra final y envía por proxy las solicitudes que estén bajo ese prefijo al backend de Jellyfin. ruta base y ruta del proxy coincidentes

Si el navegador recibe un error 404 del proxy antes de que Jellyfin registre la solicitud, la ruta es incorrecta en la capa del proxy. Si Jellyfin recibe la solicitud pero genera enlaces sin el prefijo, la URL base es incorrecta en la capa de la aplicación. Mantén separadas estas dos señales de fallo.

Comprueba los recursos estáticos y los WebSockets, no solo la página de inicio de sesión

Una respuesta HTML correcta no basta para considerar saludable la configuración de la subruta. Abre las herramientas de desarrollo o el registro del proxy y verifica que las solicitudes de JavaScript, CSS, imágenes, API y WebSocket permanezcan bajo el mismo prefijo público.

Los ejemplos de proxy inverso de Jellyfin incluyen la gestión de WebSockets porque los clientes interactivos mantienen una conexión de socket además de las solicitudes HTTP normales. Por eso, una regla del proxy que gestione únicamente las solicitudes de páginas puede parecer correcta hasta que fallen el estado de reproducción, las actualizaciones de sesión o el comportamiento dinámico de la interfaz. requisitos del proxy inverso

La condición de éxito es sencilla: no debe haber respuestas 404/502 repetidas para recursos con prefijo, el WebSocket debe actualizarse correctamente y la navegación no debe salir a la raíz del sitio. Si falla solo una clase de solicitudes, corrige esa regla del proxy en lugar de cambiar la biblioteca o la configuración de autenticación de Jellyfin.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Conserva la identidad del cliente a través del proxy

Cuando la ruta funcione, verifica la información reenviada del cliente. Jellyfin utiliza la configuración de confianza del proxy para decidir si debe aceptar las direcciones y los protocolos reenviados, lo que afecta al comportamiento local o remoto y a las reglas de acceso externo.

La guía de redes de Jellyfin advierte que los encabezados reenviados desde un proxy que no sea de confianza se descartan y recomienda configurar la dirección del proxy en Proxies conocidos. configuración de Proxies conocidos Una comprobación independiente de la IP del cliente resulta útil cuando el sitio funciona, pero todas las solicitudes parecen originarse en el proxy.

No resuelvas un problema de identidad confiando en toda subred privada ni en todos los encabezados reenviados. Añade únicamente el salto real del proxy o la red del proxy bajo control y, después, compara una solicitud de la LAN con una remota en los registros de Jellyfin para confirmar que se clasifican como corresponde.

Prueba por separado las direcciones del navegador y del cliente nativo

Introduce la dirección completa del servidor, incluida la subruta, cuando un cliente de Jellyfin solicite la URL del servidor. Un cliente guardado como https://example.com no puede deducir que Jellyfin se encuentra en /jellyfin.

Prueba un navegador y un cliente nativo desde la LAN y, después, repite la prueba mediante el nombre de host público. Si el nombre de host funciona, pero el acceso directo mediante la IP local no, puede ser lo esperado cuando la ruta del proxy y el certificado dependen del nombre de host; las pruebas con nombre de host frente a IP ayudan a aislar ese caso sin debilitar el proxy.

Da por terminada la prueba cuando la URL con prefijo se mantenga durante el inicio de sesión, la navegación, el uso de WebSockets y la reproducción en los clientes que realmente admites. Si falla un solo cliente mientras el navegador y los demás funcionan, trátalo como un problema de dirección o compatibilidad del cliente, en lugar de reescribir una configuración del proxy que ya funciona.