Pourquoi Immich semble-t-il plus rapide sur un réseau local que via des connexions distantes ?
Immich semble généralement plus rapide sur le LAN, car les clients locaux empruntent un chemin plus court et à plus faible latence, avec moins de passerelles et sans que la connexion Internet domestique ne constitue un goulot d’étranglement.
L’accès à distance peut ajouter les limites d’envoi du FAI, les réseaux mobiles ou hôteliers, le DNS, la terminaison TLS, un proxy inverse, un VPN ou un réseau superposé, et parfois un relais. Ces ajouts ne ralentissent pas toutes les requêtes de la même manière : les miniatures, les requêtes de métadonnées, les téléchargements des originaux, les téléversements et les recherches sollicitent différentes parties du chemin. Comparez donc des actions identiques avant de conclure qu’« Immich à distance » correspond à un seul mode de performance.
Le LAN élimine la plupart des variations du chemin WAN
Sur un LAN filaire ou en Wi-Fi puissant, le client et le serveur ne sont généralement séparés que par quelques sauts locaux de commutation ou de routage. Le temps aller-retour est faible et le foyer contrôle la majeure partie du chemin ; les petits appels d’API et de nombreuses requêtes de miniatures peuvent donc s’exécuter avec peu d’attente réseau.
Le modèle direct ou relayé de la traversée NAT aide à expliquer ce contraste. Un client distant peut atteindre le même serveur par un tunnel WAN direct ou via un relais, tandis que le client LAN emprunte simplement le chemin local. Le point d’accès de l’application peut être identique, même lorsque les conditions de transport ne le sont pas.
Un LAN plus rapide ne prouve pas que le serveur reste performant avec toutes les charges de travail. La faible latence locale peut masquer des requêtes inefficaces ou un stockage lent, car l’attente réseau est réduite. Conservez les métriques du serveur dans la comparaison afin qu’un diagnostic du chemin distant n’excuse pas un goulot d’étranglement du backend qui affecte les deux chemins.
Le débit d’envoi domestique devient la capacité de téléchargement à distance
Lorsqu’une personne à l’extérieur du domicile ouvre des photos stockées sur un serveur domestique, le serveur envoie les données via le débit montant de la connexion Internet du foyer. De nombreuses connexions résidentielles disposent d’une capacité montante bien inférieure à celle d’un réseau Ethernet ou Wi-Fi local ; les originaux et les grands aperçus distants peuvent donc être limités par la bande passante, même lorsque la navigation sur le LAN est instantanée.
Une discussion communautaire sur l’accès familial à distance montre pourquoi les foyers évaluent plus que la simple connectivité : le chemin doit également être simple et fiable pour les utilisateurs non techniques. Les performances, l’authentification et l’expérience utilisateur font toutes partie du chemin distant réel.
La bande passante n’est pas la bonne explication lorsque de petites commandes de métadonnées, des filtres ou les opérations de connexion sont lentes, tandis que les transferts volumineux atteignent le débit attendu. Ce schéma indique plus probablement un problème de latence, de routage des requêtes, de comportement du proxy, de DNS ou de temps de réponse du serveur.
Les proxys et les tunnels ajoutent des limites de traitement et de configuration
Une requête distante peut terminer TLS sur un proxy, traverser un autre réseau de conteneurs ou passer par un réseau superposé chiffré avant d’atteindre Immich. Des couches correctement configurées peuvent ajouter peu de surcharge, mais chacune introduit un point où la mise en tampon, la gestion des en-têtes, la politique d’expiration, la sélection du chemin ou des problèmes de MTU peuvent affecter certaines requêtes.
Un rapport d’utilisateur Immich datant de 2026 sur les délais liés au filtrage distant a finalement identifié un problème de configuration du chemin de destination, après que les performances du relais eurent également été examinées. Cet exemple est utile, car deux mécanismes distincts produisaient des symptômes similaires d’« accès distant lent ».
Ne changez pas de technologie d’accès distant sur la base d’un seul chargement de page. Identifiez d’abord si l’opération défaillante est un transfert, une requête d’API, une authentification ou l’établissement d’une connexion. Un proxy inverse ne peut pas résoudre la saturation de la liaison montante domestique, et un tunnel plus rapide ne peut pas corriger une requête de base de données lente.
La mise en cache peut rendre les tests LAN et distants incomparables
Un téléphone connecté au LAN peut déjà avoir en cache des miniatures, l’état de session, des réponses DNS ou des ressources récemment consultées, tandis que le test distant peut commencer dans un état moins mis en cache. Comparer ces deux exécutions peut exagérer la différence réseau, car l’un des clients demande moins de données au serveur.
L’explication de ZimaSpace sur la latence du stockage souligne la nécessité de contrôler l’état du cache et de la charge de travail lors de la comparaison des performances. La même rigueur s’applique aux tests de routage : utilisez si possible le même compte, le même ensemble de ressources, le même client et les mêmes conditions de cache.
Le mécanisme LAN-versus-WAN cesse d’expliquer une différence qui subsiste lorsque les deux tests sont forcés d’emprunter le même chemin ou lorsque le temps de réponse côté serveur augmente lui-même de manière identique. À ce stade, examinez l’application ou l’hôte plutôt que de continuer à optimiser la topologie réseau.
Construisez une comparaison des chemins fondée sur les mêmes actions
Choisissez quatre actions : charger le même album, ouvrir la même grande photo, exécuter la même recherche connue et téléverser le même fichier de test. Relevez le temps observé côté client, le temps de traitement de la requête côté serveur lorsqu’il est disponible, la latence aller-retour, le débit de transfert et indiquez si le chemin distant est direct, via un proxy ou relayé.
Comparez les exécutions sur le LAN et à distance à partir d’un état de cache connu, puis ne modifiez qu’une seule variable de chemin à la fois. La discussion de Tailscale sur les connexions directes et relayées fournit un modèle utile de classification des chemins. Si seuls les transferts volumineux s’améliorent, la bande passante constitue probablement la limite principale.
Validez le diagnostic lorsque le changement de chemin améliore l’opération prévue par le mécanisme, sans modifier la charge de travail du serveur. Conservez la conception distante la plus simple qui réponde aux objectifs d’accès et de performance de la famille ; les couches supplémentaires de proxy, de tunnel ou de relais doivent répondre à une raison claire d’accessibilité ou de sécurité.
Produits recommandés
Centre Tech & IA
Plus à lire
Les modèles ouverts rattrapent l’IA de pointe : 2026 sera-t-elle l’année où l’IA locale deviendra suffisamment performante ?
Les modèles ouverts deviennent suffisamment performants pour davantage de charges de travail d’IA locales, tandis que les modèles cloud de pointe restent utiles pour...
NVIDIA PAIR transforme votre réseau domestique en cluster d’IA local : avez-vous toujours besoin d’un gros serveur équipé d’un GPU ?
NVIDIA PAIR répartit les requêtes d’IA locales sur plusieurs PC, rendant les capacités de calcul plus flexibles, tandis qu’un seul serveur domestique peut conserver...
Immich fonctionne-t-il de manière fiable derrière un CGNAT ou un double NAT ?
Le CGNAT et le double NAT ne perturbent pas l’utilisation locale d’Immich. Ils compliquent principalement l’accès distant entrant direct et peuvent imposer des chemins...
