Docker atrás de um proxy: daemon, build e compose
O Docker precisa de um proxy em três lugares separados — o daemon que puxa imagens, a construção que executa comandos e os contêineres que você executa. Defina o errado e os pulls ainda falham. Aqui está cada um, corretamente escopado.
Três camadas, três configurações
A razão pela qual "configurei http_proxy, mas o docker pull ainda falha" é tão comum é que o Docker tem três contextos de rede independentes, e as variáveis de ambiente do seu shell tocam apenas um deles. Primeiro, o daemon (dockerd) é o que realmente puxa imagens de um registro — ele roda como um serviço de sistema e lê seu proxy de sua própria configuração, não do seu shell. Em segundo lugar, o build executa cada passo RUN dentro de um contêiner temporário que precisa de seu próprio proxy para acessar a rede. Por último, o contêiner em execução precisa de um proxy se o aplicativo dentro dele fizer chamadas externas.
Todos os três usam o s4m ponto de extremidade HTTP na porta 3128 com autenticação USER:PASS. A maneira moderna de configurar o daemon e o build é o arquivo de configuração do cliente Docker ~/.docker/config.json, que injeta configurações de proxy nos builds e no docker run automaticamente; o daemon em si é configurado via um drop-in do systemd ou configurações do Docker Desktop. Veja a página de proxy; isso combina naturalmente com os guias npm/yarn e pip/conda para o que roda dentro das suas imagens.
Configure todas as três camadas
Daemon via systemd drop-in, constrói e executa via docker config.json, e um fallback de compose. Substitua USER:PASS.
# --- 1) DAEMON (image pulls): systemd drop-in on Linux ---
sudo mkdir -p /etc/systemd/system/docker.service.d
sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf >/dev/null <<'CONF'
[Service]
Environment="HTTP_PROXY=http://USER:PASS@proxy.s4m.online:3128"
Environment="HTTPS_PROXY=http://USER:PASS@proxy.s4m.online:3128"
Environment="NO_PROXY=localhost,127.0.0.1,.internal"
CONF
sudo systemctl daemon-reload && sudo systemctl restart docker
# --- 2) BUILDS + RUNS: ~/.docker/config.json (injected automatically) ---
cat > ~/.docker/config.json <<'JSON'
{
"proxies": {
"default": {
"httpProxy": "http://USER:PASS@proxy.s4m.online:3128",
"httpsProxy": "http://USER:PASS@proxy.s4m.online:3128",
"noProxy": "localhost,127.0.0.1,.internal"
}
}
}
JSON
# --- 3) docker-compose fallback (per-service build args) ---
# services:
# app:
# build:
# context: .
# args:
# HTTP_PROXY: http://USER:PASS@proxy.s4m.online:3128
# HTTPS_PROXY: http://USER:PASS@proxy.s4m.online:3128Faça o docker pull e build funcionarem
Corrija as camadas na ordem em que as falhas geralmente aparecem.
Corrija o daemon primeiro
Se o docker pull falhar, o daemon não consegue acessar o registro. Adicione o drop-in do systemd com HTTP_PROXY/HTTPS_PROXY, depois daemon-reload e reinicie o docker. No Docker Desktop, configure o proxy em Configurações.
Configure o cliente para builds
Adicione o bloco de proxies ao ~/.docker/config.json para que docker build e docker run injetem o proxy em cada etapa e contêiner automaticamente — sem edições no Dockerfile necessárias.
Adicione NO_PROXY em todos os lugares
Inclua localhost, 127.0.0.1 e qualquer registro interno ou host de serviço em NO_PROXY em todas as camadas, para que o tráfego interno não seja desnecessariamente roteado para fora através do proxy.
Verifique cada camada
Teste com docker pull hello-world (daemon), uma build que executa apt-get ou pip (build), e um contêiner que faz curl em um endpoint de eco de IP (runtime).
Escopo, segredos e honestidade
Duas precauções. Primeiro, mantenha as credenciais do proxy fora das camadas da imagem. Definir variáveis de ambiente do proxy dentro de um Dockerfile com ENV as incorpora na imagem; use argumentos de construção ou a injeção do cliente config.json em vez disso, para que as credenciais permaneçam no host de construção. Segundo, seja preciso com NO_PROXY — uma entrada ausente para um registro interno significa que o Docker tenta acessá-lo através do proxy externo e falha de forma confusa.
O proxy HTTP do s4m é um endpoint autenticado de datacenter, com pagamento conforme o uso — bem adequado para construtores de CI e hosts de DevOps que precisam puxar imagens e pacotes de trás de uma saída controlada. Não é residencial, e é um proxy de encaminhamento, não um espelho ou cache de registro; para cache de pull-through, execute um espelho de registro ao lado. Quando sua frota de construção precisa de um IP de saída permitido, adicione um IP pessoal dedicado. Um 407 em qualquer lugar significa credenciais de proxy ruins — veja o guia 407. Valide o endpoint com as ferramentas.
Perguntas, respondidas
Por que o docker pull falha mesmo que eu tenha configurado http_proxy no meu shell?
Porque as pulls de imagem são feitas pelo daemon, não pelo seu shell. Configure o proxy do dockerd via um drop-in do systemd (ou configurações do Docker Desktop) com HTTP_PROXY/HTTPS_PROXY, depois daemon-reload e reinicie o docker.
Como faço para usar proxy no docker build e docker run sem editar o Dockerfile?
Adicione um bloco de proxies a ~/.docker/config.json. O cliente Docker injeta httpProxy/httpsProxy em cada etapa de construção e contêiner automaticamente, então nenhuma alteração no Dockerfile é necessária.
Como mantenho as credenciais do proxy fora da minha imagem?
Não os defina com ENV no Dockerfile — isso os incorpora em camadas. Use argumentos de construção ou a injeção do config.json do cliente para que as credenciais permaneçam no host de construção, não na imagem enviada.
O s4m fornece um espelho de registro ou cache?
Não. s4m é um proxy de datacenter para tráfego de saída, não um cache de registro pull-through. Para armazenar imagens em cache, execute um espelho de registro e roteie-o através do proxy, se necessário.
Puxe e construa atrás de um proxy
Roteie o daemon do Docker, builds e contêineres através do endpoint HTTP autenticado em proxy.s4m.online:3128. Pagamento por uso, IP dedicado para listas de permissão de CI.
As pessoas encontraram esta página pesquisando por
- Docker atrás de um proxy
- como usar proxies com Scrapy
- Docker atrás de um proxy tutorial
- Configurações de Docker atrás de um proxy
- como verificar se um proxy é válido (com um script pronto)
- como socks5 proxy funciona
- como wireguard funciona
- é autenticação de proxy seguro
- endereço IP
- quanto tempo os proxies gratuitos duram
- autenticação de proxy
Frases de busca reais que esta página responde — os links abrem a página que as cobre em profundidade.