Cómo comprobar si el DNS está causando fallos de conexión de Immich

DNS es un posible culpable de Immich únicamente cuando el cliente que falla no puede convertir el nombre de host exacto de Immich en la dirección que debería atenderlo, o cuando esa respuesta cambia según los resolutores, las redes o el momento.

Prueba la resolución de nombres por separado de la accesibilidad de la aplicación. Una conexión exitosa a nivel de IP puede demostrar que existen una ruta y un puerto, pero no garantiza que HTTPS, el enrutamiento del proxy inverso, los certificados o las reglas basadas en el host funcionen sin el nombre de host. El procedimiento más seguro registra el nombre exacto que falla, lo consulta desde el cliente afectado, compara los resolutores y después repite la acción original de Immich tras realizar un cambio en la capa DNS.

Define el nombre de host exacto y la ruta del fallo

Registra el nombre de host que realmente usa el cliente de Immich que falla, la red en la que se encuentra, la hora del fallo y si el problema afecta a la aplicación web, a la aplicación móvil o a ambas. No empieces con una prueba genérica, como resolver un dominio público no relacionado, porque eso solo demuestra que alguna ruta DNS funciona.

Compara el mismo nombre de host desde un cliente que funcione y desde el cliente que falla. Registra todas las respuestas A y AAAA, el resolutor que respondió y si el cliente está dentro de la red doméstica, usando datos móviles o detrás de una VPN. Las respuestas diferentes pueden ser intencionadas con DNS dividido, pero aun así deben dirigir a cada cliente a un punto de conexión accesible.

Como control, comprueba si la dirección y el puerto esperados del servidor son accesibles sin depender de la consulta DNS normal. Trátalo únicamente como un método para distinguir la ruta de red: los certificados HTTPS, SNI, los proxies inversos y los hosts virtuales aún pueden rechazar una solicitud basada en IP aunque el servicio funcione correctamente.

Consulta el DNS desde el cliente que falla, no solo desde el servidor

Ejecuta una consulta DNS en el dispositivo o entorno que realmente está fallando. Si el cliente de Immich está detrás de una VPN, un perfil de DNS privado, un stub de contenedor o un resolutor proporcionado por el router, una consulta desde el propio servidor puede utilizar una ruta de resolución diferente y ocultar el problema.

Consulta primero el nombre de host que falla mediante el resolutor predeterminado del cliente y, después, consulta explícitamente un resolutor de comparación conocido o el resolutor interno previsto. Una consulta dirigida con dig muestra la respuesta devuelta, el servidor que respondió, el estado y el tiempo de consulta, para que puedas comprobar si el fallo depende de un resolutor.

Repite la consulta varias veces en lugar de confiar en un único resultado correcto. Registra los casos NXDOMAIN, SERVFAIL, los tiempos de espera, las direcciones obsoletas o las respuestas A/AAAA incoherentes. Una respuesta correcta y estable aleja las sospechas de la resolución DNS básica y las dirige hacia el enrutamiento, el proxy, TLS, el firewall o la configuración de la aplicación.

Compara los resultados de los resolutores y los tipos de error

Interpreta el código de respuesta antes de cambiar la configuración. NXDOMAIN significa que el nombre consultado no existe desde el punto de vista de ese resolutor; SERVFAIL significa que no se pudo completar la resolución; un tiempo de espera significa que el resolutor no respondió a tiempo. Una respuesta válida desde el punto de vista sintáctico también puede ser incorrecta si apunta a la dirección antigua del router o a un punto de conexión inaccesible.

Los fallos de nombre no encontrado y los fallos temporales del resolutor son ramas diferentes. Usa las diferencias entre errores de resolución de nombres para decidir si debes corregir un registro ausente, un resolutor inaccesible o una ruta DNS inestable, en lugar de tratar todos los fallos de consulta como si fueran el mismo problema.

Si solo el resolutor doméstico devuelve la dirección antigua o incorrecta mientras que otro resolutor devuelve el valor público previsto, revisa las anulaciones locales, los registros de DNS dividido, el DNS proporcionado por DHCP, los servicios de filtrado y las cachés. Si todos los resolutores devuelven la misma dirección correcta, deja de cambiar el DNS y pasa a revisar la ruta del servicio.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Usa una omisión controlada para confirmar o descartar el DNS

Crea un control temporal y reversible que cambie únicamente la resolución de nombres del cliente afectado. Por ejemplo, consulta directamente otro resolutor o utiliza temporalmente una entrada en el archivo hosts que asigne el nombre de host exacto de Immich al punto de conexión conocido y previsto. Conserva la configuración original para poder deshacer la prueba de inmediato.

Si el flujo de trabajo original de Immich empieza a funcionar mientras el nombre de host permanece idéntico y solo cambia su ruta de resolución, el DNS queda fuertemente implicado. Si el mismo nombre de host sigue fallando después de resolverse hacia el punto de conexión verificado, el problema está después del DNS y debes revisar el enrutamiento del proxy, los certificados, NAT, las reglas del firewall o el propio servicio de Immich.

Si una sola consulta correcta no reproduce el intervalo en el que falla el hogar, compara con el tiempo el estado del host, el contenedor, el resolutor local, el resolutor ascendente, DHCP, la VPN y la caché. Una comprobación de fallos DNS en varias capas ayuda a detectar casos intermitentes que desaparecen durante una prueba puntual.

Borra la caché correcta y vuelve a probar el flujo de trabajo original de Immich

Después de corregir un registro DNS, un resolutor, una opción DHCP, una regla de DNS dividido o una anulación local, borra únicamente la caché pertinente del cliente o del resolutor cuando sea práctico. No vacíes repetidamente todas las capas sin registrar qué cambió, porque eso puede hacer imposible explicar un éxito transitorio.

Vuelve a resolver el nombre de host desde el cliente afectado y verifica la respuesta A/AAAA prevista, el resolutor y el tiempo de respuesta. Después, abre Immich mediante su nombre de host normal, carga recursos antiguos, realiza una búsqueda y ejecuta una carga segura u otra acción de escritura para que la prueba abarque algo más que la página de inicio de sesión.

Repite la comprobación desde el estado de red que provocó originalmente el fallo, como los datos móviles, la Wi-Fi doméstica, la Wi-Fi conectada a una VPN o después de renovar el router o DHCP. El DNS queda descartado como causa raíz únicamente cuando el nombre de host normal sigue siendo correcto durante el evento que antes provocaba el fallo; de lo contrario, conserva las nuevas evidencias y continúa en la siguiente capa de red.