Acceder al proxy del host desde un contenedor Docker en bridge

Elige una dirección de proxy accesible desde el contenedor y distingue un endpoint público de un proxy ejecutado en el host Docker.

En un contenedor normal con red bridge, 127.0.0.1 es su propia dirección loopback. Un proxy que escucha en localhost de tu portátil no escucha automáticamente dentro de cada contenedor.

Esto explica una diferencia habitual: la misma URL de proxy funciona en el terminal del host, pero da conexión rechazada dentro del contenedor. La dirección se refiere a un endpoint distinto en cada lugar.

Un proxy público se puede usar directamente

Si el endpoint elegido de un servicio o la lista de proxies HTTP es realmente una IP pública accesible, pasa esa dirección a la aplicación en vez de convertirla en localhost:

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

Sustituye la dirección de documentación y la imagen. El programa dentro de la imagen aún debe admitir las variables de entorno; Docker no convierte cada socket en una petición proxy solo porque existan.

Si el proxy se ejecuta en el host Docker

Docker Desktop ofrece host.docker.internal para llegar a la dirección interna del host. En una configuración Engine nativa compatible, una asignación de host puede proporcionar ese nombre 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

Esto cambia la resolución de nombres; no es un comando de reenvío de puertos. En Linux nativo, un servicio enlazado solo al loopback del host puede seguir siendo inaccesible por su dirección bridge. El punto de escucha, el cortafuegos y la ruta del contenedor deben permitirlo. Si cambias la escucha, limítala a los clientes necesarios en vez de crear un proxy abierto sin autenticación.

Prueba desde el mismo lugar que la aplicación

Un resultado curl en el host solo prueba su ruta. Haz la petición desde el entorno del contenedor y comprueba que llega al endpoint previsto.

«Host» también significa la máquina que ejecuta Docker Engine. Con un Engine remoto, no es necesariamente tu portátil. Por eso, es especialmente improbable que una IP loopback copiada de una aplicación local funcione sin cambios en un builder o servidor remoto.

Separa los problemas de descarga de imágenes: el daemon descarga la imagen antes de que la aplicación pueda usar el entorno mostrado arriba.

Artículos relacionados