La connexion à Immich échoue après le redémarrage du proxy inverse

Si la connexion à Immich échoue uniquement après le redémarrage du proxy inverse, commencez par vérifier si le chemin via le proxy est en cause alors que l’application Immich et le compte fonctionnent toujours directement.

Un redémarrage peut révéler des adresses de serveur en amont obsolètes, l’absence d’appartenance à un réseau partagé, des modifications d’en-têtes, un comportement différent des cookies ou un processus proxy relancé avant que ses dépendances ne soient accessibles. Testez le même compte via le point de terminaison Immich local et le nom d’hôte public habituel, puis suivez la première couche où les deux chemins divergent.

Utilisez l’accès direct pour distinguer un problème d’authentification d’une défaillance du proxy

Testez un compte connu sur le serveur Immich via une route locale de confiance qui contourne le proxy inverse. Si la connexion directe réussit tandis que le nom d’hôte public reste bloqué, redirige ou renvoie une erreur du serveur en amont, l’enregistrement utilisateur et le chemin d’authentification principal sont probablement intacts. Concentrez alors l’enquête sur le proxy, TLS, le routage et l’état du navigateur.

Un cas décrit par la communauté, où l’accès direct fonctionnait tandis que la connexion via le proxy échouait, illustre cette méthode d’isolement. Le rapport concerne une version précise : utilisez-le pour justifier la comparaison des chemins, sans supposer la même cause première.

Si les connexions directe et via le proxy échouent toutes deux, cessez de modifier les paramètres du proxy. Vérifiez plutôt l’état du service Immich, la connectivité à la base de données, l’état du compte et les journaux du serveur. Le redémarrage du proxy survenu à proximité de la panne peut être une coïncidence ; le test de contournement évite de transformer ce simple rapprochement temporel en diagnostic infondé.

Vérifiez que le proxy peut joindre le serveur Immich en amont actuel

Après le redémarrage du proxy, confirmez qu’il peut résoudre le serveur Immich en amont et s’y connecter depuis son propre espace réseau. Avec Docker, un serveur en amont défini par le nom du service sur un réseau utilisateur partagé est généralement plus stable qu’une adresse IP de conteneur copiée manuellement, qui change lorsqu’un conteneur est recréé.

Une discussion sur une panne de proxy inverse concernant la connectivité entre le proxy et Immich montre pourquoi il faut vérifier l’accessibilité du serveur en amont et la prise en charge de WebSocket par le proxy avant de récupérer un compte. Considérez la configuration exacte comme un élément anecdotique, et non comme un modèle applicable à tous les proxys.

Redémarrez le proxy seul deux fois et vérifiez si son serveur en amont est résolu vers le même service à chaque fois. Le test est concluant si la connexion réussit immédiatement sans modifier les adresses. Si la résolution de nom, l’appartenance au réseau ou le port cible change après la recréation, corrigez la définition du réseau Compose au lieu de redémarrer la pile à répétition.

Examinez les en-têtes transférés, TLS et le comportement des cookies

La connexion peut échouer même si le proxy renvoie la page Immich, car l’authentification dépend de l’intégralité du chemin HTTP. Comparez la configuration du proxy avant et après le redémarrage, notamment la transmission de l’hôte et du schéma, la terminaison HTTPS, les redirections, toute réécriture de cookies et l’éventuelle modification de la réponse par un second proxy ou un tunnel.

Une discussion de la communauté Immich décrit un cas de cookies en double lors de la connexion, où la gestion des cookies par le proxy provoquait un blocage de la connexion. Il s’agit d’un cas limité, mais il rappelle qu’il faut inspecter la réponse du navigateur et les cookies au lieu de supposer que des identifiants valides garantissent une session via le proxy.

Ne supprimez pas tous les comptes et ne réinitialisez pas la base de données parce qu’une session du navigateur semble bloquée. Utilisez une fenêtre privée ou un autre navigateur après avoir enregistré les cookies et la réponse d’origine. Si un client vierge fonctionne, effacez uniquement les données du site concerné et corrigez la règle du proxy qui a créé le mauvais cookie ou la mauvaise redirection.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Lisez les journaux d’accès et d’erreur du proxy à l’heure exacte de la requête en échec

Reproduisez une tentative de connexion et notez l’heure exacte, le nom d’hôte public, le client et le code d’état renvoyé. Inspectez ensuite les journaux d’accès et d’erreur du proxy autour de cette requête. Distinguez une requête qui n’a jamais atteint le proxy, une erreur 4xx ou 5xx générée par le proxy, une défaillance de connexion au serveur en amont et une requête qui a atteint Immich mais a reçu une réponse de l’application.

Le processus de dépannage des journaux NGINX montre comment le code d’état, les erreurs du serveur en amont, le temps de traitement des requêtes et une journalisation ciblée fournissent un signal bien plus fiable que le rafraîchissement répété de la page de connexion. Appliquez le même principe à Caddy, Traefik ou à un autre proxy.

Si le journal du proxy indique une réponse réussie du serveur en amont alors que le navigateur n’achève pas la connexion, inspectez les redirections, les cookies, TLS et l’état du client. Si le proxy ne peut pas se connecter au serveur en amont, corrigez le routage ou la disponibilité du service. Si Immich renvoie lui-même l’erreur, consultez le journal du serveur correspondant au lieu d’attribuer la cause au proxy.

Vérifiez que la correction résiste au redémarrage à l’origine de la panne

Après avoir corrigé la cause confirmée, reproduisez exactement le déclencheur : redémarrez uniquement le proxy inverse, attendez son contrôle d’état, puis connectez-vous via le nom d’hôte public. Ouvrez ensuite un élément existant, téléversez un petit fichier et laissez la session active suffisamment longtemps pour vérifier le fonctionnement normal des requêtes API.

Le guide ZimaSpace consacré aux chemins d’accès distant contrôlés définit le cadre général : le proxy n’est qu’une couche de l’accès distant ; le DNS, TLS, l’authentification et le serveur privé en amont doivent donc rester intentionnels et observables.

Considérez le test comme réussi uniquement si la connexion fonctionne après deux redémarrages du proxy et si la même configuration démarre correctement après un redémarrage complet de la pile. Annulez les dernières modifications du proxy si une nouvelle règle d’en-tête ou de cookie a créé la panne. Pour obtenir de l’aide, fournissez la différence de configuration du proxy, le code d’état de la requête, l’erreur du serveur en amont, l’heure indiquée dans le journal du serveur et le résultat du test direct par rapport au test via le proxy.