Immich fonctionne-t-il de manière fiable derrière un CGNAT ou un double NAT ?

Oui, Immich peut fonctionner de manière fiable derrière un CGNAT ou un double NAT, car ces couches réseau influencent principalement la façon dont les clients distants accèdent au serveur, plutôt que le traitement local effectué par Immich.

La difficulté apparaît lorsqu’une famille s’attend à ce que des connexions IPv4 entrantes non sollicitées atteignent un serveur domestique qui ne contrôle pas la traduction d’adresses externe. Le double NAT peut néanmoins rester gérable lorsque les deux routeurs sont sous votre contrôle ; avec un CGNAT, la traduction externe est généralement effectuée par le FAI. Une simple redirection de port sur le routeur domestique ne peut donc pas créer le même chemin public direct.

Le fonctionnement local d’Immich ne dépend pas de l’accessibilité publique

Les téléphones et les navigateurs connectés au même réseau domestique peuvent accéder au serveur Immich via une adresse privée, sans aucune redirection de port publique. Les téléversements, la navigation, les opérations sur la base de données, la génération des miniatures et l’apprentissage automatique local peuvent donc continuer à fonctionner correctement, même lorsque le FAI n’attribue au foyer aucune adresse IPv4 publique directement accessible.

Cette distinction apparaît dans les questions de la communauté concernant Immich derrière un CGNAT : les utilisateurs signalent souvent un déploiement local fonctionnel et ne rencontrent la limitation qu’en ajoutant un accès distant. Le CGNAT constitue donc une contrainte d’accessibilité, et non un problème de stockage ou de fonctionnement de l’application.

Si Immich ne fonctionne pas non plus sur le réseau local, le CGNAT n’est pas la première explication à envisager. Diagnostiquez d’abord le DNS local, le réseau des conteneurs, la disponibilité du serveur, le stockage ou l’authentification avant de revoir la conception de l’accès public.

Le double NAT et le CGNAT créent des limites de contrôle différentes

Avec un double NAT au sein d’un réseau domestique, l’administrateur peut contrôler les deux couches de traduction — par exemple une passerelle du FAI et un routeur personnel. Il est parfois possible de créer une route entrante directe en configurant une redirection à travers les deux couches ou en modifiant la topologie. La question déterminante est de savoir si la correspondance externe est sous le contrôle du foyer.

L’article de Tailscale sur la traversée des NAT difficiles explique pourquoi les couches NAT multiples et les passerelles de qualité opérateur réduisent les chances d’établir des chemins directs de pair à pair. Plus les correspondances sont restrictives, plus un système de traversée a de chances de devoir utiliser un relais de secours.

Ne considérez pas toute adresse WAN semblant privée comme le même problème sans vérifier la topologie. L’IPv6, les options d’adresses publiques proposées par le FAI, le mode pont et les différentes architectures en amont peuvent modifier les chemins disponibles, même lorsque l’interface du routeur domestique semble similaire.

Les réseaux superposés peuvent rétablir l’accessibilité sans redirection de port

Un réseau privé superposé peut permettre au client distant et au serveur domestique d’initier tous deux des connexions sortantes, puis de tenter d’établir un chemin pair à pair chiffré. Lorsque la traversée directe réussit, les données peuvent circuler sans exposer le service Immich comme un port public classique sur le routeur domestique.

L’explication détaillée de la connectivité par réseau superposé décrit la traversée du NAT ainsi que le recours à un relais chiffré lorsque la création d’un chemin direct est impossible. C’est pourquoi un foyer utilisant Immich derrière un CGNAT peut tout de même bénéficier d’un accès distant, même si la redirection IPv4 entrante classique n’est pas disponible.

Le compromis repose sur la dépendance aux clients et aux identités : les appareils distants autorisés doivent avoir accès au réseau superposé, et le chemin peut différer de celui d’un proxy inverse public utilisé par des invités qui se connectent uniquement via un navigateur. La fiabilité doit donc tenir compte de la façon dont les membres de la famille se connectent réellement, et pas seulement du fonctionnement sur le téléphone d’un administrateur.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Le relais de secours préserve l’accès, mais peut modifier les performances

Un chemin relayé peut maintenir l’accessibilité du service lorsque le NAT difficile ou les règles du pare-feu empêchent une connectivité UDP directe. Cela résout le problème binaire de l’accès, mais le saut supplémentaire peut augmenter la latence ou réduire le débit, ce qui compte pour les téléversements de nombreuses photos et la navigation distante en haute résolution.

Un rapport de 2026 sur les performances des relais présente un cas où une route DERP longue distance ajoutait plusieurs centaines de millisecondes, jusqu’à la mise en place d’une meilleure architecture de relais. Considérez cette ampleur comme propre au chemin de cet auteur, tout en conservant le mécanisme général opposant les chemins directs aux chemins relayés.

C’est la limite de validité de la réponse simplifiée « Tailscale résout le CGNAT ». Tailscale peut rétablir la connectivité, mais ne garantit pas les mêmes performances qu’un réseau local direct ou qu’une connexion directe entre pairs. Vérifiez le chemin réellement utilisé avant d’attribuer les lenteurs d’Immich à l’application.

Vérifiez séparément l’accessibilité et le chemin réseau

Commencez par tester Immich localement avec la connexion WAN débranchée : le service devrait rester utilisable sur le réseau domestique. Testez ensuite la méthode d’accès distant choisie depuis le réseau mobile ou un autre réseau externe. Enfin, vérifiez si la connexion distante est directe ou relayée, puis comparez le téléversement, l’ouverture des miniatures et une recherche connue avec les résultats obtenus sur le réseau local.

La discussion de ZimaSpace sur le CGNAT et le double NAT applique le même principe de couche réseau à un autre service auto-hébergé : l’application peut rester fiable localement, tandis que le chemin d’accès distant nécessite une conception distincte.

Adoptez cette architecture lorsque l’utilisation locale reste possible après une coupure d’Internet, que l’authentification distante est intentionnelle et que la route distante répond aux objectifs du foyer en matière de latence et de débit. Si l’accès ne fonctionne qu’au moyen d’un relais anormalement lent, considérez cela comme un problème de qualité du chemin réseau, et non comme la preuve qu’Immich n’est pas fiable derrière un NAT.