Redes de Immich: cómo el descubrimiento, el DNS y el enrutamiento permiten la accesibilidad
Los resultados de accesibilidad de Immich provienen de una cadena ordenada: selección del endpoint, resolución DNS, enrutamiento de paquetes, reenvío mediante proxy o NAT y respuesta de la aplicación.
Un teléfono puede acceder a Immich mediante la IP local mientras el mismo nombre de host falla en Wi‑Fi, o funcionar de forma remota mientras recorre una ruta más larga en casa. Estos resultados se producen por decisiones distintas de nombres y rutas, no por un único estado universal de «red activa».
La accesibilidad comienza con el endpoint que elige el cliente
Un cliente no puede enrutar hacia «Immich» como un servicio abstracto; utiliza un esquema, un nombre de host o una dirección, un puerto y, en ocasiones, una ruta. Las aplicaciones nativas, los navegadores, los marcadores y los enlaces compartidos pueden almacenar endpoints diferentes. Su accesibilidad puede divergir antes de que ningún paquete llegue al servidor.
Un hilo de la comunidad sobre la exposición de Immich de forma local y remota describe dificultades cuando un router no puede ofrecer un comportamiento de DNS dividido y el cliente carece de un cambio automático al endpoint local. El caso muestra que la selección del endpoint y las capacidades del DNS local determinan conjuntamente qué ruta intenta seguir un cliente doméstico.
Escribe la URL exacta que utiliza cada cliente e indica si se introdujo manualmente, se descubrió mediante un enlace o se guardó anteriormente. Compara el esquema, el host, el puerto y la ruta. No reduzcas una IP local funcional y un nombre de host público fallido a un único resultado; son contratos de destino diferentes.
El DNS selecciona una dirección, no un servicio funcional
El DNS convierte el nombre de host seleccionado en una dirección. Los resolutores públicos y locales pueden devolver respuestas distintas intencionadamente, mientras que las cachés obsoletas pueden conservar la dirección antigua del router o del servidor. Una respuesta correcta solo identifica un destino; no demuestra que el puerto, el proxy, el certificado o la aplicación estén disponibles allí.
Un caso de la comunidad de Caddy describe cómo Immich funciona mediante la IP local, mientras que una ruta local basada en DuckDNS falla y plantea dudas sobre el NAT hairpin. Los detalles dependen del entorno, pero demuestran que la resolución de nombres y las rutas de retorno del router pueden diferir incluso en la misma red doméstica.
Consulta el nombre de host desde la red del teléfono o navegador afectado y compáralo con la dirección local o pública esperada. Repite la prueba usando datos móviles. Si las respuestas difieren intencionadamente, documenta el DNS dividido. Si difieren de forma inesperada, corrige el registro autoritativo o la caché antes de modificar los contenedores de Immich.
El enrutamiento, el NAT y los proxies completan la cadena de entrega
Después del DNS, el cliente necesita una ruta. El tráfico remoto puede atravesar un proveedor de Internet, un router, un reenvío de puertos, un túnel o un proxy inverso; el tráfico local puede ir directamente o recorrer el perímetro público. Cada capa debe entregar el puerto correcto y conservar el contexto de la solicitud que espera la aplicación.
El artículo de ZimaSpace sobre la ruta de datos de Immich separa las dependencias del cliente, la red, la aplicación, la base de datos y los medios. Este modelo por capas evita un error común: reiniciar Immich cuando la aplicación ya responde localmente y la primera dependencia defectuosa está fuera del contenedor.
Sigue la ruta en orden: dirección, ruta, puerto de escucha, destino del proxy, nombre TLS y respuesta de la aplicación. Un ping correcto no es suficiente, porque el puerto web o de la API puede seguir bloqueado. Del mismo modo, una página de destino del proxy no demuestra que las solicitudes lleguen al servicio de Immich.
Usa un rastreo de accesibilidad por capas
Crea dos columnas para la red Wi‑Fi doméstica y los datos móviles. En cada una, registra la URL seleccionada, la respuesta DNS, la ruta o puerta de enlace, la conexión TCP, el resultado TLS, el estado HTTP y una respuesta autenticada de la API de Immich. Usa la misma cuenta y el mismo recurso para que la identidad o los permisos no alteren la comparación de red.
Una guía de Immich para servidores domésticos muestra el enrutamiento DNS como requisito previo a los pasos de acceso mediante certificado y aplicación. Su secuencia respalda la regla de diagnóstico: las capas posteriores no pueden compensar una asignación incorrecta entre nombre y dirección, mientras que un DNS correcto por sí solo no puede validar el reenvío ni el estado de la aplicación.
Detente en la primera capa cuyo valor observado difiera de la ruta esperada. Corrige únicamente esa capa y repite ambas columnas, porque una solución remota puede romper el comportamiento de NAT hairpin local. La accesibilidad se confirma cuando ambas rutas previstas completan la misma solicitud de aplicación, no simplemente cuando se resuelve un nombre de host.
Productos recomendados
Centro de Tecnología e IA
Más para leer
¿Por qué Immich vuelve a procesar los datos existentes después de una actualización?
Immich puede reprocesar los archivos cuando una actualización invalida derivados, metadatos, modelos o el estado de los trabajos anteriores; el procesamiento interminable y repetido...
¿Qué dependencias suelen limitar realmente el rendimiento de Immich?
Immich está limitado por la dependencia más lenta de cada ruta medida, por lo que la carga, la búsqueda, la navegación y la reproducción...
Immich para familias: cómo la identidad y los permisos determinan la experiencia
El uso familiar de Immich depende de identidades separadas, propiedad de los recursos, uso compartido intencional, administración limitada y revocación comprobada.
