Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- Docker daemon primarily accesses the registry for docker pull. Setting a proxy in the current terminal does not necessarily configure the daemon.
- The proxies.default setting in ~/.docker/config.json injects proxy variables into new containers and builds. It neither changes existing containers nor configures the daemon proxy.
- Prefer predefined proxy build arguments during builds. Do not hard-code a proxy address containing credentials with ENV in a Dockerfile.
- Validate NO_PROXY against actual internal domains, IPs and ports. Do not copy a template and assume every tool interprets it identically.
- Test registry pulls, build downloads and container runtime separately, so you do not configure one layer and test another.
First locate the layer where the failure occurs
If docker pull fails, check the daemon-to-registry path first. If downloading dependencies in the Dockerfile fails, check the build proxy. If the image builds but the running program cannot access the internet, check the container runtime environment. Docker CLI, daemon, build and container are four distinct configuration boundaries.
Save the full command, error time, destination domain and status code, noting any DNS, connection-timeout, TLS or 407 error. Use the proxy connection troubleshooting checklist to identify the network layer. Do not start by changing all four configurations at once.
docker pull: Check the daemon proxy
docker pull, registry sign-in and image-manifest requests are generally initiated by Docker daemon. On Linux Engine, follow Docker's official daemon-proxy configuration and restart the daemon. Docker Desktop manages proxies in its application settings. Exporting HTTP_PROXY only in the shell may affect just the CLI itself or its child processes.
Start verification by pulling a small image you are allowed to access, then inspect the destination domain and error layer in daemon logs. Enterprise networks should also add private registries, internal image caches and local services to a reviewed NO_PROXY list, so internal traffic does not take an unintended detour.
docker build: Use build arguments, not values baked into images
Docker supports automatically supplying HTTP_PROXY, HTTPS_PROXY and NO_PROXY to new builds through proxies.default in ~/.docker/config.json, or passing them temporarily with --build-arg. Predefined proxy arguments are not automatically written into final image history merely because they are referenced, but real credentials should still never be printed in build output.
Do not hard-code a proxy with ENV HTTP_PROXY=... in the Dockerfile. Official guidance warns that proxy variables may contain sensitive information; baking them in adds them to image configuration, where they may be read through the remote API, inspect or subsequent commits. Prefer build secrets or controlled CI injection when downloading private dependencies.
Container runtime: New configuration does not update existing containers
The proxies.default setting in Docker CLI configuration adds proxy variables to new containers. Changing config.json does not automatically update containers already created. Recreate the container instead of merely using restart. With Compose, also inspect the final resolved configuration to confirm variables come from the intended environment.
Use docker inspect only to verify variable names and presence. Mask usernames, passwords and tokens in output and tickets. Then test DNS, TCP, TLS and target responses separately inside the container. Success on the host does not imply the same network namespace or CA trust inside the container.
Why NO_PROXY often does not work as expected
NO_PROXY has no complete standard shared across tools. Clients may handle leading dots, wildcards, CIDR, ports and uppercase or lowercase variables differently. First list registries, internal domains, loopback addresses and service subnets that must connect directly, then verify each with the HTTP client in the actual image.
Do not casually add overly broad domain suffixes or every private subnet to the bypass list; this expands direct access and potential data exposure. Nor should you add an external AI API domain to NO_PROXY while still expecting it to use the proxy. Configuration intent must match the traffic policy.
Verification checklist for the three paths
Verify in order: first, whether the daemon can resolve and connect to the registry; second, whether the build can download dependencies without exposing credentials; third, whether a new container reads the expected variables and reaches permitted targets; fourth, whether internal domains connect directly according to NO_PROXY; and fifth, whether real credentials appear in image history, inspect output, CI logs or error reports. Change only one layer at a time.
If your team needs stable access to overseas registries, package repositories and developer documentation, visit the PuppyIP website to learn about fixed network egress. Network services do not replace registry permissions, licenses, enterprise security policies or secrets management.
Sources
Frequently Asked Questions
Why does docker pull still fail after setting HTTP_PROXY?
Registry requests for docker pull are usually made by the daemon. Check the daemon or Docker Desktop proxy, not just the current shell.
Does changing ~/.docker/config.json affect existing containers?
No. Official documentation states that the configuration affects new containers and builds. Existing containers must be recreated.
Can I save a proxy with ENV in a Dockerfile?
This is not recommended. Proxy addresses often contain credentials, and ENV embeds them in image configuration, increasing exposure risk.
How do I pass a temporary proxy to Docker build?
Use the officially supported predefined proxy build arguments, or let CLI configuration inject them into new builds. Do not print real values in build logs.
Why does a container time out when the host can reach the internet?
The container's DNS, network namespace, proxy variables and CA trust may differ. Verify each layer inside the container.
Can I copy an online NO_PROXY template directly?
You should not copy it blindly. Semantics can differ by tool. Test each actual internal domain, IP and port with the client you use.