Por qué tu proxy corporativo intenta resolver un nombre de servicio de Compose

La aplicación llega a internet a través de su proxy corporativo, pero http://catalog:8080/ falla y el proxy no puede resolver “catalog”. Es posible que esa solicitud nunca haya usado el DNS interno de Docker.

Un cliente HTTP puede seleccionar su proxy antes de establecer una conexión directa. El proxy externo recibe entonces un nombre cuyo significado solo existe dentro de la red de Compose.

1. Usa el nombre de host en la solicitud. Los servicios de Compose se pueden descubrir por nombre de servicio en la red adecuada. Añade catalog a la configuración de omisión compatible del cliente consumidor en lugar de codificar una IP de contenedor que puede cambiar.
2. Conserva las excepciones existentes. Para un cliente consciente del entorno, combina las entradas relevantes con la lista de la organización:

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

Comprueba la biblioteca o el ejecutable real de la imagen en cuanto al manejo de mayúsculas y minúsculas, la versión y la gramática de coincidencia. No existe un analizador NO_PROXY universal. Un programa llamado wget en una imagen pequeña no tiene por qué comportarse como GNU Wget.

Una vez que la solicitud elige el enrutamiento directo, comprueba la red compartida del llamador y del servicio, el servicio que escucha y el puerto del contenedor. Un puerto de host publicado es otro punto final. Una omisión no puede añadir una conexión de red que falta, del mismo modo que recrear una red no puede enseñar a un proxy externo un nombre privado de Compose.

Mantén la separación prevista: las solicitudes internas usan su ruta interna; las solicitudes externas conservan el proxy aprobado. Desactivar el proxy globalmente puede ocultar este único fallo a la vez que elimina la ruta necesaria para la siguiente solicitud externa.