Docker Base-Image Pulls: Builder Proxy vs Build Arguments
Proxy arguments supplied to build steps do not configure every registry request made by the builder. Locate the builder resolving the base image.
A build can fail while resolving FROM before any Dockerfile package-download step runs. The builder's registry client needs its own route to obtain that base image.
| Operation | Component needing the route |
|---|---|
| Resolve and fetch the base image | The builder's registry client |
| Download during RUN | The process executing the build step |
| Call an API at runtime | The running application |
Locate the builder
The default Docker driver centers on the daemon. Other Buildx drivers can use a dedicated BuildKit container, Kubernetes, or a remote service. Configure the selected driver's supported proxy mechanism where that worker runs.
A laptop loopback proxy is not automatically reachable from a remote worker, and editing the local daemon does not reconfigure that remote builder.
An ARG before FROM can help choose the image reference. It does not thereby configure the registry client's network route. Later RUN commands that write package settings or install certificates cannot repair this earlier request.
Trust, accounts, and cached data
Approved CA material must be available to the component validating the initial registry connection. Registry credentials and proxy credentials authorize different parties; a registry login cannot answer a proxy 407.
A worker reusing cached image data may not repeat the same network request as a fresh worker. Compare the actual logged operation. Once base-image access works through the intended route, diagnose any later build-step download at that next boundary.