Guida Docker · 2 min di lettura

Docker dietro un proxy: daemon, build e compose

Docker ha bisogno di un proxy in tre posti separati: il demone che scarica le immagini, la build che esegue i comandi e i contenitori che esegui. Imposta quello sbagliato e i download continueranno a fallire. Ecco ciascuno, correttamente definito.

Inizia

Tre livelli, tre configurazioni

Il motivo per cui "ho impostato http_proxy ma docker pull continua a fallire" è così comune è che Docker ha tre contesti di rete indipendenti, e le variabili d'ambiente della tua shell toccano solo uno di essi. Prima di tutto, il demone (dockerd) è quello che effettivamente scarica le immagini da un registro — funziona come un servizio di sistema e legge il suo proxy dalla propria configurazione, non dalla tua shell. In secondo luogo, il build esegue ogni RUN all'interno di un contenitore temporaneo che ha bisogno del proprio proxy per raggiungere la rete. Infine, il contenitore in esecuzione ha bisogno di un proxy se l'app al suo interno effettua chiamate in uscita.

Tutti e tre utilizzano l'endpoint HTTP su porta 3128 con autenticazione USER:PASS. Il modo moderno per configurare il demone e il build è il file di configurazione del client Docker ~/.docker/config.json, che inietta le impostazioni del proxy nei build e in docker run automaticamente; il demone stesso è configurato tramite un drop-in systemd o le impostazioni di Docker Desktop. Vedi la pagina del proxy; questo si abbina naturalmente alle guide npm/yarn e pip/conda per ciò che viene eseguito all'interno delle tue immagini.

Configura tutti e tre i livelli

Daemon tramite systemd drop-in, costruisce e avvia tramite docker config.json e un fallback di compose. Sostituisci USER:PASS.

bash

# --- 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:3128

Fai funzionare il docker pull e build

Correggi gli strati nell'ordine in cui si verificano solitamente i guasti.

Prima risolvi il demone

Se il docker pull fallisce, il demone non può raggiungere il registro. Aggiungi il drop-in di systemd con HTTP_PROXY/HTTPS_PROXY, poi daemon-reload e riavvia docker. Su Docker Desktop, imposta il proxy nelle Impostazioni invece.

Configura il client per le build

Aggiungi il blocco dei proxy a ~/.docker/config.json in modo che docker build e docker run iniettino automaticamente il proxy in ogni passaggio e contenitore — nessuna modifica del Dockerfile richiesta.

Aggiungi NO_PROXY ovunque

Includi localhost, 127.0.0.1 e qualsiasi registro interno o host di servizio in NO_PROXY a ogni livello, in modo che il traffico interno non venga instradato inutilmente attraverso il proxy.

Verifica ogni livello

Testa con docker pull hello-world (daemon), un build che esegue apt-get o pip (build), e un container che chiama un endpoint IP-echo (runtime).

Definizione, segreti e onestà

Due avvertenze. Prima, mantieni le credenziali del proxy fuori dai layer delle immagini. Impostare le variabili d'ambiente del proxy all'interno di un Dockerfile con ENV le incorpora nell'immagine; utilizza argomenti di build o l'iniezione del client config.json invece, in modo che le credenziali rimangano sull'host di build. Secondo, sii preciso con NO_PROXY — un'entrata mancante per un registro interno significa che Docker cerca di raggiungerlo attraverso il proxy esterno e fallisce in modo confuso.

Il proxy HTTP di s4m è un endpoint autenticato datacenter, a pagamento in base all'uso — ben adatto a costruttori CI e host DevOps che devono scaricare immagini e pacchetti da dietro un'uscita controllata. Non è residenziale, ed è un proxy forward, non un mirror o cache di registro; per la cache pull-through, esegui un mirror di registro accanto ad esso. Quando la tua flotta di build ha bisogno di un IP di uscita autorizzato, aggiungi un IP personale dedicato. Un 407 ovunque significa credenziali del proxy errate — consulta la guida 407. Valida l'endpoint con gli strumenti.

FAQ

Domande, risposte

Perché il docker pull fallisce anche se ho impostato http_proxy nella mia shell?

Perché i pull delle immagini vengono eseguiti dal demone, non dal tuo shell. Configura il proxy di dockerd tramite un drop-in di systemd (o le impostazioni di Docker Desktop) con HTTP_PROXY/HTTPS_PROXY, poi esegui daemon-reload e riavvia docker.

Come posso fare proxy per docker build e docker run senza modificare il Dockerfile?

Aggiungi un blocco proxy a ~/.docker/config.json. Il client Docker inietta httpProxy/httpsProxy in ogni passaggio di build e contenitore automaticamente, quindi non sono necessarie modifiche al Dockerfile.

Come posso tenere le credenziali del proxy fuori dalla mia immagine?

Non impostarli con ENV nel Dockerfile — questo li incorpora nei layer. Usa argomenti di build o l'iniezione del file client config.json in modo che le credenziali rimangano sull'host di build, non nell'immagine distribuita.

s4m fornisce un mirror o cache del registro?

No. s4m è un proxy di datacenter in avanti per il traffico in uscita, non una cache di registro pull-through. Per la memorizzazione delle immagini, esegui uno specchio del registro e instradalo attraverso il proxy se necessario.

Continua a leggere

Potresti anche apprezzare

Tira e costruisci dietro un proxy

Instrada il demone Docker, le build e i container attraverso l'endpoint HTTP autenticato su proxy.s4m.online:3128. Pagamento a consumo, IP dedicato per le liste di autorizzazione CI.

Vedi i prezzi dei proxy Vedi i prezzi

Le persone hanno trovato questa pagina cercando

Docker dietro un proxy
come utilizzare i proxy con Scrapy
Docker dietro un proxy tutorial
Impostazioni Docker dietro un proxy
come controllare se un proxy è valido (con uno script pronto)
come proxy socks5 funziona
come wireguard funziona
è autenticazione proxy sicuro
indirizzo ip
quanto tempo vivono i proxy gratuiti
autenticazione proxy

Frasi di ricerca reali a cui questa pagina risponde — i collegamenti aprono la pagina che le tratta in dettaglio.