Réseau Immich : comment la découverte, le DNS et le routage assurent l’accessibilité

Les résultats d’accessibilité d’Immich proviennent d’une chaîne ordonnée : sélection du point de terminaison, résolution DNS, routage des paquets, transfert par proxy ou NAT, puis réponse de l’application.

Un téléphone peut accéder à Immich via une adresse IP locale alors que le même nom d’hôte échoue en Wi-Fi, ou fonctionner à distance tout en empruntant un chemin plus long à domicile. Ces résultats sont produits par des décisions différentes concernant les noms et les routes, et non par un état universel unique du type « réseau opérationnel ».

L’accessibilité commence par le point de terminaison choisi par le client

Un client ne peut pas acheminer des requêtes vers « Immich » en tant que service abstrait ; il utilise un schéma, un nom d’hôte ou une adresse, un port et parfois un chemin. Les applications natives, les navigateurs, les favoris et les liens partagés peuvent enregistrer des points de terminaison différents. Leur accessibilité peut donc diverger avant même qu’un paquet n’atteigne le serveur.

Une discussion communautaire sur l’exposition d’Immich en local et à distance décrit les difficultés rencontrées lorsqu’un routeur ne peut pas fournir un comportement DNS à vue partagée et que le client ne dispose pas d’un basculement automatique vers un point de terminaison local. Ce cas montre que la sélection du point de terminaison et les capacités DNS locales déterminent conjointement le chemin qu’un client domestique tente d’emprunter.

Notez l’URL exacte utilisée par chaque client et indiquez si elle a été saisie, découverte via un lien ou enregistrée auparavant. Comparez le schéma, l’hôte, le port et le chemin. Ne réduisez pas une adresse IP locale fonctionnelle et un nom d’hôte public défaillant à un seul résultat ; il s’agit de contrats de destination différents.

Le DNS sélectionne une adresse, pas un service fonctionnel

Le DNS convertit le nom d’hôte sélectionné en adresse. Les résolveurs publics et locaux peuvent volontairement renvoyer des réponses différentes, tandis que des caches obsolètes peuvent conserver l’ancienne adresse d’un routeur ou d’un serveur. Une réponse correcte identifie uniquement une destination ; elle ne prouve pas que le port, le proxy, le certificat ou l’application y sont disponibles.

Un cas présenté dans la communauté Caddy décrit une instance d’Immich fonctionnant via une adresse IP locale alors qu’un chemin local fondé sur DuckDNS échoue et soulève des questions concernant le NAT loopback. Les détails dépendent de l’environnement, mais ils montrent que la résolution de noms et les chemins de retour du routeur peuvent différer, même sur le même réseau domestique.

Interrogez le nom d’hôte depuis le réseau du téléphone ou du navigateur concerné, puis comparez-le avec l’adresse locale ou publique attendue. Répétez l’opération sur le réseau mobile. Si les réponses diffèrent intentionnellement, documentez le DNS partagé. Si elles diffèrent de manière inattendue, corrigez l’enregistrement faisant autorité ou le cache avant de modifier les conteneurs Immich.

Le routage, le NAT et les proxys complètent la chaîne d’acheminement

Après le DNS, le client a besoin d’une route. Le trafic distant peut traverser un FAI, un routeur, une redirection de port, un tunnel ou un proxy inverse ; le trafic local peut passer directement ou repasser par le point d’accès public. Chaque couche doit acheminer le bon port et conserver le contexte de requête attendu par l’application.

L’article de ZimaSpace sur le chemin des données d’Immich distingue les dépendances du client, du réseau, de l’application, de la base de données et des fichiers multimédias. Ce modèle en couches évite une erreur fréquente : redémarrer Immich alors que l’application répond déjà localement et que la première dépendance défaillante se trouve à l’extérieur du conteneur.

Suivez le chemin dans l’ordre : adresse, route, port en écoute, cible du proxy, nom TLS et réponse de l’application. Un ping réussi ne suffit pas, car le port Web ou API peut rester bloqué. De même, une page d’accueil du proxy ne prouve pas que les requêtes atteignent le service Immich.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Utilisez une trace d’accessibilité par couches

Créez deux colonnes, l’une pour le Wi-Fi domestique et l’autre pour les données mobiles. Dans chacune, consignez l’URL sélectionnée, la réponse DNS, la route ou la passerelle, la connexion TCP, le résultat TLS, le statut HTTP et une réponse authentifiée d’une API Immich. Utilisez le même compte et le même fichier multimédia afin que l’identité ou les autorisations ne modifient pas la comparaison réseau.

Un guide Immich pour serveur domestique présente le routage DNS comme un prérequis avant les étapes d’accès par certificat et à l’application. Sa séquence confirme la règle de diagnostic suivante : les couches ultérieures ne peuvent pas compenser une mauvaise association entre nom et adresse, tandis qu’un DNS correct ne suffit pas à valider la redirection ou l’état de l’application.

Arrêtez-vous à la première couche dont la valeur observée diffère du chemin attendu. Corrigez uniquement cette couche, puis répétez les deux colonnes, car une correction à distance peut perturber le NAT loopback local. L’accessibilité est validée lorsque les deux chemins prévus exécutent la même requête d’application, et non lorsque le nom d’hôte se résout simplement.