Comment vérifier si le DNS est à l’origine des échecs de connexion à Immich

Le DNS est probablement en cause avec Immich uniquement lorsque le client qui échoue ne peut pas convertir le nom d’hôte Immich exact en l’adresse qui doit le desservir, ou lorsque cette réponse varie selon les résolveurs, les réseaux ou le moment.

Testez séparément la résolution du nom et l’accessibilité de l’application. Une connexion IP réussie peut montrer qu’une route et un port existent, mais elle ne prouve pas que HTTPS, le routage du proxy inverse, les certificats ou les règles basées sur l’hôte fonctionneront sans le nom d’hôte. La méthode la plus sûre consiste à noter le nom défaillant exact, à l’interroger depuis le client concerné, à comparer les résolveurs, puis à répéter l’action Immich d’origine après une seule modification de la couche DNS.

Définir le nom d’hôte exact et le chemin de défaillance

Notez le nom d’hôte réellement utilisé par le client Immich défaillant, le réseau auquel il est connecté, l’heure de l’échec et indiquez si le problème concerne l’application web, l’application mobile ou les deux. Ne commencez pas par un test générique, comme la résolution d’un domaine public sans rapport, car cela prouve seulement qu’un chemin DNS fonctionne.

Comparez le même nom d’hôte depuis un client fonctionnel et depuis le client défaillant. Notez chaque réponse A et AAAA, le résolveur qui a répondu et précisez si le client se trouve sur le réseau domestique, sur le réseau mobile ou derrière un VPN. Des réponses différentes peuvent être intentionnelles avec un DNS fractionné, mais elles doivent tout de même diriger chaque client vers un point de terminaison accessible.

À titre de contrôle, vérifiez que l’adresse et le port du serveur attendus sont accessibles sans dépendre de la résolution DNS habituelle. Considérez uniquement ce test comme un moyen de distinguer les chemins réseau : les certificats HTTPS, le SNI, les proxys inverses et les hôtes virtuels peuvent toujours refuser une requête basée sur une adresse IP, même lorsque le service fonctionne correctement.

Interroger le DNS depuis le client défaillant, pas seulement depuis le serveur

Exécutez une requête DNS sur l’appareil ou dans l’environnement qui rencontre réellement le problème. Si le client Immich se trouve derrière un VPN, un profil DNS privé, un relais local de conteneur ou un résolveur fourni par le routeur, une requête effectuée depuis le serveur peut utiliser un chemin de résolution différent et masquer le problème.

Interrogez d’abord le nom d’hôte défaillant via le résolveur par défaut du client, puis interrogez explicitement un résolveur de comparaison connu ou le résolveur interne prévu. Une requête dig ciblée affiche la réponse renvoyée, le serveur ayant répondu, le statut et le temps de requête, afin de voir si l’échec dépend d’un résolveur particulier.

Répétez la requête plusieurs fois au lieu de vous fier à une seule réussite. Notez les réponses NXDOMAIN, SERVFAIL, les délais d’attente, les adresses obsolètes ou les réponses A/AAAA incohérentes. Une réponse correcte et stable éloigne les soupçons d’un problème élémentaire de résolution DNS et les oriente vers le routage, le proxy, TLS, le pare-feu ou la configuration de l’application.

Comparer les résultats des résolveurs et les types d’erreur

Interprétez le code de réponse avant de modifier les paramètres. NXDOMAIN signifie que le nom interrogé n’existe pas du point de vue de ce résolveur ; SERVFAIL signifie que la résolution n’a pas pu aboutir ; un délai d’attente signifie que le résolveur n’a pas répondu à temps. Une réponse syntaxiquement valide peut tout de même être incorrecte si elle pointe vers l’ancienne adresse du routeur ou vers un point de terminaison inaccessible.

Les échecs de type « nom introuvable » et les échecs temporaires du résolveur correspondent à deux branches différentes. Utilisez les différences entre les erreurs de résolution de noms pour déterminer s’il faut corriger un enregistrement manquant, un résolveur inaccessible ou un chemin DNS instable, plutôt que de traiter chaque échec de recherche comme un même problème.

Si seul le résolveur domestique renvoie l’ancienne adresse ou une adresse incorrecte tandis qu’un autre résolveur renvoie la valeur publique attendue, examinez les remplacements locaux, les enregistrements DNS fractionnés, le DNS fourni par DHCP, les services de filtrage et les caches. Si tous les résolveurs renvoient la même adresse correcte, cessez de modifier le DNS et passez au chemin du service.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Utiliser un contournement contrôlé pour confirmer ou écarter le DNS

Créez un contrôle temporaire et réversible qui ne modifie que la résolution des noms pour le client défaillant. Par exemple, interrogez directement un autre résolveur ou utilisez temporairement une entrée dans le fichier hosts associant le nom d’hôte Immich exact au point de terminaison connu et attendu. Conservez les paramètres d’origine afin de pouvoir annuler immédiatement le test.

Si le flux de travail Immich d’origine recommence à fonctionner alors que le nom d’hôte reste identique et que seul son chemin de résolution a changé, le DNS est fortement suspecté. Si le même nom d’hôte échoue toujours après avoir été résolu vers le point de terminaison vérifié, le problème se situe en aval du DNS : examinez le routage du proxy, les certificats, le NAT, les règles du pare-feu ou le service Immich lui-même.

Si une seule requête propre ne permet pas de reproduire la défaillance domestique, comparez au fil du temps l’état de l’hôte, du conteneur, du résolveur local, du résolveur en amont, du DHCP, du VPN et des caches. Une vérification DNS multicouche aide à détecter les problèmes intermittents qui disparaissent lors d’un test ponctuel.

Vider le cache approprié et retester le flux de travail Immich d’origine

Après avoir corrigé un enregistrement DNS, un résolveur, une option DHCP, une règle DNS fractionnée ou un remplacement local, videz si possible uniquement le cache concerné du client ou du résolveur. Ne videz pas répétitivement toutes les couches sans noter ce qui a changé, car cela peut rendre impossible l’explication d’une réussite temporaire.

Résolvez de nouveau le nom d’hôte depuis le client concerné et vérifiez la réponse A/AAAA attendue, le résolveur et le temps de réponse. Ouvrez ensuite Immich avec son nom d’hôte habituel, chargez d’anciens éléments, effectuez une recherche et réalisez un envoi sécurisé ou une autre action d’écriture afin que le test couvre autre chose qu’une simple page de connexion.

Répétez la vérification depuis l’état du réseau qui provoquait initialement l’échec, par exemple via les données mobiles, le Wi-Fi domestique, un Wi-Fi connecté à un VPN ou après le renouvellement du routeur ou du DHCP. Le DNS n’est écarté comme cause racine que lorsque le nom d’hôte habituel reste correct malgré le déclencheur qui provoquait auparavant la panne ; dans le cas contraire, conservez les nouveaux éléments et poursuivez l’analyse à la couche réseau suivante.