Establece los tiempos de espera del proxy según la carga legítima más lenta que aceptarás, con un margen, y mantén la aplicación y cualquier proxy ascendente al menos igual de permisivos. No soluciones cada carga fallida eligiendo un tiempo de espera ilimitado.
Una foto o un vídeo grande puede fallar mientras la misma aplicación funciona con normalidad porque el cuerpo de la solicitud, el procesamiento ascendente o la respuesta supera un límite diferente. Registra primero el código de estado, el tiempo transcurrido, el tamaño del archivo y el registro del proxy. Estas observaciones permiten distinguir entre un rechazo por tamaño del cuerpo, un tiempo de espera por inactividad, un tiempo de espera del backend o una desconexión del cliente.
Identifica la etapa que finaliza la carga
Repite la prueba con un archivo conocido y observa si el fallo ocurre durante la transferencia, después de que la barra de progreso llegue al 100 por ciento o mientras el servidor procesa el contenido multimedia. Cada fase corresponde a una conexión y un tiempo de espera diferentes.
Un fallo constante en el mismo número de bytes sugiere un límite de tamaño del cuerpo; un fallo después del mismo intervalo de inactividad sugiere un tiempo de espera. Un error de la puerta de enlace después de completar la carga apunta a la espera entre el proxy y la aplicación o al propio límite de procesamiento de la aplicación.
Lee conjuntamente los registros de acceso y de errores del proxy con los registros de la aplicación. Si el cliente cerró la conexión primero, aumentar únicamente el tiempo de espera del proxy no ayudará; verifica el comportamiento de la aplicación móvil en segundo plano, la estabilidad de la VPN y la ruta de solicitud del navegador.
Mide un presupuesto de tiempo de espera defendible
Divide el archivo más grande aceptado entre la velocidad ascendente mínima compatible para estimar el tiempo de transferencia y, después, añade margen para TLS, el almacenamiento en búfer y las variaciones del rendimiento. Usa este valor como límite máximo para el trabajo legítimo, no como una promesa de que toda conexión lenta deba permanecer abierta indefinidamente.
Distingue entre la duración total y la duración de inactividad. Por ejemplo, NGINX documenta directivas de tiempo de espera del proxy independientes, y algunas miden el intervalo entre operaciones sucesivas en lugar de la duración de toda la respuesta.
Ten en cuenta el riesgo de denegación de servicio. Restringe los endpoints de carga mediante autenticación y controles de velocidad antes de ampliar considerablemente la duración de las conexiones, y no expongas la interfaz de administración del proxy.
Alinea todas las capas sin corregir en exceso
Establece el tamaño del cuerpo de la solicitud en el máximo compatible con la aplicación o por encima de él. Después, alinea los tiempos de espera de lectura del cuerpo del cliente, conexión ascendente, lectura ascendente y envío ascendente según la fase del fallo observada.
Comprueba si existe una CDN externa, un túnel, un balanceador de carga o un segundo proxy inverso con un límite inmutable más corto. El límite efectivo es el menor de toda la cadena, por lo que cambiar únicamente el proxy interno puede no producir ningún resultado observable.
Mantén documentadas las URL de la aplicación y las rutas del proxy. La guía de ZimaSpace sobre Immich en un recurso compartido de red ayuda a separar los errores de la ruta de carga de la latencia y las interrupciones del montaje del almacenamiento.
Vuelve a probar cargas lentas, grandes e interrumpidas
Carga el archivo que fallaba originalmente desde la ubicación original y con la velocidad de red original. Una prueba superada requiere que se complete la carga, que la aplicación indexe el contenido y que el recurso se pueda reproducir o visualizar, no solo obtener un código de éxito HTTP.
Limita una conexión de prueba a la velocidad mínima compatible y repite la prueba. Después, interrumpe deliberadamente una carga; los archivos temporales y los registros incompletos de la base de datos deben limpiarse según el comportamiento de la aplicación.
Deja de aumentar los tiempos de espera cuando los registros muestren un bloqueo del backend, un error de almacenamiento o un límite fijo del proveedor externo. Revierte los valores excesivos, corrige la capa que falla y conserva el tiempo de espera más pequeño que cubra de forma constante la carga de trabajo medida.
Preguntas frecuentes
¿Todos los tiempos de espera del proxy deberían usar el mismo valor? No. El establecimiento de la conexión, las lecturas del cuerpo del cliente, las esperas de respuesta ascendente y los envíos descendentes protegen fases diferentes.
¿Por qué funciona una foto pequeña mientras falla un vídeo? El vídeo puede superar un umbral de tamaño del cuerpo, tardar más que un límite de inactividad o activar un procesamiento más prolongado en el servidor; los registros y el momento del fallo permiten identificar cuál de estas causas se aplica.
Soporte y Consejos
Más para leer

¿Puede una galería autoalojada conservar el emparejamiento de las Live Photos de Apple?
Una decisión condicional sobre un servidor doméstico para emparejar Apple Live Photo, con pruebas controladas, interpretación de resultados, reversión y preguntas frecuentes específicas.

¿Puedes importar Google Takeout y las copias de seguridad del teléfono en una sola biblioteca de fotos?
Una decisión condicional sobre un servidor doméstico para la importación combinada de fotos, con pruebas controladas, interpretación de resultados, reversión y preguntas frecuentes específicas.

¿Puede Immich usar una biblioteca externa sin hacerse cargo de los archivos?
Una decisión condicional sobre el servidor doméstico para la propiedad de bibliotecas externas de Immich, con pruebas controladas, interpretación de resultados, reversión y preguntas...

