Route Parallels or VMware VMs Through Host Clash: NAT, Bridged, and Manual Proxy Setup

Why the Guest Cannot Use the Host’s 127.0.0.1

On the physical machine, Clash (or any Mihomo-compatible GUI) commonly binds mixed-port to 127.0.0.1 so only local processes can connect—a sensible default. Inside a virtual machine, however, 127.0.0.1 refers to the guest’s loopback interface, not the host’s. Pasting http://127.0.0.1:7890 into a Windows or Linux guest therefore talks to an empty port inside that VM, not to Clash on macOS or Windows bare metal. The fix is always the same class of change: reach the host through a routable IP on the virtual NIC path (host-only, NAT gateway, or bridged LAN), while Clash accepts inbound TCP on that path. If you already fixed similar confusion for Microsoft’s lightweight Linux layer, the mental model is identical to routing WSL2 through a Windows host Clash instance—only the hypervisor UI differs.

NAT Versus Bridged: Which Address Is the Host?

Shared / NAT (VMware’s default shared NAT, Parallels “Shared Network”) puts guests behind a virtual router. The host appears as the default gateway from inside the guest—often something like 10.211.55.1 or 192.168.x.1 depending on product and profile. A quick check inside the guest: read the route table—on Linux ip route, on Windows route print—and note the gateway on the default route; that address is usually your path to the host. The guest still needs the host’s LAN-facing or virtual-network address, not its public WAN IP.

Bridged networking makes the VM a first-class device on your LAN with its own DHCP lease. The host is “just another machine” on the subnet. Here you point the guest at the host’s ordinary IPv4 on that subnet—what you would use to SSH or ping from another laptop on Wi-Fi or Ethernet. Bridged setups sometimes simplify mental arithmetic because you can look up the host in the router’s client list, but corporate Wi-Fi that blocks peer hosts might force you back to NAT or host-only. Either mode works with Clash as long as TCP from guest to HOST_IP:mixed-port is permitted end to end.

Host-only (VMware “Host-only” or a custom Parallels private VLAN) is a third pattern: the guest and host share a tiny RFC1918 segment with no path to the Internet except whatever you bridge manually. Clash still works the same way—guest points at the host’s address on that host-only NIC—but you must not confuse that address with your Wi-Fi DHCP lease. Document the interface names; screenshots in hypervisor UIs change yearly, yet the address math stays boringly IPv4.

Host Preparation: allow-lan, Bind Address, Firewall

Before touching guest settings, open the host listener to the virtual network. In Clash / Mihomo YAML, set allow-lan: true and ensure bind-address (or equivalent) listens on * / 0.0.0.0 for IPv4, not solely loopback. Restart the core so the port really binds broadly. Then allow inbound TCP on mixed-port in Windows Defender Firewall, macOS application firewall, or third-party suites; otherwise the guest will see timeouts despite correct IP math. If you have ever pinned external-controller to localhost for safety, leave it—this article targets forward proxy ports only. For a fuller picture of sharing Clash with other devices on the LAN, including bind-address pitfalls, see Clash LAN sharing: firewall and bind address.

Step 1 — Manual HTTP and SOCKS in the Guest

The smallest reproducible path is explicit environment variables for shell tools and language runtimes. Let HOST be the IPv4 you discovered (NAT gateway or bridged LAN IP). Let PORT be mixed-port. On a Linux guest for an interactive Bash session:

Linux guest shell — HTTP and SOCKS5h for remote DNSexport HOST=10.211.55.1
export PORT=7890
export http_proxy="http://${HOST}:${PORT}"
export https_proxy="http://${HOST}:${PORT}"
export ALL_PROXY="socks5h://${HOST}:${PORT}"
export no_proxy="localhost,127.0.0.1,${HOST}"

The socks5h scheme asks cURL and many stacks to resolve hostnames through the SOCKS tunnel, which often matches what Clash’s DNS stack expects. Plain socks5 may still resolve locally inside the guest unless you align resolvers separately (next section). For apt on Debian/Ubuntu, use Acquire::http::Proxy in a file under /etc/apt/apt.conf.d/ mirroring the same http://HOST:PORT, or wrap apt with the env vars above in a disposable script when testing.

On a Windows guest, PowerShell for the current session might look like:

Windows PowerShell — session env vars$env:HOST="10.211.55.1"
$env:PORT="7890"
$env:HTTP_PROXY="http://$($env:HOST):$($env:PORT)"
$env:HTTPS_PROXY=$env:HTTP_PROXY

Then run curl.exe against an HTTPS endpoint and watch your Clash connections panel—if no line appears, traffic never reached the listener (wrong IP, firewall, or port). Persist variables via System Properties only after you trust the lab policy; corporate images sometimes clear user-level proxy keys at login.

Step 2 — Guest OS System Proxy to HOST_IP:PORT

Browsers and some GUI apps honour the guest system proxy rather than shell exports. On Windows 11/10, Settings → Network & Internet → Proxy → Manual → Address 10.x.x.x, port your mixed-port. On macOS guest (rare on VMware/Parallels but possible), System Settings → Network → Details → Proxies. On GNOME Linux guests, use Settings → Network → Network Proxy, matching the same HTTP host/port. This is the mirror image of what Clash does when it pushes system proxy on the host—but the IP is the host’s LAN identity, not loopback. Keep YAML policy readable while you test: overly broad global rules hide mistakes; refine order using Clash rules routing best practices.

DNS: Proxy-Only Versus Changing the Guest Resolver

HTTP CONNECT and SOCKS5 can carry hostname information, but many stacks still issue separate DNS queries from the guest before they ever open the tunnel—especially stock Windows tooling and mis-typed proxy schemes. Two stable patterns: (1) use socks5h/HTTP stacks that defer resolution to the proxy where Clash’s own resolver applies, or (2) point the guest’s DNS to an address your rule set already treats sanely—sometimes a public resolver when your split is broad, or the host’s LAN IP if you intentionally run a forwarder there. Always reconcile guest DNS behaviour with what you configured under Clash Meta DNS: nameserver, fallback, fake-ip-filter so fake-ip, sniffing, and rule hits stay aligned.

When Host TUN Mode Does Not Capture VM Traffic

TUN on the host steers that OS’s IP stack through Mihomo. Virtual NIC packets from Parallels or VMware enter the stack differently: they are often bridged or NAT’d before they hit routes that TUN manages. Expecting “turn on TUN, ignore the guest” is unreliable unless you have explicitly engineered routing that drags hypervisor interfaces into the policy path. In practice, explicit forward proxy to HOST_IP:mixed-port remains the portable answer across Windows hosts running Workstation, Mac hosts running Fusion, and Apple Silicon Parallels guests. Revisit Clash TUN mode fundamentals to see why transparent capture is scoped to the machine where the utun/wintun device lives—not magically every child network namespace.

Beyond Manual Proxy: Optional Gateway Pointer

Some teams want every UDP datagram, ICMP, or oddball updater to ride the tunnel without per-app proxy support. That requires elevating Clash to a gateway role—handing the VM a default route or DHCP option through a dedicated Linux router or advanced bridge—not a four-line env export. That architecture overlaps our Linux TUN side gateway with nftables article; treat it as optional reading once manual HTTP/SOCKS no longer meets the workload. Choosing how far you automate routing also intersects choosing the right Clash client for GUI versus headless operation.

Verification Checklist

Run through these steps in order so you do not chase ghosts:

1. From the host, curl through 127.0.0.1:mixed-port—confirms Clash itself answers locally.
2. From the guest, ping HOST_IP—confirms L3 reachability. ICMP may be filtered; if ping fails but TCP works, still try HTTP.
3. From the guest, curl -v -x http://HOST_IP:PORT https://example.com—should log a CONNECT in Clash.
4. Open the Clash dashboard or log and confirm the connection’s policy group—not silent drops.
5. Disable proxy temporarily; pages should revert, proving you are not seeing cached offline content.

Troubleshooting Quick Hits

• Connection refused — Clash still bound to loopback only, or wrong port; re-check allow-lan and bind options.
• Timeouts — Host firewall or hypervisor network isolation; AV “network shield” products often block cross-guest traffic.
• TLS succeeds but wrong region — Exit node issue, not transport; verify policy group selection.
• Works in browser, not in terminal — Shell lacks env vars; Windows Terminal sessions inherit differently than Settings UI.

Parallels Desktop and VMware Fusion are common precisely because they isolate whole OS images for testing. Treat the host as a tiny “proxy island”: one IP, one port, YAML you already trust, and guests that explicitly call that island. Compared with opaque VPN clients that hide policy, Clash keeps the same transparent logs you rely on when iterating rules—only the hop to reach mixed-port crosses the hypervisor instead of localhost.

→ Download Clash for free and experience the difference—a Mihomo-compatible client that exposes listeners, LAN sharing knobs, and live connection logs so your VMs stop guessing whether traffic ever touched the proxy stack.