¿Por qué Immich se siente más rápido en una red LAN que mediante conexiones remotas?

Immich suele sentirse más rápido en la LAN porque los clientes locales recorren una ruta más corta y con menor latencia, con menos puertas de enlace y sin que la conexión a Internet doméstica actúe como cuello de botella.

El uso remoto puede añadir límites de subida del ISP, redes móviles o de hoteles, DNS, terminación TLS, un proxy inverso, una VPN o una red superpuesta y, en ocasiones, un relé. Estas incorporaciones no ralentizan todas las solicitudes de la misma manera: las miniaturas, las consultas de metadatos, las descargas de originales, las subidas y las llamadas de búsqueda exigen distintas partes de la ruta. Por eso, compara acciones idénticas antes de concluir que «Immich remoto» es un único modo de rendimiento.

La LAN elimina la mayor parte de la variabilidad de la ruta WAN

En una LAN cableada o con una señal Wi-Fi potente, el cliente y el servidor normalmente están separados por solo unos pocos saltos locales de conmutación o enrutamiento. El tiempo de ida y vuelta es bajo y el hogar controla la mayor parte de la ruta, por lo que las pequeñas llamadas a la API y muchas solicitudes de miniaturas pueden completarse con poca espera de red.

El modelo de conexión directa frente a conexión mediante relé de la traversía de NAT ayuda a explicar el contraste. Un cliente remoto puede llegar al mismo servidor mediante un túnel WAN directo o a través de un relé, mientras que el cliente de la LAN simplemente utiliza la ruta local. El punto final de la aplicación puede ser idéntico aunque las condiciones de transporte no lo sean.

Una LAN más rápida no demuestra que el servidor funcione correctamente con todas las cargas de trabajo. La baja latencia local puede ocultar solicitudes ineficientes o un almacenamiento lento porque la espera de red es pequeña. Mantén las métricas del servidor en la comparación para que un diagnóstico de la ruta remota no excuse un cuello de botella del backend que afecte a ambas rutas.

La subida doméstica se convierte en capacidad de descarga remota

Cuando alguien fuera de casa abre fotos de un servidor doméstico, el servidor envía los datos a través de la dirección de subida de la conexión a Internet del hogar. Muchas conexiones residenciales tienen mucha menos capacidad de subida que una red Ethernet o Wi-Fi local, por lo que los originales remotos y las vistas previas grandes pueden quedar limitados por el ancho de banda aunque la navegación en la LAN sea instantánea.

Un hilo de la comunidad sobre el acceso remoto familiar muestra por qué los hogares evalúan algo más que la conectividad: la ruta también debe ser sencilla y fiable para los usuarios no técnicos. El rendimiento, la autenticación y la experiencia de usuario forman parte de la ruta remota práctica.

El ancho de banda no es la explicación adecuada cuando los pequeños controles de metadatos, filtros u operaciones de inicio de sesión son lentos mientras que las transferencias grandes alcanzan la velocidad esperada. Ese patrón apunta con más fuerza a la latencia, el enrutamiento de solicitudes, el comportamiento del proxy, el DNS o el tiempo de respuesta del servidor.

Los proxies y túneles añaden límites de procesamiento y configuración

Una solicitud remota puede terminar el TLS en un proxy, atravesar otra red de contenedores o viajar mediante una red superpuesta cifrada antes de llegar a Immich. Las capas bien configuradas pueden añadir poca sobrecarga, pero cada capa introduce otro punto en el que el almacenamiento en búfer, la gestión de encabezados, la política de tiempo de espera, la selección de ruta o los problemas de MTU pueden afectar a determinadas solicitudes.

Un informe de un usuario de Immich de 2026 sobre los retrasos del filtrado remoto identificó finalmente un problema de configuración de la ruta del punto final, después de considerar también el rendimiento del relé. El ejemplo es valioso porque dos mecanismos distintos produjeron síntomas similares de que «lo remoto va lento».

No cambies de tecnología de acceso remoto basándote en una sola carga de página. Primero identifica si la operación que falla es una transferencia, una solicitud de API, la autenticación o el establecimiento de la conexión. Un proxy inverso no puede solucionar un enlace de subida doméstico saturado, y un túnel más rápido no puede solucionar una consulta lenta a la base de datos.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

La caché puede hacer que las pruebas de la LAN y remotas no sean equivalentes

Es posible que un teléfono conectado a la LAN ya tenga en caché las miniaturas, el estado de la sesión, las respuestas DNS o los recursos a los que accedió recientemente, mientras que la prueba remota puede comenzar en un estado con menos elementos en caché. Comparar esas dos ejecuciones puede exagerar la diferencia de red porque uno de los clientes solicita menos datos al servidor.

La explicación de ZimaSpace sobre la latencia del almacenamiento refuerza la necesidad de controlar el estado de la caché y de la carga de trabajo al comparar el rendimiento. La misma disciplina se aplica a las pruebas de rutas: utiliza la misma cuenta, el mismo conjunto de recursos, el mismo cliente y, cuando sea posible, las mismas condiciones de caché.

El mecanismo LAN frente a WAN deja de explicar una discrepancia que persiste cuando ambas pruebas se fuerzan a utilizar la misma ruta o cuando el tiempo de respuesta del servidor aumenta de forma idéntica. En ese punto, inspecciona la aplicación o el equipo en lugar de seguir optimizando la topología de red.

Construye una comparación de rutas con las mismas acciones

Elige cuatro acciones: cargar el mismo álbum, abrir la misma foto grande, ejecutar la misma búsqueda conocida y subir el mismo archivo de prueba. Registra el tiempo observado por el cliente, el tiempo de solicitud del servidor cuando esté disponible, la latencia de ida y vuelta, el rendimiento de transferencia y si la ruta remota es directa, está detrás de un proxy o utiliza un relé.

Compara las ejecuciones en la LAN y remotas desde un estado de caché conocido y, después, cambia solo una variable de la ruta cada vez. El análisis de Tailscale sobre las conexiones directas y mediante relé proporciona un modelo útil para clasificar las rutas. Si solo mejoran las transferencias grandes, el ancho de banda es el límite más probable.

Acepta el diagnóstico cuando el cambio de ruta mejore la operación que predice el mecanismo sin cambiar la carga de trabajo del servidor. Mantén el diseño remoto más sencillo que cumpla los objetivos de acceso y rendimiento de la familia; las capas adicionales de proxy, túnel o relé deben existir por una razón clara de accesibilidad o seguridad.