How to make Windows proxy work with wsl2?

Establishing a functional proxy for Windows Subsystem for Linux 2 (WSL2) within a Windows environment that already uses a proxy requires a multi-layered approach, as WSL2 operates with a distinct virtualized network interface and its own IP address separate from the host. The core challenge is that WSL2 distributions, by default, do not automatically inherit the Windows system's proxy settings. The primary solution involves explicitly configuring the proxy within the WSL2 instance itself, while also ensuring the Windows host can accept proxy requests from the WSL2 subnet. A successful configuration typically necessitates setting environment variables like `http_proxy`, `https_proxy`, and `no_proxy` within your WSL2 shell's profile (e.g., `~/.bashrc` or `~/.zshrc`), using the host machine's IP address as the proxy target.

The specific mechanism hinges on network addressing. From within WSL2, the Windows host is accessible via a special IP address, which can be found in the `/etc/resolv.conf` file as the `nameserver` entry or by running `cat /etc/resolv.conf | grep nameserver | awk '{print $2}'`. The proxy variables should then be set to point to this address and the port on which your proxy software (e.g., Fiddler, Charles, or a corporate proxy) is listening on Windows. For instance, you would add lines such as `export http_proxy=http://<host_ip>:<proxy_port>` and `export https_proxy=$http_proxy` to your shell configuration file. Crucially, you must also configure your Windows proxy application to listen for requests from the WSL2 network adapter, which often means binding to all interfaces or explicitly allowing the WSL2 subnet, rather than just `localhost` or `127.0.0.1`.

Beyond the basic environment variables, several complicating factors must be addressed for robust functionality. First, certificate verification often fails for HTTPS traffic if the proxy uses a custom Certificate Authority (CA). This requires installing the proxy's root CA certificate into the WSL2 distribution's trust store, which is a separate process from Windows. Second, the `no_proxy` variable should be carefully populated to exclude localhost and internal Windows hostnames to prevent routing loops. Third, some applications, particularly those written in Go or using low-level system calls, may ignore the standard proxy environment variables, necessitating application-specific configuration. Furthermore, if the Windows firewall is active, it must be configured to allow inbound connections on the proxy port from the WSL2 virtual network, which is a distinct step from the proxy software's own settings.

The implications of this setup are significant for development workflows. It creates a bifurcated configuration management system where network settings must be maintained in both Windows and WSL2. Changes to the Windows proxy port or host firewall rules will break the WSL2 connectivity until the environment variables are updated. For users in corporate environments with authenticated proxies, the complexity increases, as credential passing between the subsystems is non-trivial and may require storing passwords in plaintext within WSL2 profile scripts, posing a security trade-off. Ultimately, while manually setting the proxy within WSL2 is the definitive method, it underscores the architectural reality of WSL2 as a separate, networked virtual machine rather than a seamlessly integrated layer, requiring explicit network bridge configuration for any proxy-dependent operations.