The symptom: host works, VMware guest does not
You open Edge or Safari on the physical machine and everything flows through Clash as expected. Inside VMware Workstation, Player, or Fusion, the same website spins, ping 8.8.8.8 might even succeed, yet HTTPS fails or curl hangs on TLS. That split is normal: the hypervisor presents a virtual NIC with its own default route, resolver configuration, and ARP neighborhood. Nothing in the guest magically reads the host’s proxy PAC file unless you configure it.
The fix is not “install another VPN inside the guest.” In most labs you already have a working core on the host; you only need a reachable HTTP proxy or SOCKS5 hop and a consistent story about which IP address labels the host from inside the VM. Once that hop answers TCP, browsers, package managers, and containers can share the same path—similar in spirit to how we bridge WSL2 terminals to a Windows listener in our WSL2 and Windows Clash port guide, except the guest here is a full VMware VM instead of a lightweight utility VM.
NAT versus bridged: where the default gateway points
With VMware NAT, the guest typically receives an address on a private segment such as 192.168.x.0/24 served by a virtual router that VMware implements on the host. The virtual machine gateway is almost always the .1 or .2 address on that segment (VMware documents vary by product version; treat the value shown by ip route or ipconfig as ground truth, not forum folklore). Traffic destined for the internet is masqueraded through the host’s physical interface, but that path still bypasses your Clash process unless the host OS routes into the TUN adapter or unless applications send explicit proxy requests.
Bridged mode places the guest on the same L2 segment as the host’s NIC. The guest gets a DHCP lease from the real router and often sees the LAN gateway you already recognize from the host. Reachability is simpler—you can sometimes use the host’s LAN IP directly—but hotel and corporate networks with client isolation may block VM MAC addresses or neighbor discovery, so NAT remains popular for predictable lab work.
Rule of thumb: If you can ping the host IP from the guest but proxy TCP fails, suspect bind address or firewall before you rewrite routing tables.
Stabilize Clash on the host first
Confirm the Meta-class core is healthy in a desktop browser on the host with your ordinary mode—system proxy or TUN—before you touch VMware. If the profile is broken upstairs, the guest will inherit only your confusion. On Windows, our Clash Verge Rev Windows setup guide covers installer basics; on macOS, pair it with the system proxy and helper notes for Verge Rev so elevated pieces actually start when you expect them to.
Note the mixed listener port from the UI or YAML—7890 is common, but vendors ship other defaults. You will reuse that number when you build http://HOST:PORT URLs in the guest.
Discover the host IP that the guest can route to
Inside a Linux guest, print the default gateway; it is usually the VMware pseudo-router, not the host application IP:
ip route | grep -m1 '^default'
To reach a service on the physical host, VMware often maps a special address—on many Linux guests you can try the default gateway IP as the “host side” of the NAT device, but the reliable pattern on modern Workstation builds is documented as a host-accessible address in VMware’s own networking notes. When in doubt, temporarily attach a second bridged adapter for diagnosis, read the host’s LAN address from ip addr, and curl the mixed port from the guest. If bridged is not available, use the Virtual Network Editor on Windows to read the vmnet8 (NAT) subnet and gateway, then infer which host-side IP responds to ARP from the guest.
In a Windows guest, ipconfig /all exposes the default gateway for each adapter. Compare that value with the host’s ipconfig output taken outside the VM. You are looking for an address that responds to ping (if ICMP is allowed) and, more importantly, accepts TCP on your proxy port.
Bind the proxy where the guest can touch it
A listener bound only to 127.0.0.1 on the host accepts connections from the host loopback namespace only. Packets that originate from the VMware virtual adapter are delivered on a different interface; they never land on that socket. Enable allow-lan (or equivalent) in your profile so the mixed port attaches to 0.0.0.0 or to the specific LAN address you intend to expose, then restart the core.
This is the same class of issue people hit when sharing a phone or tablet over Wi-Fi; our LAN sharing, mixed port, and firewall article walks through the mindset with concrete Windows Defender examples you can reuse for VMware subnets—just mentally swap “phone” for “guest VM.”
Exposure: Listening on all interfaces is convenient on trusted lab networks; on public Wi-Fi, narrow the bind or firewall-scope the rule to the VMware virtual subnet only.
Host firewall rules that actually stick
Windows Defender Firewall frequently prompts the first time your Clash executable accepts inbound TCP. Approve for Private networks, then verify with netsh advfirewall firewall show rule name=all or the graphical inbound list. If you clicked “block” once, the silent drop will look like a routing bug. For scripted labs, create an explicit allow rule tied to the binary and port range you use for mixed mode.
On macOS, Application Firewall and third-party tools may also require you to allow incoming connections for your GUI client or helper. After a macOS upgrade, revisit Security & Privacy because signatures change and prior approvals vanish. The symptom is identical: SYN packets never reach the userspace proxy.
Point the guest at HTTP and SOCKS explicitly
Modern guests give you three practical layers: operating-system manual proxy, per-application settings, or environment variables in shells. For a Windows guest, Settings → Network → Proxy → Manual proxy setup, then set the address to the host IP you validated and the port to your mixed listener. macOS and most Linux desktops expose similar panels.
For terminals in Linux guests, export both lowercase and uppercase variables because heritage tools disagree:
export HOST_PROXY=http://192.168.88.1:7890
export http_proxy="$HOST_PROXY" https_proxy="$HOST_PROXY"
export HTTP_PROXY="$HOST_PROXY" HTTPS_PROXY="$HOST_PROXY"
export ALL_PROXY="socks5://192.168.88.1:7890"
Replace the IP and port with your measured values. If your core splits HTTP and SOCKS across different ports, do not pretend they are identical; mismatching schemes produces maddening half-working states where apt succeeds but git does not.
DNS inside the guest
Some failures look like “no internet” but are resolver dead-ends: the guest still uses an ISP or hotel DNS that lies about CDN names. After TCP to the proxy works, if specific sites fail only inside the VM, align guest DNS with a trustworthy resolver or rely on the proxy’s remote resolution path. When FakeIP is enabled on the host, remember that the browser on the host and the curl inside the guest are different clients; they may not share the same name-to-address story unless both traverse the core consistently.
If you need a refresher on resolver modes in Meta-class cores, keep DNS leak prevention patterns open in another tab while you tune the host profile; the guest usually benefits indirectly once upstream names stop returning poisoned answers.
When port forwarding is the better hammer
VMware’s NAT editor lets you map a host port to a guest port. That feature solves different problems—exposing a guest web server—not the “guest needs outbound internet” case. For outbound internet through Clash, forwarding is rarely the first tool. Instead, forwarding becomes relevant when you run a service inside the guest that must be reached from the LAN, or when you chain another proxy entirely inside the guest. Keep the vocabulary straight so you do not spend an hour editing NAT tables when a single HTTP proxy URL would have worked.
Host TUN as an alternative mental model
If you enable TUN mode on the host with proper service privileges, much of the host’s IP stack is steered through the core automatically. That does not automatically tunnel every VMware packet—you are still dealing with a separate NIC—but some teams find that host TUN plus careful split routing reduces the number of places where bypass leaks occur. Follow the Clash Verge Rev TUN mode guide for service installation and DNS alignment; skipping those steps is why newcomers decide TUN “does nothing.”
Verify with curl and the connections log
From the guest, run:
curl -I https://example.com --proxy http://HOST_IP:7890
Watch the Connections view in your Clash UI: you should see the flow sourced from the VMware subnet, not only from host processes. If no line appears, packets are not hitting the listener—return to bind mode and firewall. If lines appear but policies show DIRECT unexpectedly, reorder rules before you blame VMware.
Ordered playbook
1Prove host browsing through Clash
Lock the baseline on metal before debugging the guest.
2Measure guest → host TCP to the mixed port
Use curl or nc with an explicit proxy URL; avoid guessing 127.0.0.1 inside the VM.
3Open the listener and firewall intentionally
allow-lan or explicit bind plus a Defender or macOS rule that matches your threat model.
4Apply guest system proxy or exports
Re-test with both browser and shell; parity between them prevents false negatives.
Open source, downloads, and trust
Meta-class cores publish sources and issue trackers for transparency. Read changelogs there, but install day-to-day builds from the official Clash download page so signatures and update channels stay consistent with the rest of this site’s guidance.
Summary
VMware guests do not inherit the host’s Clash magic. Treat the problem as networking: choose a host IP reachable from the NAT or bridged NIC, expose an HTTP/SOCKS listener outside loopback, allow the firewall path, then configure the guest’s system proxy or environment variables to that address. Compared with reinstalling tools at random, this sequence is boring—and boring is what you want when a deadline looms.
A maintained host client with clear logs turns “VM broken” into a short checklist: wrong IP, wrong bind, wrong rule, or wrong capture mode. Compared with opaque all-in-one VPNs, that precision keeps domestic routes fast and keeps your lab reproducible for teammates who clone the same appliance image.