Acessar o proxy do host a partir de um contêiner Docker em bridge

Escolha um endereço de proxy acessível pelo contêiner e diferencie um endpoint público de um proxy no host Docker.

Em um contêiner normal com rede bridge, 127.0.0.1 é o loopback do próprio contêiner. Um proxy escutando no localhost do seu notebook não escuta automaticamente dentro de cada contêiner.

Isso explica um resultado comum: a mesma URL de proxy funciona no terminal do host, mas retorna conexão recusada no contêiner. O endereço aponta para um endpoint de rede diferente em cada lugar.

Um proxy público pode ser usado diretamente

Se o endpoint de um serviço ou da lista de proxies HTTP for realmente um IP público acessível, passe esse endereço ao aplicativo em vez de trocá-lo por localhost:

docker run --rm \
  -e HTTP_PROXY=http://203.0.113.10:8080 \
  -e HTTPS_PROXY=http://203.0.113.10:8080 \
  your-image

Substitua o endereço de documentação e a imagem. O programa na imagem ainda precisa suportar essas variáveis de ambiente; o Docker não transforma cada socket em requisição proxy só porque elas existem.

Se o proxy estiver no host Docker

O Docker Desktop fornece host.docker.internal para acessar o endereço interno do host. Em uma instalação Engine nativa compatível, um mapeamento de host pode fornecer esse nome convencional:

docker run --rm \
  --add-host host.docker.internal=host-gateway \
  -e HTTP_PROXY=http://host.docker.internal:8080 \
  -e HTTPS_PROXY=http://host.docker.internal:8080 \
  your-image

Isso muda a resolução de nomes, não é um comando de encaminhamento de porta. No Linux nativo, um serviço vinculado apenas ao loopback do host pode continuar inacessível pelo endereço bridge do host. Listener, firewall e rota do contêiner precisam permitir a conexão. Se mudar o listener, limite-o aos clientes necessários em vez de criar um proxy aberto sem autenticação.

Teste no mesmo lugar que o aplicativo

Um resultado curl no host só testa a rota do host. Faça a requisição no ambiente do contêiner e veja se alcança o endpoint pretendido.

“Host” também significa a máquina que executa o Docker Engine. Com um Engine remoto, ela não é necessariamente seu notebook. Por isso, é especialmente improvável que um IP loopback copiado de um aplicativo local funcione sem alterações em um builder ou servidor remoto.

Separe problemas de pull da imagem: o daemon baixa a imagem antes de o aplicativo poder usar o ambiente acima.

Artigos relacionados