For a normal bridge-networked container, 127.0.0.1 is the container's own loopback address. A proxy listening on your laptop's localhost is not automatically listening inside every container.

This explains a common split result: the same-looking proxy URL works in a host terminal but produces connection refused inside the container. The address refers to a different network endpoint in each place.

A public proxy can be used directly

If the endpoint is genuinely a reachable public IP selected from a service or the HTTP proxy list, pass that address to the application rather than translating it into localhost:

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

Replace the documentation address and image. The program inside the image still needs to support these environment variables; Docker does not turn every socket into a proxied request merely because the variables exist.

If the proxy is running on the Docker host

Docker Desktop provides host.docker.internal for reaching the host's internal address. On a supported native Engine setup, a host mapping can supply that conventional name:

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

This changes name resolution; it is not a port-forwarding command. On native Linux, a service bound only to the host's loopback address may still be unreachable through the host's bridge address. The listener, firewall, and container route must allow that connection. If you change the listener, restrict it to the clients that need access instead of creating an unauthenticated open proxy.

Test from the same place as the application

A host-side curl result only tests the host route. Run the relevant request from the container environment and check whether it reaches the intended endpoint.

The name “host” also means the machine running Docker Engine. With a remote Engine, it is not necessarily your laptop. A loopback IP copied from a local desktop application is therefore especially unlikely to work unchanged on a remote builder or server.

Keep image-pull problems separate: the daemon downloads the image before the application can use the environment shown above.

Allakkat attuumassuteqartut