Immich s’ouvre en local, mais échoue à distance après un changement de routeur

Si Immich s’ouvre toujours sur votre Wi‑Fi domestique après un changement de routeur, mais échoue via les données mobiles, le serveur est probablement sain et c’est la couche modifiée du chemin distant qui est en cause.

Le remplacement ou la réinitialisation d’un routeur peut modifier l’adresse LAN du serveur, effacer les règles de redirection de ports, obtenir une autre adresse IP publique, modifier le comportement du DNS ou placer la connexion derrière un autre mode NAT. Commencez par un véritable test depuis un réseau extérieur et progressez depuis le serveur vers l’extérieur. Ne modifiez qu’une seule couche à la fois : ouvrir des ports supplémentaires avant de savoir quel maillon a échoué peut accroître l’exposition sans rétablir l’accès.

Prouvez que la panne est limitée à l’accès distant

Commencez par tester Immich depuis un appareil connecté au même réseau LAN, en utilisant l’adresse locale actuelle du serveur. Désactivez ensuite le Wi‑Fi sur un téléphone et répétez le test distant via le réseau mobile. Si l’accès local échoue également, cessez de considérer cela comme un problème situé à la périphérie du routeur et réparez d’abord le serveur ou le réseau local.

Si l’accès local fonctionne mais que l’accès distant échoue, notez le nom d’hôte distant exact, le protocole et l’erreur affichée. Un délai d’attente expiré indique un problème différent d’un avertissement de certificat ou d’une page d’erreur du proxy. Notez également si vous utilisez une redirection de port directe, un proxy inverse, un VPN maillé ou un tunnel, car le remplacement du routeur affecte différemment chacun de ces modèles.

N’utilisez pas le même Wi‑Fi domestique comme seul test distant. Certains routeurs gèrent les requêtes internes vers le nom d’hôte public via le NAT loopback, d’autres non : un test sur le LAN peut donc produire un faux échec ou une fausse réussite. À la fin de cette étape, vous devez disposer d’un symptôme clair : Immich fonctionne en local, tandis qu’un chemin externe défini échoue.

Vérifiez que le routeur envoie toujours le trafic vers la même cible LAN

Un nouveau routeur attribue souvent une autre adresse IP privée à l’hôte Immich. Comparez l’adresse LAN actuelle du serveur avec la cible enregistrée dans toute redirection de port, tout serveur mandataire inverse, tout objet de pare-feu ou toute réservation DHCP. Si la règle pointe toujours vers l’ancienne adresse, corrigez cette association avant de modifier Immich.

Recréez uniquement la règle entrante réellement nécessaire au modèle d’accès choisi. Vérifiez ensemble le port externe, la cible interne, le port interne et le protocole. Si vous utilisez un proxy inverse, le routeur redirige normalement vers le proxy plutôt que directement vers Immich ; rediriger vers les deux peut créer un second chemin public inutile.

Après avoir corrigé la cible, effectuez à nouveau le test via le réseau mobile et vérifiez dans les journaux du proxy ou du serveur si la requête est visible. Si les journaux restent complètement silencieux, le trafic est toujours bloqué avant l’application. Si la requête atteint désormais le proxy ou l’hôte, mais renvoie une erreur d’application, la périphérie du routeur est probablement corrigée et la section suivante doit se concentrer sur l’adressage public ou la résolution de noms.

Comparez l’adresse IP publique, l’enregistrement DNS et le mode NAT

Le remplacement du routeur peut coïncider avec l’attribution d’un nouveau bail WAN. Résolvez le nom d’hôte que vous utilisez pour Immich et comparez le résultat avec l’adresse IP publique actuellement attribuée à votre connexion domestique. Si elles diffèrent, le nom d’hôte dirige les clients vers l’ancien point d’accès, même si tous les services locaux sont sains.

Le DNS dynamique maintient un nom d’hôte aligné sur une adresse publique changeante. Si le nom d’hôte se résout toujours vers l’ancienne adresse WAN, les clients externes continuent d’atteindre la mauvaise destination jusqu’à la mise à jour de l’enregistrement et des caches concernés. Consultez le fonctionnement du DNS dynamique pour suivre les changements d’adresse IP, corrigez le programme ou l’enregistrement de mise à jour, puis testez à nouveau depuis un résolveur externe et via les données mobiles.

Si l’adresse WAN du routeur ne correspond pas à l’adresse publique observée depuis Internet, la nouvelle connexion peut être placée derrière un NAT de niveau opérateur ou une autre couche NAT en amont. Avec un NAT entre les pairs et l’Internet public, modifier la redirection de port du routeur domestique peut ne jamais rendre le service accessible. Dans ce cas, utilisez une adresse publique, un chemin VPN ou réseau superposé, ou une autre méthode d’accès qui ne dépend pas d’une redirection entrante non sollicitée.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Vérifiez l’état du proxy inverse, du TLS et du pare-feu après le changement de réseau

Si le trafic externe atteint l’hôte, mais qu’Immich ne s’ouvre toujours pas, vérifiez les couches d’identité que le routeur ne gère pas. Confirmez que le proxy inverse pointe toujours vers l’adresse et le port actuels d’Immich, que le nom d’hôte correspond à la route du proxy et que le pare-feu du serveur autorise le chemin prévu depuis le nouveau sous-réseau LAN.

Un domaine qui atteint le mauvais site du proxy, boucle dans des redirections ou affiche une erreur de nom de certificat n’est plus un simple problème de redirection de port. Gardez séparés le chemin IP fonctionnel et le chemin par nom d’hôte défaillant pendant que vous examinez le DNS, le SNI, le routage Host et toute URL publique configurée. Ne régénérez pas les certificats à l’aveugle si le nom d’hôte se résout toujours vers la mauvaise adresse publique.

Pour un arbre de décision plus large, distinguez l’accessibilité locale des défaillances du chemin public avant de répéter les corrections côté serveur. Une fois qu’Immich est confirmé comme fonctionnel en local, un changement de routeur limite l’enquête à l’adressage, au NAT, au DNS, au pare-feu, au proxy et à l’état du TLS.

Retestez depuis l’extérieur et choisissez le chemin d’accès sûr le plus simple

Une fois une cause corrigée, répétez le test initial via les données mobiles en utilisant le même nom d’hôte et le même client. Redémarrez ensuite une fois le routeur et une fois l’hôte Immich. La correction n’est durable que si le serveur conserve la cible LAN attendue, si le DNS continue de se résoudre correctement et si l’accès distant revient sans intervention manuelle.

Si vous dépendez d’une exposition entrante directe, vérifiez que seul le chemin HTTPS prévu est public et que les anciennes règles temporaires ont été supprimées. Pour un accès réservé à la famille, un VPN maillé ou un tunnel authentifié peut réduire la dépendance aux redirections de ports et aux adresses publiques changeantes, en particulier lorsque le nouveau routeur ou le chemin du FAI est difficile à contrôler.

Arrêtez de multiplier les modifications réseau lorsque les requêtes atteignent de manière fiable le bon proxy ou le bon point d’accès Immich et que le client d’origine fonctionne à nouveau. Si l’accès local reste sain, mais qu’aucun paquet externe n’atteint jamais votre routeur malgré un chemin public et un DNS corrects, contactez le FAI ou changez de modèle d’accès ; il s’agit d’un problème à la frontière du réseau, pas d’une raison de reconstruire Immich.