How to Route WSL2 Traffic Through Windows Clash: Mirror Networking and Localhost Setup (2026)

1. Mental Model: WSL2 vs Windows Network

WSL2 runs your Linux distribution inside a lightweight virtual machine. Traffic leaving that VM crosses a virtual switch to the Windows host. From the Linux side, “the internet” is reachable, but “the proxy process bound to 127.0.0.1 on Windows” is a different destination than “this shell’s 127.0.0.1.” Search queries like “WSL2 proxy” almost always boil down to discovering the correct host-facing address and port, then teaching command-line tools to use it—mirroring what you already do for browsers via system proxy or TUN, but with explicit env vars or tool-specific settings for the Linux environment.

Keep one invariant in mind: anything that only listens on Windows loopback (127.0.0.1) is invisible to WSL2 unless you add port forwarding or change the bind address. Clash GUI clients typically expose a mixed-port for HTTP and SOCKS; that listener must accept connections from the WSL virtual interface, not only from localhost on Windows, which is why “allow LAN” / bind-to-all-interfaces discussions show up in every thread on this topic.

If you already completed first-time setup for Verge Rev on the host, our Windows 11 Verge Rev system proxy and TUN walkthrough is the right prerequisite reading—you want a known-good profile, working logs, and a stable listener port before you chase WSL-specific symptoms.

2. Why 127.0.0.1 Is the Wrong Address

Inside WSL2, 127.0.0.1 refers to the Linux instance itself. A command such as curl http://127.0.0.1:7890 tries to open a connection to port 7890 inside the distro, not on Windows. Unless you run a proxy server inside WSL on that port, you will see “connection refused” or similar errors even while the same port works in a Windows browser pointing at 127.0.0.1.

Some guides suggest localhost “should” magically forward to the host. In default WSL2 networking, it does not solve the namespace problem by itself—you still need the host’s IP or an explicit forwarding mechanism. Treat any snippet that hard-codes 127.0.0.1:PORT for WSL2→Windows as suspect unless you have enabled a feature (such as mirrored mode with specific forwarding) that you have verified on your build.

The practical takeaway for terminal proxy configuration is simple: replace loopback with the routable Windows address you derive in the next section, then append your Clash HTTP or mixed-port number.

3. Finding the Windows Host IP from WSL2

The most common stable method is to read the default gateway inside WSL2—it is usually the host IP on the virtual network connecting the VM to Windows. For example:

ip route show default | awk '/default/ {print $3}'

Another frequently cited approach is inspecting /etc/resolv.conf for a nameserver line, which often points at the same host address Microsoft assigns for DNS forwarding. Either method can drift if networking modes change, so when you script your exports, recompute the IP at shell startup rather than pasting a literal from last month’s blog screenshot.

After you have a candidate address, sanity-check reachability: ping -c 1 <host-ip> should succeed in typical setups, and curl -v http://<host-ip>:<mixed-port> should at least complete TCP handshake to whatever your Clash listener returns for a bare HTTP probe (exact response body matters less than “not immediately refused”).

If your organization uses VPN software on Windows that reshapes routes aggressively, the gateway IP can still be right while specific ports are filtered—keep that distinction in mind before you rewrite YAML inside Linux.

4. Mirror Networking: What Changes

Recent WSL2 releases on Windows 11 introduce experimental mirror networking (sometimes described as “mirrored mode” or “networkingMode = mirrored” in .wslconfig). In that configuration, Microsoft aims to align the guest network stack more closely with the host’s interfaces. Users sometimes report that localhost forwarding or interface layout feels closer to “regular” desktop behavior, but the feature is still something you must validate per machine: builds, drivers, and corporate security agents interact with it unpredictably.

Do not assume mirror mode removes the need for a correctly bound Clash listener. Even when loopback mapping improves, your proxy port must still be reachable from the WSL side, and your client must still be configured to use HTTP CONNECT or SOCKS where appropriate. Treat mirror networking as a modifier that can simplify discovery—not as a substitute for explicit configuration and tests.

If you toggle mirror mode, rerun your host IP discovery commands and repeat the curl checks. Documentation drift between teammates is a frequent source of “works on my machine” confusion when half the office runs classic NAT-style WSL2 and half runs mirrored stacks.

5. Clash on Windows: Listen Address and LAN

For WSL2 to connect to Clash on the host, the listener that serves HTTP or mixed traffic cannot be restricted to 127.0.0.1 only. In Meta-style configurations, that maps to concepts such as allow-lan and binding the port to 0.0.0.0 (all interfaces) or to the specific address that accepts WSL traffic—exact YAML keys depend on your template, but the operational test is always the same: from WSL, can you open a TCP connection to host-ip:mixed-port?

Opening the listener wider than loopback has security implications on laptops that move between trusted and untrusted networks. Pair allow-lan with Windows Defender Firewall rules that scope access appropriately, and read our LAN sharing and Windows firewall article for a host-centric view of the same problem—WSL2 simply becomes another client on the virtual subnet.

If you rely on TUN mode on Windows to capture desktop applications, remember that WSL2 traffic is not magically “just another app” in every GUI stack. Many teams still use explicit HTTP/SOCKS env vars inside WSL even when TUN works for Chrome—because CLI tools and package managers follow libc proxy hooks or their own config files, not necessarily the same capture path as the browser.

6. Pointing Terminals at mixed-port (HTTP CONNECT)

Most developers standardize on the mixed-port because it accepts HTTP proxying and often SOCKS on one number—fewer moving parts than juggling separate ports for each protocol. For HTTPS traffic, clients issue HTTP CONNECT to that port; the scheme in your env vars remains http:// even when the remote site uses TLS.

export HOST_IP=$(ip route show default | awk '/default/ {print $3}')
export MIXED_PORT=7890
export http_proxy="http://${HOST_IP}:${MIXED_PORT}"
export https_proxy="http://${HOST_IP}:${MIXED_PORT}"
export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"
export ALL_PROXY="socks5://${HOST_IP}:${MIXED_PORT}"  # optional if your tools prefer SOCKS
export no_proxy="localhost,127.0.0.1,::1"
export NO_PROXY="$no_proxy"

Uppercase and lowercase variables both matter in the wild: some tools read only HTTPS_PROXY, others honor lowercase. Duplicating both avoids pointless debugging. Expand NO_PROXY with internal registry hosts and corporate Git endpoints so sensitive traffic does not accidentally traverse a public exit.

SOCKS versus HTTP can trip up newcomers. If a tool speaks SOCKS5, pointing it at an HTTP-only listener will fail; conversely, typical curl invocations work through HTTP CONNECT on the mixed listener. When in doubt, read the error string: “wrong version number” and TLS handshakes against a proxy port usually mean protocol mismatch, not censorship.

7. apt, Git, npm, and Persistent Shell Config

apt historically ignores generic env vars unless you configure Acquire::http::Proxy and Acquire::https::Proxy in a file under /etc/apt/apt.conf.d/, or use an inline -o option. Many teams generate a small snippet with the same http://host-ip:port pattern once they confirm connectivity with curl.

git respects http.proxy / https.proxy for HTTPS remotes. SSH remotes ([email protected]) ignore HTTP env vars unless you add a ProxyCommand or switch the remote to HTTPS. That distinction trips people who see “git works in browser credentials but not in terminal” when the browser used a PAC file and git used SSH.

Node ecosystems usually pick up HTTP_PROXY, but some corporate templates set npm config entries independently. Verify with npm config list and remember that global installs and CI scripts may unset inherited environments unless you export them in the same shell that launches the process.

Persist the exports in ~/.bashrc or ~/.zshrc, but guard against stale IPs: sourcing a hard-coded address breaks silently when Wi‑Fi subnets change. A tiny function that recomputes HOST_IP on interactive login trades a few milliseconds for fewer support tickets.

8. DNS, resolv.conf, and fake-ip Consistency

WSL2’s /etc/resolv.conf is often auto-generated and points at the Windows host for DNS forwarding. That is convenient, but it interacts with advanced Clash features on the host—especially fake-ip—in ways that confuse first-time users. If Windows resolves a name to a synthetic address while WSL resolves differently, you can see “connection works in one shell, fails in another” despite identical env vars.

When debugging, compare dig or getent hosts output inside WSL against the same query on Windows for the same hostname. If the answers diverge, fix DNS alignment on the host profile first; chasing WSL-only sysctl tweaks rarely pays off before the upstream resolver story is coherent.

If your subscription relies on domain-based rules, remember that HTTP CONNECT proxies can carry SNI information differently than transparent TUN captures. Use mihomo debug logs on Windows as ground truth: if the flow never appears, the packet never reached Clash; if it appears under the wrong policy, adjust rules rather than WSL.

9. Troubleshooting in a Fixed Order

Random tweaks waste time. Walk this sequence when WSL2 tools cannot reach the internet through Windows Clash:

For subscription fetch issues on the Windows side—distinct from WSL egress—see subscription update TLS and DNS troubleshooting, then return to WSL once the host profile is healthy.

10. Closing Thoughts

Routing WSL2 terminal traffic through Clash on Windows is less about exotic Linux hacks and more about naming the correct host address, exposing a listener that WSL can reach, and applying the same discipline you already use for rules and DNS on the desktop. Compared with juggling multiple standalone clients, reusing one maintained mihomo core keeps policy groups, audit logs, and subscription updates in a single place—similar to why teams prefer host-level proxies for Docker, but with a virtual NIC story that is unique to WSL.

Once the plumbing is verified with plain curl, layer tool-specific settings (apt, git, npm) deliberately rather than copying twenty conflicting snippets from outdated forum posts. The difference between a smooth workflow and a fragile one is almost always observability: read Windows-side logs when flows go missing, and reject fixes that cannot explain where the packet stopped.

When you are ready to align installers and updates from a single vetted entry point on the host, use our download center first, then fold WSL-friendly listeners and shell exports into your daily environment. → Download Clash for free and experience the difference