Pourquoi votre proxy d'entreprise tente de résoudre un nom de service Compose

L'application atteint internet via son proxy d'entreprise, mais http://catalog:8080/ échoue et le proxy ne peut pas résoudre « catalog ». Cette requête n'a peut-être jamais utilisé le DNS interne de Docker.

Un client HTTP peut sélectionner son proxy avant d'établir une connexion directe. Le proxy externe reçoit alors un nom dont la signification n'existe qu'à l'intérieur du réseau Compose.

1. Utilisez le nom d'hôte dans la requête. Les services Compose sont découvrables par nom de service sur le réseau approprié. Ajoutez catalog à la configuration de contournement prise en charge du client consommateur plutôt que de coder en dur une IP de conteneur susceptible de changer.
2. Préservez les exceptions existantes. Pour un client conscient de son environnement, fusionnez les entrées pertinentes avec la liste de l'organisation :

NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Vérifiez la bibliothèque ou l'exécutable réel de l'image pour la gestion de la casse, la version et la grammaire de correspondance. Il n'existe pas d'analyseur NO_PROXY universel. Un programme nommé wget dans une petite image n'est pas tenu de se comporter comme GNU Wget.

Une fois que la requête choisit le routage direct, vérifiez le réseau partagé de l'appelant et du service, le service à l'écoute et le port du conteneur. Un port d'hôte publié est un autre point de terminaison. Un contournement ne peut pas ajouter une attache réseau manquante, pas plus que recréer un réseau ne peut apprendre à un proxy externe un nom Compose privé.

Conservez la séparation voulue : les requêtes internes utilisent leur chemin interne ; les requêtes externes conservent le proxy approuvé. Désactiver globalement le proxy peut masquer cette unique défaillance tout en supprimant la route nécessaire à la prochaine requête externe.