El inicio de sesión de Immich falla después de que se reinicia el proxy inverso

Si el inicio de sesión en Immich falla solo después de reiniciar el proxy inverso, comprueba primero si se interrumpió la ruta del proxy mientras la aplicación de Immich y la cuenta siguen funcionando directamente.

Un reinicio puede dejar al descubierto direcciones de upstream obsoletas, la falta de pertenencia a una red compartida, cambios en las cabeceras, el comportamiento de las cookies o un proceso del proxy que se inició antes de que sus dependencias estuvieran disponibles. Prueba la misma cuenta mediante el endpoint local de Immich y el nombre de host público habitual; después, sigue la primera capa en la que ambas rutas diverjan.

Usa el acceso directo para distinguir la autenticación de un fallo del proxy

Prueba una cuenta conocida contra el servidor de Immich mediante una ruta local de confianza que omita el proxy inverso. Si el inicio de sesión directo funciona mientras el nombre de host público se queda cargando, redirige o devuelve un error del upstream, es probable que el registro de usuario y la ruta de autenticación principal estén intactos. Centra la investigación en el proxy, TLS, el enrutamiento y el estado del navegador.

Un caso de la comunidad en el que el acceso directo funcionaba mientras el inicio de sesión mediante el proxy fallaba ilustra este método de aislamiento. El informe es específico de una versión, así que úsalo para justificar la comparación entre rutas, no para asumir la misma causa raíz.

Si fallan tanto el inicio de sesión directo como el realizado mediante el proxy, deja de cambiar la configuración del proxy. Comprueba en su lugar el estado del servicio de Immich, la conectividad con la base de datos, el estado de la cuenta y los registros del servidor. Un reinicio del proxy ocurrido cerca del fallo puede ser una coincidencia; la prueba de bypass evita convertir ese momento en un diagnóstico sin fundamento.

Verifica que el proxy pueda alcanzar el upstream actual de Immich

Después de reiniciar el proxy, confirma que puede resolver y conectarse al upstream de Immich desde su propio espacio de nombres de red. En Docker, un upstream basado en el nombre del servicio dentro de una red definida por el usuario y compartida suele ser más estable que una IP de contenedor copiada manualmente, que cambia cuando se recrea un contenedor.

Un debate sobre una interrupción del proxy inverso relacionada con la conectividad entre el proxy e Immich muestra por qué conviene comprobar la accesibilidad del upstream y la configuración del proxy compatible con WebSocket antes de recuperar cuentas. Considera la configuración exacta como evidencia anecdótica, no como una plantilla para cualquier proxy.

Reinicia el proxy por separado dos veces y observa si su upstream se resuelve en el mismo servicio cada vez. La prueba es satisfactoria si se establece una conexión correcta de inmediato sin editar direcciones. Si la resolución de nombres, la pertenencia a la red o el puerto de destino cambian después de recrear los contenedores, corrige la definición de red de Compose en lugar de reiniciar repetidamente toda la pila.

Inspecciona las cabeceras reenviadas, TLS y el comportamiento de las cookies

El inicio de sesión puede fallar incluso cuando el proxy devuelve la página de Immich, porque la autenticación depende de toda la ruta HTTP. Compara la configuración del proxy antes y después del reinicio, incluido el reenvío del host y el esquema, la terminación de HTTPS, las redirecciones, cualquier reescritura de cookies y la posibilidad de que otro proxy o túnel también esté modificando la respuesta.

Un debate de la comunidad de Immich documenta un caso de inicio de sesión con cookies duplicadas en el que la gestión de cookies del proxy provocaba que el inicio de sesión quedara bloqueado. Es un caso concreto, pero sirve para recordar que debes inspeccionar la respuesta y las cookies del navegador en lugar de asumir que unas credenciales válidas garantizan una sesión correcta mediante el proxy.

No elimines todas las cuentas ni restablezcas la base de datos porque una sesión del navegador parezca bloqueada. Usa una ventana privada o un segundo navegador después de registrar las cookies y la respuesta originales. Si un cliente limpio funciona, borra únicamente el estado del sitio afectado y corrige la regla del proxy que creó la cookie o redirección incorrecta.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Lee los registros de acceso y errores del proxy en la marca de tiempo de la solicitud fallida

Reproduce un intento de inicio de sesión y registra la hora exacta, el nombre de host público, el cliente y el estado devuelto. Después, inspecciona los registros de acceso y errores del proxy en torno a esa solicitud. Distingue entre una solicitud que nunca llegó al proxy, un error 4xx o 5xx generado por el proxy, un fallo de conexión con el upstream y una solicitud que llegó a Immich pero recibió una respuesta de la aplicación.

El flujo de trabajo para solucionar problemas con los registros de NGINX muestra cómo el estado, los errores del upstream, los tiempos de las solicitudes y los registros específicos proporcionan una señal mucho más clara que actualizar repetidamente la página de inicio de sesión. Aplica el mismo principio a Caddy, Traefik u otro proxy.

Si el registro del proxy muestra una respuesta correcta del upstream mientras el navegador no logra completar el inicio de sesión, inspecciona las redirecciones, las cookies, TLS y el estado del cliente. Si el proxy no puede conectarse al upstream, corrige el enrutamiento o la disponibilidad del servicio. Si Immich devuelve el error, sigue el registro del servidor correspondiente en lugar de atribuir la causa al proxy.

Demuestra que la solución resiste el reinicio que provocó originalmente el fallo

Después de corregir la causa confirmada, repite exactamente el desencadenante: reinicia solo el proxy inverso, espera a que pase su comprobación de estado e inicia sesión mediante el nombre de host público. Después, abre un recurso existente, sube un archivo pequeño y mantén la sesión activa el tiempo suficiente para verificar el tráfico normal de la API.

La guía de ZimaSpace sobre rutas de acceso remoto controladas establece el contexto general: el proxy es solo una capa del acceso remoto, por lo que el DNS, TLS, la autenticación y el upstream privado deben mantenerse configurados de forma intencional y ser observables.

Considera la prueba superada solo cuando el inicio de sesión sobreviva a dos reinicios del proxy y la misma configuración se inicie correctamente después de reiniciar toda la pila. Revierte los cambios recientes del proxy si una nueva regla de cabeceras o cookies provocó el fallo. Solicita ayuda proporcionando la diferencia de configuración del proxy, el estado de la solicitud, el error del upstream, la marca de tiempo del registro del servidor y el resultado de la prueba directa frente a la realizada mediante el proxy.