Tutorial · Estimated reading 17 mins

WSL2 Ubuntu via Windows Clash:
Mirror networking and apt proxy setup

Windows already runs Clash, yet apt update inside WSL2 Ubuntu still stalls, Git times out, and DNS looks “wrong.” This guide walks the full dual-stack path: how WSL2 reaches the host, how to point Ubuntu package manager traffic at Clash’s HTTP proxy, and how to keep resolv.conf predictable so resolver churn does not undo your work.

WSL2 · Ubuntu · Windows Clash · apt · DNS

1 Why WSL2 does not “just use” the Windows proxy

WSL2 is a lightweight virtual machine with its own Linux network namespace. Traffic from Ubuntu inside that VM does not automatically inherit the WinHTTP or “system proxy” settings that Internet Explorer and many Win32 applications honor. Clash for Windows, Clash Verge Rev, or any Mihomo-based GUI on the host listens on Windows interfaces; your Linux distribution must explicitly send HTTP, HTTPS, or SOCKS traffic toward that listener, usually by targeting the virtual Ethernet adapter that represents the Windows host from WSL’s point of view.

Package managers such as apt do not read http_proxy unless you configure APT’s Acquire directives or wrap the tool. Git and curl respect environment variables when they are exported, but only after every new shell session sees them. DNS is yet another layer: WSL often injects a nameserver line into /etc/resolv.conf that points at a resolver hosted on the Windows side. If that resolver disagrees with the DNS stack you configured inside Clash, you can resolve names to addresses that your proxy rules never match, which looks like “everything is broken except ping.”

The goal of this tutorial is not to duplicate generic Linux proxy advice. Instead, we connect the Windows side—where Clash already runs—to the Linux side with concrete file paths and verification commands. Keep security in mind: exposing Clash’s mixed port to non-localhost clients requires trust on your LAN segment; follow your organization’s policy when enabling Allow LAN or opening firewall rules.

2 Mirrored networking versus classic NAT

Historically, WSL2 placed the Linux guest behind a virtual NAT. The Windows host appeared at an address on the eth0 default route, and localhost on Linux did not mean the same thing as localhost on Windows. Microsoft has been evolving optional mirrored networking modes on recent Windows 11 builds so that more scenarios behave like a single machine: loopback forwarding and shared interface semantics can simplify tooling that expects identical loopback on both sides.

Whether you run mirrored mode or the older NAT layout, you still need a stable idea of “where is Clash listening?” and “which IP should WSL use to reach that listener?” Mirrored setups may allow you to hit 127.0.0.1 from WSL for certain forwarded ports, but behavior varies by build and by optional .wslconfig switches. For maximum portability across machines in a team, many administrators standardize on the explicit host IP from the default route instead of assuming loopback parity.

Document your team’s baseline: Windows version, WSL kernel package, and whether C:\Users\YourName\.wslconfig enables networking experiments. When something breaks after an Insider upgrade, you can compare notes instead of guessing whether mirrored mode changed the routing table inside the guest.

Practical rule: If curl http://127.0.0.1:7890 from WSL fails unpredictably across PCs, switch to the routed Windows host IP for Clash’s mixed port and keep that approach in your internal runbook.

3 Find the Windows host IP from WSL2 Ubuntu

The quickest reliable pattern on classic NAT WSL2 is to read the default gateway of the primary interface, which is usually the Windows host. Run ip route show | grep -m1 default and note the via address, or parse ip route | awk '/^default/ {print $3}' for scripting. Another common trick is inspecting /etc/resolv.conf for a nameserver line—WSL often sets this to the host resolver stub—but that value is a DNS forwarder, not always identical to the best IP for HTTP proxy traffic, so prefer the default route when they disagree.

Assign the address to a shell variable so you can paste fewer mistakes later, for example export WIN_HOST=$(ip route | awk '/^default/ {print $3; exit}'). Echo it, ping it lightly if your policy allows, and only then point http_proxy at http://${WIN_HOST}:7890 (replace 7890 with the mixed or HTTP port shown in your Clash client). If you script this in ~/.bashrc, guard against empty output when WSL starts before networking is ready.

Optional: resolve host.docker.internal

Some environments map host.docker.internal through WSL interop. Availability is not universal on pure Ubuntu WSL without Docker Desktop. Treat it as a convenience when present, not a contract.

4 Configure Clash on Windows for WSL access

Clash must accept connections from the WSL virtual switch, not only from 127.0.0.1. In Clash-compatible clients, enable Allow LAN (sometimes labeled “allow connections from the local network”) so the mixed port binds to 0.0.0.0 or the appropriate interface. Confirm the port number—7890 is a widespread default for mixed HTTP and SOCKS—and align your YAML or GUI profile so external-controller and API ports remain firewalled if you do not intend remote administration.

If you rely on TUN mode on Windows for some applications, remember that WSL traffic is still separate unless you adopt more advanced bridging strategies. This article focuses on explicit HTTP proxies for apt and environment-driven tools, which keeps mental models aligned with “WSL is a second computer behind the host.” For installation tips on the Windows side, see our Clash Verge Rev on Windows walkthrough.

Listen scope: Binding widely without a firewall invites adjacent-device access on public Wi-Fi. Combine Allow LAN with Windows Defender Firewall rules that restrict the source subnet to the WSL virtual NIC range when you are not at home.

5 apt proxy: Acquire::http::Proxy and friends

APT reads proxy settings from configuration fragments under /etc/apt/apt.conf.d/. Create a file such as 95proxies owned by root with directives that match your Clash listener scheme. HTTP and HTTPS repository traffic typically uses http:// proxy URLs even when the archive redirects to TLS, because APT handles transport negotiation separately.

sudo tee /etc/apt/apt.conf.d/95proxies
Acquire::http::Proxy  "http://192.168.192.1:7890/";
Acquire::https::Proxy "http://192.168.192.1:7890/";

Replace 192.168.192.1 with your measured Windows host IP and 7890 with your mixed port. If you only need a proxy for outbound HTTPS mirrors, some teams set only Acquire::https::Proxy; however, many Ubuntu mirrors still begin as HTTP redirects, so duplicating both lines reduces surprise failures during apt update.

To disable later, remove the file or comment the lines—APT does not cache proxy state across runs beyond what lives in those fragments. Combine this with locale-appropriate mirror selection: if your rules route certain countries differently, pick archive mirrors whose DNS names resolve consistently with your Clash DNS mode (FakeIP versus redir-host) to avoid TLS certificate mismatches when transparent interception is involved.

Authentication and corporate proxies

Rarely, an enterprise inserts an upstream authenticating proxy. APT supports embedded credentials in the proxy URL, but storing secrets in world-readable paths is poor hygiene. Prefer a dedicated service account machine or a lower-layer tunnel if policy allows.

6 Git, curl, wget, and interactive shells

After APT works, developers usually want Git and CLI downloads on the same path. Export uppercase proxy variables in ~/.bashrc or ~/.profile so non-interactive tools inherit them:

Shell exports
export WIN_HOST=$(ip route | awk '/^default/ {print $3; exit}')
export http_proxy="http://${WIN_HOST}:7890"
export https_proxy="http://${WIN_HOST}:7890"
export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"
export ALL_PROXY="socks5://${WIN_HOST}:7890"
export NO_PROXY="localhost,127.0.0.1,::1"

Git can also store http.proxy and https.proxy via git config --global, which helps GUI clients that do not inherit your shell. Test with curl -I https://www.example.com after exporting variables; you should see quick TLS completion and HTTP headers. If curl works but Git still hangs, inspect whether Git is using SSH remotes—SSH ignores HTTP proxies unless you ProxyCommand through something like nc or connect over port 443 with appropriate core.sshCommand overrides.

Container workflows sometimes spawn subprocesses without your login shell. When Docker inside WSL enters the picture, duplicate proxy settings in daemon JSON or build arguments; the mechanics differ from bare-metal Ubuntu. This article stays focused on distro tools first; once those succeed, container-specific guides are easier to apply.

7 resolv.conf stability and DNS alignment with Clash

WSL may regenerate /etc/resolv.conf whenever the instance starts. A nameserver entry that points to a Windows stub resolver can be correct, but if Clash uses FakeIP or custom upstreams, some names may resolve to placeholder ranges that only make sense when queries pass through Clash’s DNS pipeline. Misalignment shows up as “works in browser on Windows, fails inside WSL” even when proxies are right.

Ubuntu on WSL often ships a symlink from /etc/resolv.conf to ../run/systemd/resolve/stub-resolv.conf or a WSL-managed generator. To pin a static file, disable automatic generation in /etc/wsl.conf with [network] and generateResolvConf = false, then supply your own resolv.conf with nameservers you trust—sometimes a public resolver, sometimes the Windows host IP if you intentionally forward from there into Clash. This is powerful and easy to get wrong; snapshot your working file before experimenting.

/etc/wsl.conf (excerpt)
[network]
generateResolvConf = false

After disabling auto-generation, create /etc/resolv.conf manually with nameserver lines that match your DNS strategy. If you route all DNS through Clash on Windows, ensure WSL queries can reach that listener without creating a loop—typically by pointing at a resolver that forwards into Clash rather than duplicating FakeIP ranges inside Linux without the matching iptables or routing logic.

For deeper Mihomo DNS patterns—DoH, DoT, and leak-resistant FakeIP setups—our DNS leak prevention guide pairs well with this WSL baseline. The guiding principle remains one coherent resolver story end to end.

Avoid blind copying: Hard-coding 8.8.8.8 bypasses corporate inspection and may violate policy. Align with what your Clash profile and workplace rules require.

8 Windows Defender Firewall rules

Even with correct IP addresses, SYN packets from WSL can hit silent drops if Windows Firewall treats the virtual switch as a public profile without an allow rule for Clash’s executable or port. Create an inbound rule permitting TCP to your mixed port from the WSL subnet, scoped to private networks when possible. Re-test curl from WSL after each change; intermittent success often means overlapping “block” rules with higher priority.

Some security suites add their own filters above Defender. If you see single-direction packet captures in diagnostic tools, temporarily relax those filters in a controlled test window, document the vendor, and replace broad “allow all” with narrowed port and program rules once you identify the culprit.

9 Troubleshooting checklist

  • apt update returns 407: Upstream proxy authentication required—fix credentials or bypass path.
  • Works once per boot then stops: Host IP changed; recompute WIN_HOST or stop hard-coding stale addresses.
  • HTTPS errors after DNS edits: FakeIP mismatch—ensure Linux resolver and Clash DNS mode agree; revisit the DNS guide linked above.
  • Windows browser fast, WSL slow: Confirm Allow LAN and firewall; verify you targeted host IP not Windows loopback unless mirrored mode guarantees parity.
  • Corporate SSL inspection: Import your root CA into WSL’s trust store, not only Windows.

10 Wrap-up

Wiring WSL2 Ubuntu to a Clash instance on Windows is fundamentally an exercise in drawing one straight line through two stacks: discover how the guest reaches the host, expose the proxy listener safely, teach APT with Acquire directives, export shell variables for developer tools, and align DNS so name resolution does not contradict your rules. None of these steps is exotic on its own; the difficulty is keeping them consistent across reboots, kernel updates, and teammate laptops.

Compared with ad hoc VPN clients, Clash-compatible workflows give you structured logs, reproducible YAML, and the option to graduate to TUN on Windows when you need broader capture than manual proxies provide. When you are ready for that leap on the host OS, the Clash Verge Rev TUN mode guide explains how terminal and GUI traffic share one routing story—useful context even if WSL still uses explicit proxies for now.

If you have not settled on a Windows client build yet, grab a maintained installer from our download page so features like Allow LAN and readable connection logs are available from day one.

→ Download Clash for free and experience the difference

Tags: WSL2 Ubuntu Windows Clash apt proxy resolv.conf mirrored networking
Clash Verge Rev logo for WSL2 and Windows proxy

Clash Verge Rev

Next-gen Clash client · Free and open source

Run Clash on Windows with clear mixed-port settings, optional TUN, and logs you can trust—so WSL2, browsers, and IDEs share one routing policy instead of fighting each other.

TUN full traffic takeover Mihomo high-performance core Precise rule routing DNS leak helpers Multi-subscription management

Related reading