Por que o teu proxy corporativo intenta resolver un nome de servizo de Compose

A aplicación chega a internet a través do seu proxy corporativo, pero http://catalog:8080/ falla e o proxy non pode resolver “catalog”. Pode que esa solicitude nunca usase o DNS interno de Docker.

Un cliente HTTP pode seleccionar o seu proxy antes de establecer unha conexión directa. O proxy externo recibe entón un nome cuxo significado só existe dentro da rede de Compose.

1. Usa o nome de host na solicitude. Os servizos de Compose pódense descubrir polo nome de servizo na rede axeitada. Engade catalog á configuración de omisión compatible do cliente consumidor en lugar de codificar un IP de contedor que pode cambiar.
2. Conserva as excepcións existentes. Para un cliente consciente do contorno, combina as entradas relevantes coa lista da organización:

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

Comproba a biblioteca ou o executable real da imaxe en canto ao tratamento de maiúsculas e minúsculas, a versión e a gramática de coincidencia. Non existe un analizador NO_PROXY universal. Un programa chamado wget nunha imaxe pequena non ten por que comportarse como GNU Wget.

Unha vez que a solicitude escolle o encamiñamento directo, comproba a rede compartida do chamador e do servizo, o servizo que escoita e o porto do contedor. Un porto de host publicado é outro punto final. Unha omisión non pode engadir unha conexión de rede que falta, do mesmo xeito que recrear unha rede non pode ensinar a un proxy externo un nome privado de Compose.

Mantén a separación prevista: as solicitudes internas usan a súa ruta interna; as solicitudes externas conservan o proxy aprobado. Desactivar o proxy globalmente pode ocultar este único fallo á vez que elimina a ruta necesaria para a seguinte solicitude externa.