1 Two ways a Hyper-V guest can route through Clash
Hyper-V runs Type-1 hypervisor plumbing on Windows, yet from the guest’s perspective you still face the same split you would on a physical second PC. Applications fall into two buckets: those that speak HTTP(S) through a configurable proxy, and those that open ordinary sockets and rely on IP routing. Clash on the host can accept the first bucket via its mixed HTTP/SOCKS port when clients point at it explicitly. The second bucket only reaches Clash if something on the path performs policy routing—typically the guest’s default gateway is a machine that forwards into Clash, or you enable a transparent interception layer the guest does not need to understand.
System proxy inside Windows (or Linux) guest settings adjusts WinINET-style consumers, many browsers when set to “use system proxy,” and some runtimes that read http_proxy. It does not magically reroute ping, game clients, bespoke TCP tools, or Windows Update delivery optimization unless those components explicitly support proxies. That is why forum threads oscillate between “it works in Edge” and “PowerShell Invoke-WebRequest still times out” when only the GUI proxy toggle was changed.
Changing the guest’s default gateway to the Hyper-V host (or another router that sends traffic into Clash) pushes the entire IP forwarding decision upward. In home labs people sometimes point the default gateway at the host’s internal Hyper-V interface address and enable forwarding or a dedicated redirector; in corporate networks you would rarely do this without explicit approval. This article assumes a personal workstation where you control both host and guest and can accept the security trade-offs of exposing a local proxy listener.
2 Default switch NAT versus an external bridged vSwitch
The built-in Default Switch in modern Hyper-V is a NAT-style attachment: the guest receives a private address, and Hyper-V performs outbound NAT through the host’s primary connectivity. The guest’s default gateway is usually an address on that synthetic network that represents the Hyper-V host from the guest’s routing table. That address is not the same as your Wi-Fi router on the LAN; it is an internal hop managed by the hypervisor.
When you create an external virtual switch bound to a physical NIC, the VM can sit directly on the same Ethernet broadcast domain as the host—functionally similar to bridging. In that layout the guest often gets DHCP from the same upstream router as the PC, and “the host” is simply another neighbor with a routable LAN IP. You point proxy clients at that LAN IP (for example 192.168.1.42:7890) instead of hunting for a synthetic gateway address.
Both designs can work with Clash; they differ in how you discover the host IP and whether multicast or broadcast expectations match your tooling. NAT is convenient for quick sandboxes; bridging is easier when you want the VM to behave like another laptop on the office subnet—at the cost of consuming a MAC address and possibly triggering network access control policies.
Why “just use the same gateway as the host” confuses people
On NAT, the guest’s default gateway is already the Hyper-V NAT endpoint. Replacing it blindly with your Wi-Fi router may break outbound connectivity unless you understand split routing. On a bridge, the guest’s gateway is often the Wi-Fi router, and Clash on the host is not on that path unless you add policy routes or move the interception point. Match instructions to your actual vSwitch type before copying random screenshots.
3 Locate the Windows host IP from inside the VM
For a NAT-backed guest, open PowerShell or Command Prompt and inspect the route table: route print 0.0.0.0 or Get-NetRoute -DestinationPrefix 0.0.0.0/0. The gateway field on the default route typically corresponds to the host-side interface that performs NAT. You can also read IPv4 details with ipconfig /all and look for the adapter that carries the private Hyper-V prefix (often 172.x or 192.168.x depending on build and configuration).
For a bridged guest, identify the host by its LAN address—ping it by machine name if DNS resolution works, or read the lease table on your router. The IP you need is the one where Clash’s mixed port listens after Allow LAN is enabled. If you enabled binding only on loopback, LAN clients will fail until you widen the bind address in the client or YAML allow-lan equivalent.
Linux guests follow the same pattern: ip route for the default via address on NAT, or interface address correlation on a bridge. Document the value you used; Hyper-V NAT gateways can change across major upgrades or when you recreate virtual switches.
4 Enable Allow LAN and pick a consistent port
Clash-compatible GUIs expose Allow LAN so the mixed HTTP and SOCKS listener accepts connections from non-loopback addresses. Without it, only the host loopback can connect, which is why guests appear “dead” even when the proxy works locally. Pair this with a known port—7890 is a common default for mixed mode—and keep the same number in your guest proxy settings.
Treat the mixed port like a local service boundary: anyone who can reach that TCP port on your host can tunnel traffic through your subscription. On untrusted networks, tighten Windows Defender Firewall rules so only the Hyper-V virtual subnet or your home RFC1918 range is permitted. Our Windows 11 firewall walkthrough explains how Private versus Public profiles interact with those rules.
0.0.0.0/0, when you can.
5 Path A: steer the guest default gateway toward interception
Pointing the guest default gateway at the host is the classic “router on a stick” pattern shrunk to a workstation. Conceptually, every packet the VM emits toward the wider Internet first arrives at the host; the host must then decide whether to forward, drop, or redirect it into Clash. Windows does not ship a one-click “send all Hyper-V child traffic through Clash” toggle—you still need either OS forwarding plus policy routing, a dedicated small router VM, or transparent redirection that Clash’s TUN stack can see on the host.
Many advanced users skip full gateway surgery and instead run Clash in TUN mode on the host while simultaneously using an explicit proxy from the guest. That hybrid is not contradictory: TUN captures host processes elegantly, but Hyper-V guest packets are encapsulated; they do not automatically traverse the host TUN adapter unless you design for it. If your goal is “guest browsers + apt + git,” explicit proxy to the host mixed port is simpler than re-architecting L3 forwarding.
When you truly need default-route takeover inside the guest, validate that the host forwards and that Clash (or a companion tool) receives the flows. Misconfigured forwarding loops can soft-brick networking until you revert adapter settings from Hyper-V console—not a fun recovery on a remote machine.
Relationship to corporate VPNs
Enterprise VPN clients often install competing routes. If the host VPN sends 0.0.0.0/0 into a virtual tunnel, guest traffic that hairpins through the host may suddenly match different policies. For split-tunnel nuance on Windows, see our corporate VPN and split tunneling article before mixing Hyper-V labs with work laptops.
6 Path B: system proxy and explicit application settings
The lighter-weight approach keeps the guest’s default route untouched and teaches individual stacks to use the host as an HTTP or SOCKS proxy. In Windows guests, open Settings → Network & Internet → Proxy, disable misleading “automatic” scripts if they fight your manual endpoint, and set the manual proxy address to the host IP with the Clash mixed port. Edge and Chromium derivatives will follow when configured to use the system proxy; Firefox maintains its own dialog if you prefer isolation.
Developers should also set environment variables in shells: HTTP_PROXY, HTTPS_PROXY, and optionally ALL_PROXY for SOCKS. Package managers differ—some read npm config, some need Acquire::http::Proxy on Debian-derived Linux guests. The pattern matches what we documented for WSL2 Ubuntu reaching Windows Clash, except your guest is a full Hyper-V VM with its own kernel instead of WSL’s lightweight utility VM.
Store apps and certain WinRT components historically ignored WinINET proxy settings. If a specific client still bypasses, check whether it is a loopback-restricted UWP app; our UWP loopback checklist covers the CheckNetIsolation workaround space—still relevant inside Hyper-V Windows guests running Store-distributed tools.
# Replace HOST_IP and PORT with your Clash mixed listener
$proxy = "http://HOST_IP:PORT"
Invoke-WebRequest https://example.com -Proxy $proxy -ProxyUseDefaultCredentials7 Why host-only TUN does not replace guest configuration
TUN mode on Windows elevates Clash into the routing path for processes that honor the host kernel forwarding rules. Hyper-V networking, however, presents virtual NICs with separate offload paths. Guest egress may leave the VM encapsulated, reach the physical NIC through the vSwitch, and never intersect the TUN adapter you stared at in the Clash dashboard. That observation fuels endless “but TUN is on” tickets where packet captures on the host show guest traffic bypassing the intended mark.
If you require uniform interception without per-app proxy settings, you may need a design where the interception point sits before or inside the guest—examples include running a Clash or Mihomo instance directly in the VM, using a upstream router with policy routing, or adopting nested virtualization strategies that exceed the scope of a single blog post. For most readers, explicit proxy to the host remains the lowest-friction compromise.
8 Windows Defender Firewall and Hyper-V traffic
Even correct IP and port pairs fail when Defender Firewall treats the vSwitch as Public and applies a default deny to your Clash executable’s inbound listener. Create allow rules tied to the program path (for example the Mihomo binary your GUI launches) and scope source addresses to the guest subnet. After editing rules, restart the Clash core once so the listener rebinds cleanly.
Third-party endpoint protection may add kernel filters above Defender. Symptom pattern: SYN packets reach the host interface in Wireshark but never arrive at the Clash log. Temporarily relax the suite in a controlled test, document the vendor, then replace broad allows with narrow port-based rules.
9 Verification checklist before you blame the subscription
- Port probe from guest:
Test-NetConnection HOST_IP -Port 7890(adjust port) should returnTcpTestSucceeded : True. - Clash logs: Live connections should increment when the guest loads a page; silence means the traffic never hit the listener.
- DNS split-brain: If domains resolve to unexpected addresses, align guest DNS with your Clash DNS mode (FakeIP versus redir-host) using the DNS leak prevention guide.
- Dual proxies: Remove obsolete PAC files when switching to manual host IP; stale PAC entries send traffic into dead endpoints.
- IPv6: If the guest prefers AAAA records but your proxy path is IPv4-only, either disable IPv6 temporarily for testing or extend the proxy path to handle both address families consistently.
10 Wrap-up
Hyper-V does not magically inherit Clash settings from the host: you choose whether each guest application uses an explicit proxy toward the host’s mixed port or whether you re-engineer routing so the guest default gateway feeds interception. NAT and external vSwitches determine which IP represents the host from the VM—mixing instructions between the two layouts is the fastest way to chase ghosts. Enable Allow LAN, document your listener port, and pair it with firewall rules that respect the Hyper-V subnet without exposing the proxy to the entire coffee-shop VLAN.
Compared with ad hoc VPN clients, Clash and Mihomo give you structured logs, reproducible YAML, and a gradual path from manual proxy to TUN on the host when you truly need broader capture. For a clean Windows install baseline before you layer Hyper-V on top, follow our Clash Verge Rev Windows setup so features like Allow LAN and readable connection traces are ready on day one.
When you want installers and platform-specific notes in one place instead of hunting GitHub releases, use the site’s download page as the primary entry point—then return to Hyper-V and validate guest connectivity with the checklist above.
