WSL Auto-Proxy: Importing Windows Proxy State Without Leaking Credentials

WSL 2 can import Windows HTTP proxy information into Linux, but the feature is not a universal proxy client. Microsoft’s current networking documentation scopes auto-proxy to Windows 11 version 22H2 and later; .wslconfig places the setting under [wsl2] and currently lists autoProxy as enabled by default. Confirm the actual host/WSL configuration instead of inferring support from an environment variable appearing in one terminal. These settings apply to WSL 2, not WSL 1.

To make the setting explicit on a supported host, add or merge this section in %UserProfile%\.wslconfig:

[wsl2]
autoProxy=true

Do not replace an existing [wsl2] section with a duplicate. After a configuration change, stop the affected WSL VM/distro and relaunch it; wsl --shutdown stops all running WSL 2 distributions, so use it only when that interruption is acceptable.

What auto-proxy actually mirrors

With auto-proxy enabled, WSL’s troubleshooting documentation says it sets HTTP_PROXY, HTTPS_PROXY, and NO_PROXY from the corresponding Windows HTTP proxy configuration, and sets upper- and lower-case forms (except for WSL_PAC_URL). A PAC configuration is different: WSL passes its URL in WSL_PAC_URL; Linux tools do not generally evaluate PAC scripts automatically. A program must support PAC or be given a separately resolved proxy by an approved mechanism. Do not treat a PAC URL as if it were a static HTTP_PROXY endpoint or assume WSL has evaluated per-destination PAC logic for every client.

Why “it mirrors the proxy” doesn’t mean every tool obeys it

The practical gap is that HTTP_PROXY/HTTPS_PROXY are a widely adopted convention, not a kernel-enforced or libc-enforced rule - whether a given piece of software actually routes its traffic through the configured proxy depends entirely on whether that specific tool’s own networking code checks those variables at all. curl, wget, git, and most language package managers (pip, npm) honor them by default. Other software reads proxy configuration from its own dedicated config file or system trust store instead, entirely independent of what’s exported into the shell environment - meaning a distribution can have technically correct auto-proxy variables set and still have a specific application fail to reach the internet, because that particular application was never looking at those variables in the first place.

Inspecting what’s actually been imported

Before assuming a networking failure is proxy-related, confirm what WSL actually populated:

for name in HTTP_PROXY HTTPS_PROXY NO_PROXY http_proxy https_proxy no_proxy WSL_PAC_URL; do
  if printenv "$name" >/dev/null; then
    printf '%s is set (value withheld)\n' "$name"
  fi
done

The set-only check deliberately withholds values. If you need to inspect full proxy variables, do so in a private terminal and redact them before sharing: a proxy URL can embed a username and password directly (http://user:[email protected]:8080), and raw env or printenv output in a recording, support ticket, or CI log can expose those credentials. Prefer authentication mechanisms that avoid passwords in URLs when the proxy infrastructure supports them.

Testing incrementally rather than assuming a single failure means everything is broken

A methodical test order avoids wasted troubleshooting: first a plain HTTPS request with a tool known to respect the standard variables. This form prints a status code without dumping request headers or proxy credentials into terminal recordings:

curl --fail --silent --show-error --output /dev/null --write-out 'http=%{http_code}\n' https://example.com

Then test a package manager or application only in an environment where its changes are acceptable. Language-specific or containerized tools may need separate proxy configuration; Docker’s daemon proxy settings, for example, are configured independently of an interactive shell’s environment. Avoid curl -v in shared or recorded sessions: verbose output can reveal request metadata and may expose proxy authentication details. If verbose diagnostics are indispensable, capture them privately and redact before sharing.

TLS interception proxies and the certificate trust problem

Many enterprise proxies perform TLS interception - terminating the HTTPS connection at the proxy, inspecting traffic, then re-encrypting with a certificate signed by the organization’s own internal CA. Linux tools verify TLS certificates against the distribution’s own trust store, which does not automatically include a Windows-managed enterprise root CA just because the proxy variables were successfully imported. This is why curl/pip/apt can fail with certificate verification errors even when the proxy connection itself succeeds: the proxy is reachable, but the re-signed certificate it presents isn’t trusted yet.

The fix is installing the organization’s CA certificate into the distribution’s own trust store, not disabling verification:

sudo cp corporate-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

Disabling certificate verification (curl -k, pip --trusted-host, git -c http.sslVerify=false) removes the actual protection TLS is providing and should be treated as a last-resort diagnostic step, never a standing configuration - it means every one of those connections is now unverified, indistinguishable from a genuine man-in-the-middle attack from the tool’s own perspective.

VPN connection order and discovery timing

Proxy discovery may race with a VPN or proxy service that has not finished publishing Windows proxy information at WSL startup. The current WSL configuration reference documents initialAutoProxyTimeout (Windows 11 only; default 1000 ms) for the wait when autoProxy is enabled and says that if proxy settings resolve after that wait, WSL must be restarted to use them. If behavior changes with connection order, record the observed host proxy state and WSL version, then test a restart after the VPN is connected; do not assume this is the cause without comparing the environment.

wsl --shutdown

then relaunch the distribution and retest the imported variables. This is a diagnostic experiment for the documented startup timeout, not a guaranteed fix for every VPN or PAC issue.

PAC scripts add a layer auto-proxy can’t fully resolve on your behalf

Some enterprises configure a Proxy Auto-Configuration (PAC) script, which Windows evaluates per destination. Microsoft’s WSL troubleshooting guidance says WSL sets WSL_PAC_URL for a PAC proxy and notes Linux does not support PAC by default. Therefore, seeing this variable is not proof that curl, git, a package manager, or every other client evaluated the script. Check the specific client’s PAC support or use the proxy configuration path approved by the network team. Static proxy variables and PAC handling are separate diagnostic cases; test an approved internal and external destination independently, without bypassing policy.

Confirming the feature is actually available on your WSL version

Auto-proxy is documented for Windows 11 22H2 and later. The feature is configured for WSL 2 through .wslconfig; older Windows releases or WSL 1 are outside that documented scope. Confirm the host build and WSL package version before troubleshooting:

wsl --version

Comparing the reported version against Microsoft’s current WSL documentation for the feature avoids an extended troubleshooting session aimed at a capability that was never present in the first place - updating via wsl --update is the direct fix if the installed version predates the feature.

Documenting what you found for the next person

Because proxy behavior genuinely differs across VPN states, network locations, and individual tool configuration, recording what actually worked - which variables were present, which tools required separate configuration, whether a CA certificate installation was needed - saves the next troubleshooting session from re-deriving the same findings from scratch, particularly on a shared team where multiple people hit the same enterprise proxy independently.

Related:

Sources: