Route VM Traffic Through Host Clash: VMware and Parallels Bridge, NAT, and Proxy Steps

Why guest VMs differ from WSL2

Articles that target WSL2 describe a lightweight utility VM with mirrored or NAT networking tightly coupled to the host stack. A desktop-grade Linux or Windows guest under VMware or Parallels behaves like another machine on a cable: it may live behind the hypervisor’s NAT, sit on your LAN with its own DHCP lease, or sit on an isolated segment that never sees your router. Clash on the host does not magically “include” that guest unless packets can reach the host IP and port you configured, and unless return traffic is routed back correctly.

If you already use WSL2 with Clash, keep that playbook separate—start from the WSL2 and Windows Clash guide for that environment. Here we focus on intentional VM networking and two integration patterns:

• Application proxy: the guest is told “send HTTP(S) and SOCKS through HOST_IP:PORT.” Minimal routing change; only apps that honor proxy settings or env vars use Clash.
• Gateway / transparent path: the guest’s default gateway or selective static routes send traffic to the host (or through the host as the next hop), and Clash must accept LAN connections and apply rules to those flows—usually with TUN or a redirect stack on the host, depending on OS.

Bridged, NAT, shared, and host-only in one table

Hypervisors reuse the same vocabulary but label menus differently. The important question is always: Can the guest open a TCP connection to the host’s Clash listener without crossing unsupported NAT hairpins?

Mode	Guest view	Reaching host Clash
Bridged	Looks like another device on the LAN; often gets a DHCP address from the same router as the host.	Use the host’s LAN IP (same subnet). Straightforward for mixed-port proxy; watch OS firewalls.
NAT / shared / “Internet sharing”	Private hypervisor subnet; outbound masqueraded through the host’s external interface.	Typically use the default gateway IP shown inside the guest (often a .1 or .2 on the vmnet)—that is the host-side virtual router. Confirm with ip route or ipconfig.
Host-only	Can talk to the host and other VMs on the same vmnet, not the public Internet.	Fine for lab proxy tests; you still point at the host-facing IP on that vmnet. No Internet unless you add a second NIC or custom routing.

On macOS, Parallels “Shared Network” and VMware Fusion’s “Share with My Mac” behave like NAT. “Bridged” exposes the guest on the physical LAN. On Windows, VMware Workstation’s VMnet8 (NAT) and VMnet1 (host-only) follow the same logic: learn the guest’s default gateway address and treat it as the path to the host services you expose.

Host baseline: mixed port, Allow LAN, and bindings

Before touching the VM, stabilize Clash on the host. The guest will connect to a TCP port on an address the host actually listens on—commonly the mixed listener for HTTP and SOCKS on one port. You must allow remote (LAN) clients if the guest is not the same OS namespace as loopback-only listeners.

Concrete checklist on the host:

• Enable Allow LAN (or equivalent) so Clash binds beyond 127.0.0.1 where your client expects it.
• Note the mixed port number and protocol support your GUI exposes; many setups use one port for both HTTP proxy and SOCKS5.
• If you run TUN mode on the host, it intercepts traffic originating on the host. It does not replace the need for the guest to route or proxy toward the host unless you build a more advanced forwarding design.

For firewall and binding details, read the Allow LAN and mixed port guide next to your OS documentation. Windows users should also skim the Clash for Windows setup article; macOS users should confirm permissions using the Clash Verge Rev macOS walkthrough.

Path A — Explicit proxy inside the guest

This is the fastest way to get curl, package managers, and browsers through Clash. Steps:

Keep DNS in mind: with an HTTP proxy, many clients tunnel DNS resolution through the proxy; others still use the guest resolver. If sites load but names fail, align guest DNS with a resolver that matches your Clash DNS mode or enable DoH inside the guest. For fake-ip mismatches on the host side, see the DNS and fake-ip troubleshooting page.

Path B — Default route or selective static routes via the host

Some workloads ignore proxies: custom UDP tools, certain installers, or language package ecosystems that spawn helpers. You can send all default traffic from the guest through the host by making the host the guest’s gateway and enabling forwarding—but this is heavier: you are now responsible for NAT, reverse path filtering, and sometimes ICMP behavior.

A lighter compromise is policy routing on the guest: keep the hypervisor default gateway for general Internet, add a static route for a problematic subnet via the host IP, or use iptables / Windows forwarding only after you know exactly which prefixes must traverse Clash. On the host, Clash TUN can pick up forwarded packets only if the OS forwards them into the TUN stack; not every desktop Clash deployment documents that as a one-click feature, so validate with packet captures before relying on it in production.

Most readers who need “everything in the VM exits through my airport node” still combine explicit proxy for package managers plus a small set of static routes or a second NIC bridged to LAN for management—rather than re-home the entire default gateway away from the hypervisor NAT.

VMware Workstation and Fusion specifics

VMware Workstation (Windows/Linux host): open Virtual Network Editor to see VMnet definitions. NAT networks expose a gateway IP—guests should use that gateway to reach the host services listening on the NAT-side interface. Bridged mode maps the guest to a physical adapter; use the host’s address on that same broadcast domain. If connections time out, suspect Windows Defender Firewall profiles: allow inbound TCP on your Clash port for Private networks or add a scoped rule.

VMware Fusion (macOS host): network labels mirror the same ideas. After macOS major upgrades, recheck privacy prompts for network extensions if you run Clash with system extension–based TUN. Fusion’s NAT still presents a gateway IP to the guest—use it as the proxy target when the guest cannot see the Mac’s Wi-Fi IP directly.

Parallels Desktop specifics

Parallels exposes Shared, Bridged, and Host-Only networking profiles similar to other hypervisors. Shared mode is the comfortable default for Internet access; the guest reaches the Mac through Parallels’ virtual router. For the lowest-friction Clash integration, switch to Bridged when corporate Wi-Fi policies allow it—then the guest and Mac share a subnet and you can point proxy settings at the Mac’s LAN IP directly.

If you must stay on Shared mode, discover the gateway IP inside the guest (often visible as the default route next hop) and use that as the proxy hostname. Parallels Tools can change how clipboard and drive sharing work, but they do not remove the need for correct TCP connectivity to the mixed port.

TUN on the host and DNS for guests

TUN mode on the host creates a virtual interface and steering rules so local processes hit Clash before exiting to the physical NIC. Guests do not automatically inherit that tunnel. Treat host TUN as orthogonal: you still need a reachable HOST:PORT or a forwarding path. Where TUN indirectly helps is when the host itself must resolve names consistently with fake-ip or redir-host policies—those choices influence what you expect when the guest uses the host as an HTTP proxy, because the proxy may perform CONNECT requests with different DNS semantics.

Recommended habit: pick one DNS story per workload. If the guest uses explicit HTTP proxy to Clash, let Clash resolve names for tunneled HTTPS. If the guest resolves locally, ensure its resolver is not fighting your rule set (split DNS, captive portals, or ISP hijacks). For terminal workflows across OSes, the terminal, HTTP, and git proxy article complements this page.

Firewalls, VPNs on the host, and double NAT

Three recurring breakages:

• Host VPN alongside Clash: a full-tunnel corporate VPN on the Mac or PC can steal default routes and block LAN peers from reaching your mixed port. Pause the VPN to test, or add split tunneling exclusions.
• Inbound firewall rules: allowing Clash locally does not imply allowing the vmnet subnet. Add explicit allow rules for the guest network prefix.
• Double NAT confusion: NAT inside the guest (docker default bridge) plus hypervisor NAT means you may need to proxy from the inner network too—sometimes it is simpler to run Docker on the host and keep the VM lean.

FAQ

Guest can ping the host but proxy times out

ICMP succeeding does not prove TCP to your mixed port is allowed. Check Clash bind address, Allow LAN, and OS firewall profiles port-by-port.

Downloads are slow through the VM

Compare the same node using curl on the host versus curl in the guest. If only the guest is slow, suspect virtio driver settings, CPU throttling, or disk backing store—not Clash itself.

Bridged mode is blocked on public Wi-Fi

Fall back to NAT/shared networking and use the virtual gateway IP as your proxy target; accept that discovery is slightly more annoying but connectivity is still fine.

Checklist before you blame the subscription

Get a maintainable client on the host

VM networking already has enough moving parts; your Clash surface should stay predictable—clear listeners, explicit LAN toggles, and logs that show which adapter accepted a connection. Once the host side is boring, VMware and Parallels guests become just another consumer of your mixed port.

Download Clash for free and experience the difference