1 Why VMware networking deserves its own checklist
If you already read a Hyper-V plus host Clash tutorial, the high-level idea is familiar: the guest must either use an explicit HTTP or SOCKS proxy toward the host, or you must engineer routing so traffic is intercepted before it leaves the environment you control. VMware Workstation implements its own virtual adapters—commonly VMnet1 for host-only and VMnet8 for NAT out of the box—with DHCP service on the Windows host. That means the “host IP” your guest should target is predictable once you know which VMnet you are attached to, but it is not identical to the Hyper-V NAT gateway story.
Another distinction matters for support forums: VMware bridged mode puts the virtual NIC on the same Layer-2 segment as a physical adapter you select. The guest may obtain an address from the same router that serves your Wi-Fi or Ethernet PC. In that layout, “the host” is simply another machine on the subnet, and you aim proxy clients at the host’s LAN IPv4 address—often easier to explain to yourself than digging through synthetic private ranges. By contrast, NAT keeps guests behind VMware’s own mini-router; the default gateway inside the guest points at a VMware-managed address (typically .1 or .2 on the NAT segment, depending on version and customization), while the host also participates on that same virtual wire with a separate address you must read from ipconfig or ip addr.
Host-only removes upstream internet from the virtual switch entirely unless you add another adapter or complex forwarding. Guests can still reach the Windows host on the host-only interface—exactly what you want for a deliberately isolated malware lab or license-locked toolchain—so Clash on the host remains reachable for explicit proxying while the guest has no default route to the public internet through that adapter. Choosing the wrong mental model—treating host-only like NAT and wondering why “the internet is broken,” or treating NAT like bridged and hunting for a LAN DHCP lease that never appears—is the root cause of many misconfigured guests.
2 NAT, bridged, and host-only in one table of intent
NAT is the default sweet spot for laptops: the guest shares the host’s outbound path, VMware performs address translation, and you do not consume an extra DHCP lease on the coffee-shop VLAN. From Clash’s perspective, the guest originates traffic that exits through the host’s real NIC after VMware unwraps it. To send application flows through Clash’s mixed listener instead of the raw path, you still configure the guest OS or individual apps to use HOST_IP:PORT where HOST_IP is the Windows address on the NAT virtual segment facing the guest—not your public Wi-Fi IP, not the loopback address inside the guest.
Bridged mirrors plugging a second computer into the same switch. The guest’s default gateway is usually your home or office router, same as the physical PC. Clash on the host does not automatically sit in that default route; it is just another host listening on a TCP port if you enable Allow LAN. Discovery is simple when you know the host’s LAN address (often shown in your router’s client list). The trade-off is visibility: some enterprise networks block unknown MAC addresses, duplicate static IP mistakes become easier, and multicast-heavy apps behave differently than behind NAT.
Host-only wires VMs to each other and to the host on a private VMware switch with no NAT to the outside world through that adapter. You still configure a proxy toward the host’s address on VMnet1 (or whichever host-only network you defined) so selective tools can reach the internet through Clash, while the rest of the guest stack sees no general-purpose internet path unless you attach a second NIC. That pattern suits compliance-sensitive workflows where you want outbound control centralized on the host proxy without giving the guest a full public default route on the isolated adapter.
Relationship to host-side TUN mode
Running Clash in TUN mode on Windows captures traffic from host processes in a way that feels like magic until you involve virtualization. Packets originating inside a VMware guest traverse VMware’s virtual switch and may not intersect the host TUN adapter the same way local Chrome traffic does. For most readers, explicit proxy settings in the guest toward the host’s mixed port remain the maintainable solution; reserve “make TUN see the guest” discussions for advanced lab designs with forwarding and policy routing you can document and revert.
3 Allow LAN: when it is mandatory, when it is not
Clash-compatible clients expose Allow LAN (or YAML allow-lan: true) so the HTTP and SOCKS listener binds beyond 127.0.0.1. Virtual machines, whether on NAT or bridged mode, connect from a non-loopback source address. If Allow LAN stays off, your guest will time out even when the IP and port look correct, because the socket never accepted LAN-scope SYN packets. Turn it on for any scenario where the guest must dial the host by RFC1918 address.
You do not need Allow LAN for traffic that never leaves the host—for example, if you later run a separate Clash instance inside the guest and only use loopback there. You do need it for the common pattern “one subscription on the host, many guests point at the host.” Pair Allow LAN with a fixed mixed port such as 7890 and document it in your notes so Linux HTTP_PROXY variables and Windows manual proxy dialogs stay aligned.
Security posture follows the same rule as physical LAN exposure: anyone who can reach that TCP port can tunnel through your proxy profile. On untrusted networks, constrain Windows Defender Firewall rules to the specific VMware subnet or your home prefix instead of opening the listener to the world. Our Windows 11 firewall article walks through profile selection when virtual adapters flip between Private and Public.
vmnet-style subnets where possible, not blanket any/any permits.
4 NAT (VMnet8): step-by-step toward the host mixed port
Open Virtual Network Editor on Windows (administrator privileges) and confirm which VMnet is tied to NAT—often VMnet8 with a segment like 192.168.x.0/24. Boot the guest, then inspect addressing: on Windows guests use ipconfig; on Linux use ip -4 addr and ip route. Identify the default gateway on the NAT interface; it represents VMware’s virtual router role. The Windows host also holds an IPv4 address on that same VMnet—this is the address you aim proxy clients at, not the guest’s own address.
If you cannot remember which side is which, list adapters on the host with ipconfig /all and locate the entry named like VMware Network Adapter VMnet8. Its IPv4 host address is the destination for HTTP_PROXY=http://<that-ip>:7890 style settings. In the guest, configure Settings → Network & Internet → Proxy on Windows or environment variables on Linux. For shells, export HTTP_PROXY, HTTPS_PROXY, and optionally ALL_PROXY for SOCKS if your Clash mixed port supports both schemes.
Some applications ignore environment variables; browsers may need the system proxy toggle, and Firefox can be pointed independently. The workflow parallels what we described for WSL2 reaching Windows Clash, except your guest is a full VMware VM with its own kernel and DHCP lease. After changes, open PowerShell in the guest and run Test-NetConnection <HOST_VMNET_IP> -Port 7890 (adjust the port) to prove TCP connectivity before blaming rule quality.
# Replace with your host address on the NAT VMnet and your mixed port
export HTTP_PROXY="http://192.168.174.1:7890"
export HTTPS_PROXY="http://192.168.174.1:7890"
export ALL_PROXY="socks5://192.168.174.1:7890"5 Bridged mode: treat the host like any LAN neighbor
Set the guest NIC to Bridged and pick the physical adapter that actually carries your internet (Wi-Fi or Ethernet). After DHCP settles, the guest should sit in the same subnet as your Windows host—think 192.168.1.0/24 or 10.0.0.0/24 as your router defines. Discover the host’s current IPv4 from the guest with ping HOSTNAME if DNS resolution works, or read the lease table on the router, or run arp -a after a successful ping by hostname.
Point proxy settings at <host-lan-ipv4>:7890 with Allow LAN enabled on Clash. Bridged mode is often the easiest to reason about because it matches how you would configure a second physical PC beside your desk. The complication is environmental: hotel captive portals, 802.1X wired auth, or VPN software on the host can reorder routes so the guest still reaches the internet while specific flows hairpin oddly—if that happens, capture whether the issue is DNS or TCP by testing an IP literal through the proxy first.
When you roam between Ethernet and Wi-Fi, bridged attachments may need manual re-selection in VMware if you bind bridging to a specific NIC. Stale selections produce guests that think they are online while DHCP never completes. Revisit the bridged adapter choice whenever you change docking stations or VPN products on the host.
6 Host-only: isolated VMs that still talk to Clash
Attach a NIC to Host-only (commonly VMnet1). Guests receive addresses from VMware’s DHCP service on that segment only; there is no NAT-provided path to the public internet through this adapter alone. The Windows host always has an address on the same wire—again, check VMware Network Adapter VMnet1 via ipconfig on the host. That IP is your proxy target for traffic you intentionally steer through Clash.
If you need both isolation and raw internet without the proxy, add a second virtual NIC in NAT or bridged mode and think through which applications bind to which interface. Routing metrics on Linux and interface metrics on Windows decide the default exit; mis-set metrics can send unintended flows out the wrong NIC. For a pure lab where everything should exit via the host proxy, a single host-only NIC plus correct proxy environment is simpler than split routing.
Corporate compliance scenarios sometimes pair host-only with snapshots: revert the disk after testing while the host Clash configuration remains the single audited outbound choke point. Document that the host-only network must not be bridged to production VLANs accidentally—Virtual Network Editor mistakes have created “ghost DHCP” incidents that confuse IT tickets for days.
7 Avoiding port fights and DNS weirdness
Port collisions rarely mean “VMware stole port 7890 from Windows.” They usually mean you tried to run another proxy listener—maybe an old Clash core, a corporate HTTP inspector, or a dockerized mitmproxy—on the same host port Clash already uses. Only one process can bind a given TCP port on an address. If you must run a second tool, pick a different port in Clash’s profile and update every guest reference consistently. Inside the guest, avoid launching a second Clash instance on 7890 if your intent is to consume the host’s listener instead; change the guest-side port or disable the redundant service.
DNS symptoms arrive early: the guest resolves names to addresses you did not expect—sometimes because Clash uses FakeIP or a dedicated DNS listener on the host, while the guest still queries public resolvers. If HTTP works when you enter an IP literal but fails by hostname, synchronize DNS strategy: either point the guest to a resolver consistent with your Clash DNS mode, or accept explicit proxy for DNS-over-HTTPS capable apps. The Meta core DNS leak prevention guide explains FakeIP versus redir-host trade-offs that apply whenever multiple operating systems participate in one policy.
IPv6 adds another wrinkle: if the guest prefers AAAA records and your proxy path is IPv4-only, failures look like intermittent “half the sites work.” Test with IPv6 temporarily disabled on the guest adapter to confirm, then either carry IPv6 through consistently or align preferences with your rule set. VMware per-VM NIC toggles for IPv6 are worth checking when dual-stack behavior surprises you after a host OS upgrade.
8 Verification checklist
- TCP to the mixed port: From the guest, port-test the host IP and Clash port; success must precede TLS debugging.
- Clash logs: Live connections should increment when the guest loads an HTTPS site; silence means traffic never reached the listener—revisit Allow LAN and firewall scope.
- Rule sanity: Temporarily switch to a simple global rule to isolate profile mistakes from VMware networking mistakes.
- DNS alignment: If only some domains fail, compare guest resolver settings with your Clash DNS section.
- Adapter mode: Reconfirm NAT vs bridged vs host-only in the VM settings; screenshots from forums rarely include this crucial line.
9 Wrap-up
VMware Workstation and Player give you three distinct traffic stories. NAT hides guests behind VMware’s mini-router—point proxies at the host’s VMnet address. Bridged puts the guest beside your PC on the real LAN—use the host’s ordinary IPv4 and remember Allow LAN. Host-only isolates lab networks while keeping a private path to the host for explicit proxy hops. None of these modes automatically inherit Clash settings from Windows; you choose per guest whether to rely on system proxy, environment variables, or application-specific dialogs, and you keep DNS behavior consistent with your Meta core configuration so FakeIP does not fight stub resolvers.
Compared with juggling multiple one-off VPN clients, Clash and Mihomo reward you with structured logs and repeatable YAML—valuable when a VMware snapshot rolls back the guest but the host profile stays authoritative. For a polished Windows install before you stack VMs on top, see Clash Verge Rev on Windows so mixed ports, Allow LAN, and connection traces are ready from day one.
When you want installers and platform notes centralized—without hunting GitHub releases as the primary distribution path—open the site’s download page, finish host-side setup, then return to VMware and run through the verification list above guest-by-guest.
