¿Por qué Jellyfin pierde las sesiones después de un cambio de proxy o DNS?
Un cambio de proxy o DNS no debería destruir automáticamente todos los inicios de sesión de Jellyfin. La pérdida de sesión suele aparecer cuando el cambio también altera el nombre de host, el esquema, la ruta, la identidad del servidor backend, la capa de autenticación o la ruta del cliente que espera el estado de inicio de sesión existente.
Empieza separando una simple actualización del registro DNS de un cambio de origen. Mantén fija una cuenta y un dispositivo conocidos, compara el acceso directo desde la LAN con el nombre de host público habitual y captura la primera solicitud fallida antes de borrar los datos del cliente. El objetivo es identificar qué límite cambió, no restablecer usuarios hasta que el síntoma desaparezca.
Primero decide si el origen público realmente cambió
Anota el esquema, el nombre de host, el puerto, la ruta base y la ruta del proxy antiguos y nuevos. Un registro DNS A o AAAA puede apuntar el mismo nombre de host a una dirección diferente sin cambiar el origen del navegador, mientras que pasar de un nombre de host a otro o cambiar la ruta base de una aplicación crea un límite de cliente diferente. Las migraciones a dominios personalizados también requieren que la aplicación y la ruta de autenticación coincidan con el nuevo dominio; una lista de comprobación para migrar a un dominio personalizado hace explícita esa vinculación entre DNS y aplicación.
El estado de autenticación depende de dónde se presenta. Una útil lista de comprobación del alcance de las cookies de sesión comienza por mapear el dominio y la ruta asociados a cada mecanismo de autenticación. Los clientes de Jellyfin no almacenan todos el estado exactamente de la misma manera, así que prueba el cliente afectado en lugar de asumir que el comportamiento del navegador describe todas las aplicaciones.
Si el nombre de host antiguo sigue funcionando, pero el nuevo solicita iniciar sesión, considéralo una migración de origen esperada hasta demostrar lo contrario. Si el mismo nombre de host cierra la sesión de todos únicamente después de cambiar el proxy, conserva el nombre de host y pasa a investigar la identidad del upstream, las cabeceras y la autenticación del proxy.
Verifica que el DNS siga dirigiendo a la misma instancia prevista de Jellyfin
Resuelve el nombre de host desde un cliente de la LAN y, si importa el acceso remoto, también desde un resolvedor externo. Confirma que la dirección devuelta llega al proxy inverso previsto y que el proxy dirige el tráfico al servicio de Jellyfin esperado, no a un contenedor antiguo, una instancia de prueba, un clon restaurado o un segundo servidor con una base de datos persistente diferente.
Un cambio de DNS puede parecer un problema de sesión cuando en realidad envía al cliente a un backend diferente. Compara la respuesta que identifica el servidor, el comportamiento de la lista de usuarios, el estado de las bibliotecas y el destino upstream del proxy antes de tocar la autenticación. Si la nueva ruta llega a una instancia de Jellyfin nueva o restaurada, las credenciales existentes del cliente podrían dejar de representar una sesión válida allí.
El flujo de trabajo relacionado de ZimaSpace para mantener separados los ciclos de vida del proxy y del estado de sesión resulta útil aquí: un reinicio de la entrada no debería reemplazar silenciosamente la identidad de la aplicación ni el estado que valida las sesiones existentes.
Compara el host reenviado, el esquema, la ruta y la autenticación del proxy
Captura la configuración efectiva del proxy después del cambio. Compara el valor público de Host, el esquema reenviado, la dirección del cliente, la ruta de actualización de WebSocket, las redirecciones y cualquier middleware de autenticación con la última configuración funcional. Una redirección de HTTPS a una URL HTTP inesperada o a un host alternativo puede hacer que un inicio de sesión válido parezca haber desaparecido.
Si hay otra capa de autenticación delante de Jellyfin, mantén estables su clave de firma, el nombre de la cookie, el dominio de la cookie y el almacén de sesiones durante el reemplazo del proxy. Los diseños con balanceador de carga utilizan estado de afinidad de sesión y de enrutamiento para mantener una solicitud en el backend previsto; cambiar esa capa puede provocar un cierre de sesión o un bucle aunque Jellyfin siga funcionando correctamente.
No copies ciegamente cabeceras de un ejemplo de proxy no relacionado. Cambia un valor únicamente cuando la solicitud fallida o la redirección demuestre que el valor actual es incorrecto. La configuración de proxy más segura es la mínima que conserva el origen público y llega de forma coherente al backend correcto.
Usa una prueba con un cliente limpio sin borrar las pruebas originales
Antes de borrar nada, guarda la hora del fallo, la versión del navegador o de la aplicación, el estado de la solicitud, la cadena de redirecciones, la línea del registro del proxy y la entrada correspondiente del registro de Jellyfin. Después, utiliza una ventana de navegación privada o un segundo dispositivo de prueba para iniciar sesión a través de la nueva ruta. Un inicio de sesión nuevo que funciona demuestra que hay conectividad; no explica por qué el estado antiguo dejó de ser utilizable.
Compara estas tres rutas en orden: la dirección directa de Jellyfin en la LAN, el nombre de host habitual desde la LAN y el nombre de host habitual desde fuera de la LAN. Si el acceso directo funciona mientras el nombre de host falla, conserva los usuarios y el estado de la base de datos sin cambios e investiga el DNS, TLS, el proxy o el middleware. Si todas las rutas rechazan la misma cuenta conocida y válida, el problema vuelve a estar dentro de Jellyfin o de su estado persistente.
Borra el estado específico del sitio en el cliente afectado solo después de capturar las pruebas de la ruta de la solicitud. Evita eliminar todos los dispositivos registrados o revocar todas las sesiones como primer paso, porque eso elimina la comparación que podría distinguir una migración de enrutamiento de un fallo de autenticación del servidor.
Valida el cambio mediante la expiración del DNS, el reinicio del proxy y el reinicio del sistema
Después de aplicar la solución correspondiente, deja que expire la ventana del TTL de DNS anterior, reinicia únicamente el proxy, después reinicia el servicio de Jellyfin y, por último, reinicia el equipo anfitrión. Repite las pruebas de inicio y cierre de sesión, comienzo de reproducción, búsqueda y reconexión a través del mismo nombre de host después de cada evento.
Un resultado estable significa que el nombre de host sigue resolviendo al proxy previsto, que el proxy vuelve a conectarse a la instancia de Jellyfin prevista, que las sesiones existentes sobreviven a los reinicios normales de los componentes cuando corresponde y que un inicio de sesión nuevo sigue siendo válido. Si los fallos aparecen únicamente durante el arranque de toda la pila, utiliza la ruta de recuperación del proxy hacia el upstream para separar la disponibilidad del servicio de la autenticación.
Registra en las notas del despliegue el nombre de host final, el nombre del upstream del proxy, la ruta base, el origen del certificado y cualquier secreto de sesión del proxy. Así, los futuros cambios de DNS o proxy podrán probarse según un contrato de identidad conocido, en lugar de redescubrirlo a partir de los síntomas del navegador.
Preguntas frecuentes
¿Cambiar un registro DNS por sí solo invalida las sesiones de Jellyfin?
Por lo general, no, siempre que se mantengan el mismo nombre de host, esquema, ruta e instancia de Jellyfin. Un cambio de DNS adquiere relevancia para la sesión cuando envía a los clientes a un backend diferente, cambia el origen público, altera TLS o las redirecciones, o modifica una capa de autenticación situada delante de Jellyfin.
¿Debería revocar todas las sesiones de Jellyfin después de cambiar un proxy?
No como primera medida de reparación. Conserva un cliente que presente el fallo como prueba, confirma que la nueva ruta llega al servidor previsto y prueba por separado un inicio de sesión nuevo. Revoca las sesiones únicamente si has rotado credenciales de forma intencionada, sospechas que se han expuesto tokens o has confirmado que el estado antiguo del cliente ya no debe considerarse fiable.
Productos recomendados
Soporte y Consejos
Más para leer
¿Deberías hacer una copia de seguridad de Home Assistant en ejecución o detener primero el servicio?
Las copias de seguridad integradas de Home Assistant pueden ejecutarse en vivo; las copias simples del sistema de archivos deben detener o poner en...
¿Por qué un servidor de Home Assistant se calienta o hace ruido durante las horas de inactividad?
Correlaciona los picos de ventilación o temperatura de Home Assistant con Recorder, las copias de seguridad, las integraciones y las tareas alojadas conjuntamente antes...
¿Cuándo deberías reconstruir Home Assistant en lugar de repararlo?
Repara primero la capa más pequeña de Home Assistant que haya fallado, restaura después un estado conocido y funcional, y reconstruye solo cuando no...
