Using a proxy cleanly in Docker, WSL and virtual machines

First, one thing to understand

127.0.0.1 always means "myself". In a container it means the container; in WSL2 it means the WSL VM; in VMware it means the virtual machine. So 127.0.0.1:7898 on the host is unreachable from these environments.

Two needs, handled separately

Docker Desktop: use host.docker.internal

Docker Desktop gives containers a special hostname, host.docker.internal, that points to the host:

docker run --rm -e HTTPS_PROXY=http://host.docker.internal:7898 python:3.13 pip download requests

Native Docker on Linux, WSL2 and VMs: the shared proxy

Requests from these environments come from another address in a private range. For safety, CoderBoost's local proxy only accepts connections from the same machine by default. You need to:

1. turn on the shared proxy in the client and allow only the matching private range;
2. create separate credentials for each guest (the password is shown only once);
3. use http://username:password@host-address:port as the proxy inside the guest.

Why credentials? Because once a range is open, other devices on that range could connect too. Separate credentials tell you who is using it and let you revoke each one individually at any time.

Three common pitfalls

1. Putting the proxy in a Dockerfile ENV: the proxy address, or even the password, stays in the image layers. Pass it with --build-arg instead.
2. Forgetting NO_PROXY: containers reaching internal services (databases, other containers) also go through the proxy. Set NO_PROXY=localhost,127.0.0.1,.internal,db.
3. The WSL host address changes: look up the default gateway with ip route at every start instead of hard-coding it.