Pourquoi un proxy inverse renvoie-t-il une erreur 502 après la recréation d’un conteneur ?
Un proxy inverse renvoie une erreur 502 lorsqu’il ne peut plus établir de connexion valide avec le serveur en amont après la reconstruction d’un conteneur.
La reconstruction peut remplacer le conteneur, lui attribuer une nouvelle adresse, détacher ou renommer un réseau Docker, modifier le port exposé, restaurer une configuration incomplète ou démarrer le proxy avant que l’application soit prête. Le bon diagnostic commence par le journal d’erreurs du proxy et suit l’adresse exacte du serveur en amont, du proxy au conteneur, plutôt que de redémarrer les deux services jusqu’à ce que l’erreur disparaisse temporairement.
Vérifier que l’erreur 502 provient d’un échec de connexion au serveur en amont
Accédez une fois au domaine concerné et notez l’horodatage, le statut du proxy, l’adresse du serveur en amont et le message d’erreur complet. Distinguez une connexion refusée, un hôte introuvable, un délai d’attente dépassé, une réinitialisation de connexion, un échec de négociation TLS et une réponse non valide.
Une erreur 502 signifie que le proxy n’a reçu aucune réponse exploitable du serveur en amont, mais le détail de l’erreur permet de déterminer si la cible est absente, inaccessible, à l’écoute sur aucun port ou utilise le mauvais protocole. Un guide actuel de dépannage NGINX indique qu’un conteneur reconstruit peut laisser le proxy utiliser une ancienne adresse de serveur principal jusqu’à l’actualisation de la résolution de noms ou de la configuration.
Testez directement l’application depuis l’hôte du proxy ou le conteneur du proxy en utilisant le nom, l’adresse, le port et le protocole du serveur en amont consignés dans le journal. Si cette requête directe échoue de la même manière, poursuivez l’analyse entre le proxy et le conteneur plutôt que de modifier le DNS public ou les certificats.
Comparer la cible en amont avant et après la reconstruction
Inspectez le nom du conteneur reconstruit, le nom du service, l’adresse IP interne, le port exposé, le port publié, les alias réseau et les réseaux auxquels il est connecté. Comparez-les avec la configuration du proxy et sa dernière cible fonctionnelle.
Un problème signalé avec nginx-proxy décrit une reconstruction qui a modifié l’adresse IP du conteneur d’application, tandis que le proxy continuait d’envoyer les requêtes vers un serveur en amont conteneurisé inaccessible. Le domaine public restait correct : seule l’identité privée du serveur en amont avait changé.
Préférez un nom de service Compose stable ou un alias réseau à une adresse IP de conteneur. Si une adresse IP est volontairement fixe, vérifiez que le service reconstruit l’a bien reçue et qu’aucun autre conteneur ne l’utilise désormais.
Vérifier que le proxy et l’application partagent toujours un réseau Docker
Répertoriez les réseaux associés au proxy et à l’application, puis confirmez qu’ils partagent au moins un réseau défini par l’utilisateur. La publication d’un port hôte ne rend pas automatiquement le nom du conteneur accessible depuis un autre réseau Docker isolé.
Un cas de configuration réseau Docker a montré que le déplacement d’un service dépendant vers le réseau approprié supprimait immédiatement les erreurs 502 récurrentes, démontrant comment un chemin en amont inaccessible peut provoquer des erreurs même lorsque tous les conteneurs restent actifs.
Connectez les services via Compose plutôt qu’avec des commandes ponctuelles afin que cette relation survive aux reconstructions. Testez la résolution DNS et le port du serveur en amont depuis l’intérieur du conteneur du proxy après avoir recréé la pile.
Vérifier le port d’écoute interne et l’adresse d’écoute
Confirmez que l’application écoute sur le port utilisé par le proxy et sur une adresse accessible depuis le réseau des conteneurs. Ne confondez pas un port publié sur l’hôte avec le port d’écoute interne du conteneur.
Un proxy ne peut se connecter qu’une fois que l’application écoute au-delà de l’interface de bouclage. Un service qui écoute sur 127.0.0.1 à l’intérieur de son propre conteneur est inaccessible au proxy, même si une commande de vérification locale réussit.
Examinez le journal de l’application et la liste des sockets, puis effectuez une requête directe depuis le conteneur du proxy. Si le port refuse les connexions, corrigez l’écoute de l’application ou sa configuration avant d’ajouter des tentatives ou d’allonger les délais d’attente du proxy.
Attendre que l’application soit prête plutôt que le simple démarrage du conteneur
Un conteneur reconstruit peut être en cours d’exécution alors que des migrations, une récupération de base de données, une mise en cache ou la génération de la configuration empêchent encore l’application d’accepter les requêtes. Comparez l’horodatage de la première erreur 502 avec les journaux de vérification d’état et de démarrage.
Une discussion de dépannage consacrée à Grist montre comment l’architecture Docker, les paramètres d’environnement et la disponibilité du serveur en amont peuvent se combiner pour provoquer durablement des erreurs 502 côté conteneur après une reconstruction.
Ajoutez une vérification d’état pertinente et faites attendre le proxy ou les services dépendants jusqu’à ce que l’opération dont les clients ont besoin soit disponible, plutôt que de vous limiter à l’existence d’un processus. Limitez le nombre de tentatives afin qu’une application définitivement défaillante ne soit pas prise pour une application dont le démarrage est simplement lent.
Actualiser la résolution du proxy et reconstruire le chemin stable
Rechargez ou recréez le proxy une fois que le nom du service, le réseau, le port et l’état de santé sont corrects. Si le proxy ne résout les noms qu’au démarrage, configurez la résolution à l’exécution prise en charge ou un ordre de redémarrage prévisible.
Le processus ZimaSpace pour isoler une dépendance de conteneur défaillante fournit le diagnostic complémentaire lorsque le serveur en amont s’arrête de manière répétée au lieu de rester en bonne santé.
La réparation est terminée uniquement lorsque le proxy résout le nom du service après une nouvelle reconstruction, atteint le port interne prévu, attend la fin du démarrage et sert le domaine sans modification manuelle des adresses IP. Supprimez après validation les cibles temporaires utilisant directement une adresse IP et les connexions réseau non documentées.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
