Por que o proxy corporativo da sua empresa tenta resolver um nome de serviço do Compose

A aplicação chega à internet pelo proxy corporativo, mas http://catalog:8080/ falha e o proxy não consegue resolver “catalog”. É possível que essa solicitação nunca tenha usado o DNS interno do Docker.

Um cliente HTTP pode selecionar seu proxy antes de estabelecer uma conexão direta. O proxy externo então recebe um nome cujo significado só existe dentro da rede do Compose.

1. Use o nome do host na solicitação. Os serviços do Compose podem ser descobertos pelo nome do serviço na rede apropriada. Adicione catalog à configuração de desvio suportada pelo cliente consumidor em vez de codificar um IP de contêiner que pode mudar.
2. Preserve as exceções existentes. Para um cliente ciente do ambiente, combine as entradas relevantes com a lista da organização:

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

Verifique a biblioteca ou o executável real na imagem quanto ao tratamento de maiúsculas e minúsculas, à versão e à gramática de correspondência. Não existe um analisador NO_PROXY universal. Um programa chamado wget em uma imagem pequena não precisa se comportar como o GNU Wget.

Depois que a solicitação escolhe o roteamento direto, verifique a rede compartilhada do chamador e do serviço, o serviço que escuta e a porta do contêiner. Uma porta de host publicada é outro endpoint. Um desvio não pode adicionar uma conexão de rede ausente, assim como recriar uma rede não pode ensinar a um proxy externo um nome privado do Compose.

Mantenha a separação pretendida: solicitações internas usam seu caminho interno; solicitações externas mantêm o proxy aprovado. Desativar o proxy globalmente pode ocultar essa única falha enquanto remove a rota necessária para a próxima solicitação externa.