1. How this failure looks in real support threads

People describe the same story with different product names. The host can open YouTube, GitHub, or a subscription test page with Clash in system proxy or TUN mode. Inside the Windows virtual machine, the browser shows endless spinning, certificate warnings caused by captive portals, or “no route” errors. On Linux guests, apt update may fail with “Could not connect” to a mirror, and curl -I https://example.com hangs until it gives up. None of that proves Clash is broken; it often proves the guest is still trying to use the physical default gateway (your router) or a hypervisor NAT that does not forward to the host’s proxy port.

Your first job is to decide whether the guest should reach the host as a proxy endpoint (HTTP/SOCKS) or you expect transparent routing. Most readers want the smallest change: set the guest to use the host’s mixed port and enable allow-lan so Clash accepts connections from another IP on the LAN. The bridge/NAT section below tells you which virtual topology makes that IP stable and discoverable.

2. Bridge versus NAT: why your VM “cannot see” the host

In VMware and many other desktop hypervisors, the default shared or NAT mode puts the guest on an isolated private network. The host and guest can sometimes ping each other through special forwarding, but the guest’s view of “where is the internet” is a virtual router, not your home LAN. If you point the guest at 192.168.x.1 expecting your router while Clash only listens on a host loopback or a different interface, the traffic never touches Mihomo. Switching the virtual NIC to bridged (sometimes called “bridge mode”) makes the guest appear as another device on the same Ethernet or Wi-Fi segment as the host. It receives an address from the same DHCP pool and can use the same default gateway as the host—simpler reasoning for which IP is “the Windows machine running Clash.”

Hyper-V defaults to a virtual switch; an external switch bound to a physical adapter behaves like a bridge. An internal or private switch keeps guests in a private bubble unless you add NAT or routing. If the guest is on a private switch, you must still route to the host’s internal interface IP, not the address you use for ordinary browsing. Document the vNIC IP on the host and the guest IP in the same table before you edit proxy settings.

One more pitfall: some corporate Wi-Fi or public hotspots block multiple MAC addresses on one port, which breaks true bridging. If bridge mode fails in hotels or offices, fall back to double NAT (host NAT + guest NAT) and use explicit HTTP proxy toward the host-only or VMware Host-Only address listed in the hypervisor’s network editor. The principle stays the same: the guest must reach a routable host IP that Clash is allowed to accept.

3. Resolving the correct host address for the guest

On bridged or routed setups, run ipconfig on the Windows host and note the IPv4 address of the adapter that actually carries guest traffic (often “Ethernet” or “Wi-Fi,” not a disconnected TAP-only row). In PowerShell, Get-NetIPConfiguration is easier to read when you have many virtual adapters. The address you need is the one the guest would ping successfully—typically something like 192.168.1.42 on a home router LAN.

Avoid the loopback 127.0.0.1 for guest configuration; from inside the virtual machine, that always refers to the guest itself, not the host. If your documentation still says localhost:7890, that is a common reason Linux guests or Windows guests fail silently. Replace it with the host’s LAN address you discovered above.

4. Clash: allow-lan, bind address, and mixed port

Clash and Mihomo-class cores expose listeners such as port, socks-port, and mixed-port. A mixed port accepts both HTTP and SOCKS on the same TCP port, which keeps guest instructions short—browsers, curl --proxy, and many tools can share one value. In your config.yaml (exact keys depend on the core and GUI you use), ensure:

  • allow-lan: true (or the GUI equivalent) so connections from the LAN segment are not rejected.
  • The listener is bound to 0.0.0.0 or the specific LAN IP, not only 127.0.0.1, if you need off-host access.
  • mixed-port (or your chosen port) is consistent with the guest proxy settings and any firewall allow rule you add next.

Treat the mixed port as the single “front door” for virtual machines: HTTP traffic from Windows guests and ALL_PROXY style SOCKS from Linux guests can both target it, subject to the client. If you prefer separate 7890 and 7891 style ports, document both in a tiny table next to the guest’s OS. Our LAN proxy guide walks the same firewall pattern when phones or other PCs share the host; virtual machines are simply another LAN client once bridged.

5. Windows guest: system proxy and edge cases

In a Windows virtual machine, open Settings, search for Proxy, and under Manual setup set the address to the host’s IPv4 and the port to your mixed (or HTTP) port. If you use “Use setup script” or a PAC file from another environment, clear it; stale PACs override manual entries in confusing ways. For Store apps, remember UWP can ignore WinINET proxy; our UWP loopback article is relevant if only Store apps stay offline while classic Win32 browsers work.

Some enterprise images ship with a second VPN client or a security agent that sets its own filter driver. If Clash TUN is also enabled on the host while the guest uses manual proxy, you usually do not need TUN inside the guest. Keep the mental model: host Clash owns the path out; the guest only has to get TCP to the host’s proxy port first.

6. Linux guest: apt, environment variables, and systemd

For Ubuntu or Debian guests, export for a quick test: export http_proxy=http://<host-ip>:<port>/ and export https_proxy=... matching, plus export ALL_PROXY=socks5://<host-ip>:<port> if you standardize on SOCKS. Run curl -I https://www.google.com before touching apt. For persistent apt configuration, a file under /etc/apt/apt.conf.d/ with Acquire::http::Proxy and Acquire::https::Proxy lines is reliable when you want full-upgrade flows unattended.

Containers inside the guest are another hop: Docker Desktop in a Windows VM is rare, but LXC and nested Docker on Linux will inherit or ignore host environment in ways that mirror the WSL2 story. If nested daemons “cannot see” the host proxy, pass the same host-ip for the first-level guest, not an inner 172.17.0.1 guess, unless you have verified that bridge with ip route.

7. Windows Defender Firewall: inbound rule without guessing

When allow-lan is true and bind is correct, the guest may still get “connection refused” if the Windows firewall blocks inbound TCP to the proxy port. Create an inbound rule allowing the port for Private networks (or the profile that matches your Wi-Fi) and limit the scope to the subnet of your LAN if you want a tighter posture. After changing rules, test from the guest with Test-NetConnection <host-ip> -Port <port> in PowerShell or nc -vz <host-ip> <port> in Linux. A successful proxy handshake in Clash’s connection log is the best confirmation: you should see the guest’s source IP, not just loopback.

8. When you actually need default gateway (policy routing on the guest)

Explicit HTTP or SOCKS is enough for browsers and most CLI tools, but not for apps that open raw TCP without proxy awareness, or for ICMP-only diagnostics. A more advanced path is to set the default gateway on the guest to the host’s LAN IP and run a capture or redirection stack on the host. That design overlaps with a router or TUN on the host and is easy to get wrong, so for typical Clash use on a Windows virtual machine we still recommend the mixed-port, allow-lan, application-proxy approach first. If you are already all-in on TUN mode on the host, re-read the host routing table any time a VM stops working—overlapping 10.x or 198.18 ranges from the core can confuse the guest if you also assign manual static routes in the same space.

9. Field order that minimizes wasted time

When someone opens a thread saying “VMware or Hyper-V plus Clash is broken,” I walk through the same sequence. First, confirm the virtual NIC is bridged (or a documented route exists to the host) and guest-to-host ping works for the target IP. Second, on the host, verify allow-lan and the listener’s bind address. Third, from the guest, open TCP to the mixed port and watch Clash’s log. Only then, fourth, set guest proxy or apt environment. Fifth, if something still bypasses, check firewall profiles and UWP, then DNS inside the guest (a hijacked or stale resolver can look like a proxy failure).

If you import subscriptions rarely, a broken baseline makes every VM look broken—keep the subscription import path healthy before you blame networking.

10. Clash Verge Rev on the host: one place to see LAN clients

GUI clients that surface live connections are helpful because you can sort by source IP and see whether the Windows virtual machine is attached at all. The Clash Verge Rev setup guide remains the right primer for first-run permissions, core selection, and where the mixed port is displayed. If the log is empty when the guest browses, traffic never reached the core—go back to bridge/NAT and firewall, not to node selection.

11. How this article stays distinct from WSL2 and Docker pieces

WSL2 shares the Windows network stack in a very different way: localhost forwarding, resolv.conf, and the Windows–Linux boundary dominate. A full VM has its own kernel and ARP table; the mental model is closer to a second physical PC on a switch. Docker Desktop on macOS in our library targets container HTTP proxying on a different host OS, but the idea of “find the true gateway IP, then point HTTP clients at it” rhymes with what you are doing in VMware or Hyper-V guests once bridged. Keep those articles as cross-links rather than pasting the same steps here.

12. Security and trust boundaries

Opening allow-lan and an inbound port means any device on that LAN segment with network access can use your Clash instance unless you confine it with firewall scope or a dedicated VLAN. On lab networks that is often acceptable. On public Wi-Fi, prefer host-only or firewalled bridge alternatives and keep mixed-port exposure short-lived for testing. Citing the ecosystem’s open-source repositories for audits is fine, but use the site’s download path for the client installer, consistent with the rest of our troubleshooting content.

13. Summary: make the guest reach the same host the browser uses

VMware, Hyper-V, and other Windows guests fail with Clash when the virtual network isolates the guest or when 127.0.0.1 in the guest points nowhere useful. Use bridge (or a documented route), enable allow-lan and a mixed port on the host, set the real host IP in the guest’s proxy, and let Windows firewall admit the connection. When metrics line up, your guest curl and browser behave like the host’s—because they finally use the same Mihomo path by design, not by accident. For a clean install path and ongoing updates, → Download Clash for free and experience the difference