Routing Docker and WSL2 Through Clash: Image Pull Timeouts and Network Configuration

Clash listening on 127.0.0.1 in Windows only guarantees access from that Windows machine. WSL2 uses a NAT virtual network by default, and containers also have independent networking. Their requests to 127.0.0.1 usually reach themselves, not the host.

First inspect the actual HTTP or mixed-port in Clash. A common example is 7890, but your client may differ. When WSL accesses it through the host IP, the connection is treated as local-network traffic, so the client must allow LAN access and listen on an address reachable from WSL.

Allowing LAN access expands the port's reachability. Use it only on a trusted private home or work network and have Windows Firewall restrict sources. Do not expose an unauthenticated proxy on public Wi-Fi or the internet. Disable LAN access after testing if you no longer need it.

In default NAT mode, WSL can read the next hop of its default route, which is usually the Windows host's address in the WSL virtual network. With mirrored networking enabled on Windows 11 22H2 and later, WSL can access Windows services directly through 127.0.0.1.

Only after this curl receives an HTTP response should you set WSL environment variables. If the proxy port immediately returns Connection refused, the issue is Clash listening, LAN access, or the firewall. If the port is reachable but the external request shows timeout, then inspect the node and rules.

Temporary variables are read by programs started from the current terminal. Repeat the same HTTPS request with git or curl, then add the working settings to your shell startup file. For HTTP URLs, curl reads lowercase http_proxy; HTTP_PROXY alone will not work.

The HTTP transport in apt reads lowercase http_proxy and no_proxy, or its own Acquire::http::Proxy setting. When starting it with sudo, also check whether the environment is retained. Do not treat the variable block above as universal proxy settings for every tool.

Supported Windows versions of WSL can also use autoProxy=true in .wslconfig to import Windows HTTP proxy information. Restart WSL after enabling it and inspect the actual variable values.

NO_PROXY should include services available only inside WSL so access to localhost does not detour through the Windows proxy. Add internal corporate domains and private ranges according to the actual network.

Docker Desktop image pulls and WSL shell downloads come from different processes. Running export HTTP_PROXY only in WSL does not automatically configure image pulls in Desktop.

Open Settings in Docker Desktop, enter HTTP and HTTPS proxies reachable from the host under Resources / Proxies, whose labels may vary by version, and apply the settings.

If the page separates Docker Desktop proxy and Containers proxy, check Containers proxy for image pulls. Docker Desktop proxy is only a fallback when Containers proxy is not configured. Verify the change with docker pull.

Official Docker documentation explicitly states that Desktop does not read daemon proxy settings from daemon.json. A working WSL terminal does not let you skip Docker Desktop's own proxy settings.

Only when using standalone Linux Docker Engine rather than Docker Desktop should you configure daemon proxies through daemon.json or the systemd environment according to Engine documentation, then restart the Docker service. Identify what you are running first so you do not edit a file that is never read.

Docker client configuration can automatically inject proxy variables into new containers and builds or pass them explicitly for a single command. Use --build-arg at build time and --env at runtime. Do not use ENV in a Dockerfile to persist a credential-bearing proxy address; image history and configuration may retain it.

Run this example from a project directory containing a Dockerfile. demo-app is the image name for this build; replace it for your project as needed. This is not a standalone connectivity test. First use the earlier curl check to test whether the proxy port is reachable.

Docker Desktop normally provides host.docker.internal for reaching the host. Availability in native Linux Engine depends on the environment and may require an explicit host gateway or extra host-gateway mapping. Before running the command, use curl or application logs inside the container to confirm that the hostname and port are reachable.

Database names, Compose service names, localhost, and internal subnets normally should not use an external proxy. Add the actual internal domains to NO_PROXY so requests to db:5432 or redis:6379 do not first go to the Windows proxy. Wildcard and CIDR support differs between tools; after setting the variable, print it in the target process and make a real request.

If a proxy address contains a username or password, do not put it in a public compose.yaml, Dockerfile, or image. Use a local environment file or the project's secret-management method, and ensure logs do not print the complete URL.