Cómo saber si un error de Immich proviene del cliente o del servidor

Determina si un error de Immich se origina en el cliente o en el servidor reproduciendo la misma acción con una sola variable modificada y siguiendo la solicitud fallida a través de la ruta.

Un banner móvil que dice «error del servidor» aún puede originarse en el estado del cliente, TLS, un proxy inverso o una solicitud que el servidor rechazó correctamente. Del mismo modo, un fallo que solo ocurre en el navegador no demuestra que el navegador esté averiado. Mantén iguales la cuenta, el recurso y la acción; compara clientes y rutas; después usa los códigos de estado y registros sincronizados para localizar la primera capa que falla.

Reproduce la misma acción en un segundo cliente

Elige una acción determinista, como iniciar sesión, abrir un recurso conocido, subir la misma foto pequeña o ejecutar la misma búsqueda. Repítela con la misma cuenta en un navegador y en un cliente móvil, manteniendo sin cambios la ruta de red. Registra la hora exacta y el resultado de ambos intentos.

Un informe reciente de Immich en el que un cliente Android falló mientras se probaban otras vías de acceso ilustra el valor de comparar clientes. La causa de un hilo no se puede generalizar, pero un resultado específico del cliente reduce considerablemente dónde conviene buscar a continuación.

Si todos los clientes fallan al realizar la misma acción al mismo tiempo, el servidor, la base de datos, el almacenamiento o la ruta de red compartida suben puestos en la lista. Si solo falla un cliente mientras otro funciona mediante el mismo endpoint, comprueba la versión del cliente, el estado en caché, los permisos, la confianza local en el certificado y la solicitud exacta que difiere.

Cambia la ruta sin cambiar la cuenta ni el recurso

A continuación, compara una ruta local de confianza con la ruta normal mediante proxy inverso, VPN, túnel o acceso remoto. Usa la misma cuenta y la misma acción. Si funciona localmente pero falla de forma remota, el problema probablemente no está en el registro multimedia, sino en las capas de DNS, TLS, proxy, firewall o enrutamiento ascendente.

La guía de ZimaSpace sobre el diagnóstico de rutas locales y remotas explica por qué el éxito en la LAN y el éxito a través de Internet son pruebas diferentes. Aplica ese límite a Immich antes de reinstalar una aplicación móvil o reconstruir el servidor.

Si ambas rutas fallan de forma idéntica, deja de cambiar la configuración del proxy e inspecciona la solicitud del lado de la aplicación. Si solo falla la ruta mediante proxy, registra el estado del proxy, el resultado de TLS, la respuesta ascendente y el tiempo de espera. Esta comparación de una sola variable evita que un mensaje del cliente desvíe la investigación hacia la capa equivocada.

Usa los códigos de estado como pistas, no como veredictos definitivos

Las clases de estado HTTP ayudan a clasificar dónde buscar, pero no identifican automáticamente el componente que causó la condición. Un código 4xx suele indicar que la solicitud, la autenticación o la autorización no eran aceptables; un código 5xx indica que un componente del servidor no pudo completar la solicitud. Los proxies pueden generar cualquiera de las dos clases antes de que Immich reciba la solicitud.

La guía de campos de los registros de acceso destaca el código de estado, la ruta de la URL, la hora de la solicitud, el host remoto y los identificadores de solicitud como campos útiles para solucionar problemas. Captura esos valores para la única acción que falla en lugar de revisar miles de líneas no relacionadas.

Si el proxy registra un 502 o un tiempo de espera sin ninguna solicitud correspondiente en Immich, sigue la ruta ascendente. Si Immich registra una solicitud y devuelve un 4xx determinista, inspecciona la autenticación, los permisos o el contenido de la solicitud. Si el cliente informa de un fallo, pero todas las capas del servidor muestran un 2xx, inspecciona el análisis de la respuesta en el cliente, la caché local o las solicitudes posteriores.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Correlaciona la tasa de errores, la latencia y los registros del servidor en una misma marca de tiempo

Una solicitud fallida puede ser un caso aislado. Reproduce la acción entre cinco y diez veces y registra la tasa de éxito y la latencia mientras observas los registros relevantes del servidor y del proxy. Si los errores aumentan durante una presión elevada sobre los recursos o picos en las colas, el servidor puede estar disponible de forma intermitente aunque un segundo intento tenga éxito.

La visión general de Better Stack sobre los errores y la latencia como señales del servicio separa la tasa de errores de la latencia y el tráfico. Este enfoque ayuda a distinguir una única solicitud malformada del cliente de una ruta del servidor que solo se degrada bajo carga.

Si los registros del servidor contienen la misma excepción para varios clientes, considéralo un problema del servidor hasta que se demuestre lo contrario. Si el servidor nunca recibe la solicitud fallida, rastrea DNS, TLS, el proxy y la red del cliente. Si solo un cliente genera una forma de solicitud diferente, actualiza o restablece ese cliente después de conservar suficientes pruebas para confirmar la diferencia.

Emite el diagnóstico final con una prueba de dos por dos

Usa dos clientes y dos rutas: navegador-local, navegador-remoto, móvil-local y móvil-remoto. Mantén la misma cuenta y el mismo recurso de prueba. Esta matriz separa los fallos específicos del cliente de los fallos específicos de la ruta y de los fallos del servidor que afectan a todas las combinaciones.

La causa está respaldada por el cliente cuando un cliente falla en ambas rutas mientras otro funciona. La causa está respaldada por la ruta cuando ambos clientes fallan únicamente a través de una ruta. La causa está respaldada por el servidor cuando las cuatro combinaciones reproducen el mismo error de la aplicación y los registros del servidor muestran la misma operación fallida.

Después de corregir la capa identificada, vuelve a ejecutar las cuatro combinaciones y reinicia una vez el componente afectado. Detente cuando la combinación que fallaba originalmente funcione sin romper las combinaciones de control. Escala el caso con la matriz, las marcas de tiempo, los estados HTTP, fragmentos de los registros del proxy y del servidor, las versiones de los clientes y una solicitud reproducible, en lugar de una captura de pantalla genérica.