Hyper-V VMs Through Windows Host Clash: NAT, Gateway, and Firewall Steps (2026)

Pick your mental model: whole-VM egress vs proxy hop

Two legitimate architectures show up in search threads, and mixing them wastes weekends. The first is application-level proxying: the guest OS (Windows or Linux) points browsers, package managers, or system proxy settings at HOST_IP:PORT where the host runs Clash’s HTTP or mixed listener. The second is full default-route steering: you expect every packet leaving the VM to traverse the host as a router, often paired with TUN-like behavior on the host side. Clash on Windows is excellent at the first pattern and tolerates parts of the second when you understand what the stack can actually see. This article leads with the proxy hop because it matches how most Clash derivatives expose mixed-port or 7890-class listeners, and it fails in ways you can log. If you need global capture inside the guest comparable to host TUN, you still end up running a client inside the VM or accepting complex routing—neither is “just set gateway” on a NAT switch without consequences.

Also separate VMware Workstation muscle memory from Hyper‑V. Workstation’s bridged and NAT modes are familiar, but Microsoft’s default virtual switch story uses different adapter names, DHCP scopes, and host addresses. A recipe that worked on VMware NAT may need different IP discovery on Hyper‑V; the troubleshooting section calls that out so you do not cargo-cult old forum posts.

How Hyper‑V NAT changes the address book

When you attach a VM to the built-in Default Switch or a user-defined internal switch with Internet Connection Sharing or NAT enabled, the guest receives an address from a private scope (commonly 172.x space) and a default gateway that belongs to the NAT service—not always the same string you would guess from a quick glance at the host’s Wi‑Fi IP. The Windows host still owns a vEthernet interface for that switch, and that interface’s IPv4 address is typically what you target when you want the guest to reach a service bound on the host. People say “use the host IP” and stop; power users write down both the guest’s gateway and the host vEthernet address, then confirm which one answers TCP on the Clash port.

If you use an external virtual switch instead, the VM may sit on the same LAN as your router like a second physical PC. In that layout, the guest’s default gateway is often your home router, and the “host IP” for a Clash hop is simply the host machine’s LAN address—as long as nothing else blocks intra-LAN hops. Firewall scope still matters: Windows Defender Firewall distinguishes profiles, and a rule that allowed Wi‑Fi chatter may need revisiting when the source is another IP on Ethernet or a bridged Hyper‑V NIC.

Before chasing Clash settings, sketch your switch type on paper. Wrong diagram, wrong remediation—especially when someone enabled both Wi‑Fi and bridged VMs and accidentally split horizons.

Step 1 — Discover IPv4 endpoints on host and guest

On the physical Windows machine, open Terminal as your normal workflow allows and run ipconfig /all. Identify adapters whose descriptions mention Hyper‑V Virtual Ethernet, vEthernet, or your named virtual switch. Note the IPv4 address tied to the switch servicing your VM—for example something like 172.26.192.1 on a common default switch layout, but your network decides the truth. That candidate is often the address you aim shell tools at from inside the guest.

Inside the guest, record the VM’s own IPv4, subnet mask, and default gateway. On Windows guests, ipconfig suffices; on Linux guests, ip route and ip addr show the same reality. If the guest’s gateway does not match the host vEthernet you expect, pause: you might be looking at the wrong virtual adapter on the host (multiple switches) or a stale static configuration in the guest from an old lab.

Sanity tip: from the guest, try ping toward the host vEthernet IP. If ICMP is blocked or filtered, failure proves nothing about Clash. Prefer Test-NetConnection TARGET -Port PORT on Windows guests or curl -v --proxy once you know the listener is up. This alone prevents the most common “ping does not work so proxy is dead” fallacy.

Step 2 — Prepare Clash on the host (listener, allow-lan, bind)

Confirm the host-side client—often Clash Verge Rev with a Mihomo-class core—is running and that a browser on the host already honors your profile. Open the active configuration or GUI and read the real numbers: mixed-port or separate port and socks-port. Marketing defaults still say 7890; your machine may use 7897 or another merge-safe value. If you have never hardened the Windows install, walk the Windows 11 first-setup article first so you are not debugging two layers at once.

Enable allow-lan (or equivalent YAML allow-lan: true) and ensure the listener is not restricted to 127.0.0.1 only. GUI clients sometimes label this “Allow LAN” or similar; YAML-oriented users set bind-address to * or 0.0.0.0 when schema permits. Apply or restart the core so the runtime actually opens the socket. If local browsing on the host breaks after toggles, undo methodically—you may have introduced a profile error, not a Hyper‑V mystery.

For vocabulary on how rules pick exits after traffic reaches the proxy, skim the site Clash tutorial and, when you need group semantics, the proxy-groups guide. The VM use case does not change YAML physics; it only changes where packets originate.

Step 3 — Windows Firewall: allow inbound TCP to the listener

Even correct allow-lan settings fail when Windows Defender Firewall discards SYN packets from another interface. Create a deliberate inbound rule for the TCP port your mixed or HTTP listener uses. The flow mirrors the LAN phone guide, but the “remote” client is now a Hyper‑V NIC rather than a handset.

1. 1

   Open the advanced firewall console

   Press Win + R, run wf.msc, select Inbound Rules, and choose New Rule.

2. 2

   Port rule for TCP

   Choose Port → TCP → Specific local ports → enter your real mixed or HTTP port (example: 7897). If HTTP and SOCKS differ and both must be exposed, create two rules—future you will thank present you during audits.

3. 3

   Allow and scope

   Select Allow the connection. On the profile page, prefer Private unless you truly need Public exposure; Hyper‑V lab traffic is usually private to the machine, but misclassified networks happen after travel—re-check the active profile if nothing hits the rule counters.

4. 4

   Name and document

   Label the rule like Clash mixed 7897 from Hyper-V. When ports change, disable stale rules to avoid phantom debugging.

Endpoint security suites occasionally layer their own kernel filters. If Windows shows the port listening but counters never tick, check whether a third-party firewall still blocks the path and whether the rule targets the correct executable path for your Clash-based binary.

Step 4 — Aim the guest at the host proxy

Windows guest: Settings → Network → Proxy → manual server, pointing to the host vEthernet IPv4 and your mixed port. Some enterprises prefer netsh or PAC files; the address math is identical. Linux guest: export http_proxy and https_proxy to http://HOST:PORT, or configure Desktop environment proxy panes. For shells only, match the environment variable style your distro expects; duplicate uppercase and lowercase variants when tools disagree.

Explicitly set NO_PROXY for local names so internal services do not hairpin through a foreign node. If you manage multiple VMs, consider small per-VM notes on which host port you standardized—labs rot quickly when three profiles disagree on 7890 versus 7897.

This is also the right time to compare with WSL2: WSL2 uses its own virtual switch and host discovery tricks, while Hyper‑V guests use different IPv4 wiring. If you tried to paste WSL’s $(ip route) output into a Hyper‑V Ubuntu VM, you already felt the mismatch; treat each platform’s host IP as a fresh measurement.

Step 5 — Validate with TCP and logs, not vibes

From the guest, open a browser through the proxy or run curl -I https://example.com with proxy flags. On the host, watch the Clash client’s connections or logs. You should see flows whose source IP matches the guest. Silence means the SYN never arrived—return to bind, firewall, or wrong host IP. Entries with REJECT or unexpected groups mean your YAML rules, not Hyper‑V, deserve the next edit; the custom rules tutorial shows how to keep overrides merge-safe across subscription refreshes.

If HTTPS works for some sites and not others, compare DNS behavior between guest resolver and Clash’s fake-ip mode. Misaligned DNS often masquerades as “proxy broken.” For deeper transport context on how TUN differs from manual proxies when apps ignore settings, read Clash TUN mode explained—the mental model ports to planning whether you also need a guest-side client for stubborn apps.

When people talk about changing the default gateway

Sometimes threads recommend setting the VM’s default gateway to the host address so “everything” flows through it. In a simple NAT lab, the guest already has a gateway for Internet access; replacing it blindly can break plain connectivity unless the host actually routes and NATs the way you assume. If your goal is only to use Clash’s SOCKS or HTTP listener, you usually do not need to rewrite the guest’s default route—point applications or OS proxy settings at the host port instead. Full routing scenarios belong in network engineering territory: IP forwarding on Windows, duplicate NAT, and possibly running Clash in TUN with policies that include the Hyper‑V subnet. Document requirements before flipping gateway fields in production guests.

If you truly run a dual-homed design—VM subnet dedicated to lab traffic—write down the intended packet walk: guest → host vEthernet → Clash listener → outbound per rules. Any step that lacks a matching return path will surface as asymmetric weirdness in traceroute and connection logs.

Why ping fails even when the browser works

ICMP echo requests are not the same class as TCP to port 7897. Windows Firewall ships with separate defaults; some administrators block ping to reduce noise. Hyper‑V itself does not guarantee ICMP success as a proxy for application health. Use port tests, application logs, and connection tables. If you must prove L3 reachability without Clash, try ping after temporarily allowing ICMP for diagnostics, but do not treat it as a Clash readiness gate.

NAT also rewrites addresses; source-NAT on the way out can confuse beginners who expect to see the guest’s raw address on upstream captures. Trust the host tool’s view of sessions—what entered the proxy listener—not an outdated mental model of transparent Ethernet taps.

Split routing and policy after traffic hits the host

Once the guest successfully connects to the host listener, split routing behaves like any other client: your rules list decides DIRECT versus proxy outbounds. Keep high-priority DOMAIN or GEOSITE slices for domestic or LAN targets ahead of catch-all MATCH if that matches your policy. Nothing about Hyper‑V changes the order of operations inside YAML—only the client IP in logs reminds you the traffic came from a VM.

Subscription health still matters: if the host cannot refresh nodes, every dependent VM session fails in sync. When remote URLs error, consult subscription links FAQ before assuming virtual switch regression.

VMware and other hypervisors in one paragraph

If you landed here from a VMware search: bridged mode often makes the guest’s gateway your router while the host’s LAN IP still hosts Clash—firewall rules must allow that guest-to-host hop. NAT mode resembles Hyper‑V’s NAT story but with different adapter names. Re-measure IP addresses per product; do not reuse Hyper‑V numbers by rote.

Security and housekeeping

Exposing a proxy listener beyond loopback increases LAN-adjacent risk—every VM on an allowed switch can attempt connections. Disable allow-lan when you finish lab work, delete obsolete inbound rules, and avoid binding broadly on untrusted hotel networks. Treat Clash as network software you operate, not a lucky toggle.

Open-source repositories remain the right place for protocol and issue discussion; for installers, keep using the site’s download flow so readers do not confuse release artifacts with support policy. The project’s GitHub presence can supplement transparency without replacing the primary install path.

Pulling the threads together

Reliable Hyper‑V access to a Windows Clash hop is a straight sequence: classify your virtual switch and NAT layout, read the host vEthernet IPv4 and guest parameters without mixing in WSL2 shortcuts, enable allow-lan on the real listener port, add a narrow Windows Firewall inbound rule, then aim the guest’s proxy settings and confirm with logs. Skip ping superstition, treat default gateway edits as an advanced fork, and keep split routing policy in YAML where it already belongs. Compared with mystery toggles, that checklist turns high-intent searches—Hyper‑V, VM, host proxy, firewall—into something you can reproduce the next time you rebuild a lab.

When you want a maintained Windows client to anchor the workflow, use this site’s download page for installers—Download Clash for free and experience the difference.