Raggiungere il proxy host da un container Docker bridge

Scegli un indirizzo proxy raggiungibile dal container e distingui un endpoint pubblico da un proxy in esecuzione sull’host Docker.

Per un normale container in rete bridge, 127.0.0.1 è il loopback del container stesso. Un proxy in ascolto su localhost del portatile non ascolta automaticamente dentro ogni container.

Questo spiega una differenza comune: lo stesso URL proxy funziona nel terminale host ma dà connessione rifiutata nel container. L’indirizzo indica un endpoint diverso in ciascun contesto.

Un proxy pubblico si può usare direttamente

Se l’endpoint scelto da un servizio o dall’elenco di proxy HTTP è davvero un IP pubblico raggiungibile, passa quell’indirizzo all’applicazione senza trasformarlo in localhost:

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

Sostituisci indirizzo di documentazione e immagine. Il programma nell’immagine deve comunque supportare queste variabili d’ambiente; Docker non trasforma ogni socket in richiesta proxy solo perché esistono.

Se il proxy gira sull’host Docker

Docker Desktop fornisce host.docker.internal per raggiungere l’indirizzo interno dell’host. In una configurazione Engine nativa supportata, una mappatura host può fornire quel nome convenzionale:

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

Questo modifica la risoluzione dei nomi, non è un comando di port forwarding. Su Linux nativo, un servizio legato solo al loopback dell’host può restare irraggiungibile tramite il suo indirizzo bridge. Listener, firewall e rotta del container devono permettere la connessione. Se modifichi il listener, limitalo ai client necessari invece di creare un proxy aperto senza autenticazione.

Prova dallo stesso ambiente dell’applicazione

Un risultato curl sull’host verifica solo la rotta dell’host. Esegui la richiesta dall’ambiente del container e controlla che raggiunga l’endpoint previsto.

“Host” indica anche la macchina che esegue Docker Engine. Con un Engine remoto non è necessariamente il portatile. Un IP loopback copiato da un’applicazione desktop locale ha quindi ben poche probabilità di funzionare invariato su un builder o server remoto.

Tieni separati i problemi di pull dell’immagine: il daemon scarica l’immagine prima che l’applicazione possa usare l’ambiente mostrato sopra.

Articoli correlati