¿Debería Immich usar una red del host o una red puente?

Para la mayoría de las implementaciones de Immich basadas en Docker, una red bridge definida por el usuario es la opción predeterminada más limpia; la red del host es una solución específica, no una mejora de rendimiento universal.

Immich necesita principalmente rutas fiables entre el cliente y el servidor, el servidor y la base de datos, el servidor y Redis, el servidor y el aprendizaje automático, y el servidor y el proxy inverso. Ambos modos de red pueden proporcionarlas. La elección debe hacerse reproduciendo el fallo real o el requisito de acceso, probando un modo a la vez y conservando la configuración que sea más fácil de observar y recuperar.

Empieza por las rutas que Immich realmente necesita

Representa la pila como conexiones en lugar de contenedores: los clientes acceden al punto de conexión público o local de Immich; el proxy accede al servidor de Immich; la aplicación accede a PostgreSQL y Redis; y el servidor accede al aprendizaje automático. Indica qué conexiones permanecen dentro de Docker y cuáles atraviesan el límite del host.

Una red bridge definida por el usuario proporciona a los contenedores su propio espacio de nombres de red y permite que los servicios de la misma red se resuelvan entre sí por nombre de servicio. El resumen sobre los modos de red de Docker es útil para distinguirlos: los puertos publicados sirven a los clientes del host o externos, mientras que el DNS de los contenedores gestiona el tráfico entre servicios.

Si todas las rutas necesarias ya funcionan con una red bridge, la red del host no ha resuelto ningún problema demostrado. Conserva la red bridge y documenta los nombres de servicio, las redes y los puertos publicados para poder comparar cualquier cambio posterior en el proxy o en Compose con una topología conocida.

Prefiere una red bridge definida por el usuario cuando importen el aislamiento y los nombres de servicio estables

El modo bridge permite que los servicios de Immich se comuniquen en una red de aplicación explícita sin exponer todos los puertos de los contenedores en el host. Esto resulta especialmente útil cuando un proxy inverso comparte la red y puede dirigirse directamente al nombre del servicio de Immich, reduciendo la dependencia de una IP de contenedor que podría cambiar tras recrearlo.

El análisis de las ventajas y desventajas de la red del host en laboratorios domésticos señala que eliminar la traducción NAT de Docker rara vez supone una ganancia de rendimiento significativa para el tráfico web habitual de un homelab. Las diferencias más importantes son el aislamiento del espacio de nombres, la publicación de puertos y la forma en que los servicios se descubren entre sí.

El modo bridge solo falla como diseño cuando una ruta necesaria no puede expresarse o sigue siendo poco fiable después de corregir la red, el DNS, el firewall y la pertenencia al proxy. No cambies de modo simplemente porque un cliente muestre «servidor inaccesible»; primero demuestra que la solicitud se detiene en el límite de Docker.

Usa la red del host solo para un requisito específico y reproducible

El modo host coloca el contenedor en el espacio de nombres de red del host, lo que elimina la traducción de puertos de Docker y proporciona al servicio el contexto de red del host. Esto puede simplificar ciertos casos de descubrimiento o enrutamiento inusual, pero también elimina el límite de puertos del contenedor y aumenta la posibilidad de conflictos con los puertos del host.

Una comparación actual entre las redes bridge y host plantea la elección en función del rendimiento, el aislamiento, la exposición de servicios y la depuración. Aplica esas dimensiones a la ruta de Immich en lugar de asumir que el modo host es inherentemente más fiable.

Si el modo host soluciona un síntoma, reproduce la prueba dos veces y explica por qué. Por ejemplo, confirma que el mismo nombre de host, la misma cuenta, el mismo proxy y el mismo cliente fallan con la red bridge y funcionan con la red host, mientras los registros de la aplicación permanecen saludables. Si el resultado no puede repetirse, el cambio de modo quizá solo haya ocultado un problema de DNS o un estado de red obsoleto.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Mantén el proxy inverso en una ruta explícita y recuperable

Un proxy inverso debe poder llegar a Immich mediante una definición de origen estable después de reiniciar cualquiera de los contenedores. Con una red bridge, prefiere una red definida por el usuario compartida y un origen basado en el nombre del servicio en lugar de copiar manualmente la IP del contenedor. Con el modo host, dirige el proxy a la dirección y el puerto previstos del host, comprobando que no haya conflictos.

El patrón de prueba entre host y bridge de ZimaSpace utiliza una regla condicional análoga: la simplicidad del descubrimiento puede justificar el modo host, mientras que el aislamiento y la integración explícita con el proxy favorecen una red bridge. Immich utiliza protocolos diferentes, así que reutiliza el método de decisión, no las suposiciones sobre puertos específicas de Plex.

Reinicia primero solo el proxy, después solo Immich y, por último, toda la pila. Un diseño correcto restablece las mismas rutas locales y remotas cada vez sin editar direcciones IP. Una topología que requiere volver a cablearse manualmente después de recrear los contenedores no es lo bastante estable, independientemente de que use la red host o bridge.

Elige el modo que supere la misma prueba de aceptación con menos riesgo

Prueba el inicio de sesión web local, la conexión de la aplicación móvil, una carga pequeña, una carga grande, el acceso mediante el proxy inverso, el estado de los servicios y un reinicio completo. Registra la latencia y los fallos, pero no des demasiada importancia a pequeñas diferencias de rendimiento si ambos modos se mantienen muy por debajo del límite de la red.

Elige bridge cuando todas las funciones pasen y te beneficies de una exposición explícita, del DNS de los contenedores y del aislamiento. Elige host cuando una ruta necesaria falle de forma reproducible con una red bridge correctamente configurada y el modo host la solucione sin crear conflictos de puertos ni ampliar la exposición más allá de lo que aceptes.

Si ambos modos fallan de la misma manera, deja de alternar entre configuraciones de red. Es más probable que la causa esté en el DNS, TLS, las cabeceras del proxy, la autenticación, el firewall, el almacenamiento o la propia aplicación. Conserva la solicitud y los registros del fallo, vuelve a la topología sencilla conocida y funcional, y diagnostica el siguiente límite.