1 与 Hyper-V 场景区分：检索词不同，网络模型也不同
站内《Hyper-V 虚拟机走宿主机 Clash：NAT 默认网关与系统代理两种配法》面向的是 Windows 自带虚拟化与默认交换机 / 外部 vSwitch；而 VMware Workstation 与 Player 在 Windows 上使用另一套虚拟网卡命名（常见 VMnet1、VMnet8 等），地址规划与「谁是网关」的直觉也不完全一样。
两条线共通的前提是：虚拟机里的 127.0.0.1 永远指向虚拟机自己，要连宿主机上的 Clash，必须写宿主机在对应网段上的 IPv4，并保证 Clash 对该网段入站可达——通常要开 Allow LAN（或等价「监听所有接口」），再配合防火墙放行。下文按 VMware 三种常用适配器模式分别说明「该填哪个 IP」。
若你尚未在 Windows 上装好图形客户端，可先完成《Clash Verge Rev Windows 安装》，确认混合端口与局域网开关位置，再继续虚拟机侧配置。
2 NAT、桥接、Host-Only：先选场景再填代理
在 VMware 中，可先粗分为三类（具体名称以你「虚拟网络编辑器」为准）：
- NAT：虚拟机通过宿主机做地址转换访问外网；虚拟机与宿主机在独立的 NAT 网段，与家里路由器网段不同。
- 桥接（Bridged）：虚拟机像同一局域网里的第二台物理机，通常从路由器 DHCP 拿到与宿主机同网段的地址。
- 仅主机（Host-Only）：虚拟机只与宿主机及其他 Host-Only 虚机互通，默认不经 NAT 上公网；适合纯内网实验或刻意隔离。
对「让浏览器/终端走宿主机 Clash」这一目标，三种模式都能做，差别在于：你要从虚拟机里 ping / curl 到的宿主机 IP 是哪一段，以及是否存在AP 隔离、公司网策略阻断「无线客户端互访」。
3 NAT（常见 VMnet8）：默认网关不是 Clash
在典型 NAT 配置下，虚拟机拿到的默认网关往往是 VMware 虚拟路由/NAT 设备地址（常见为网段内 .2，以你环境为准），负责把私网流量送出去；而宿主机在同一 VMnet上通常会有另一个地址（常见为 .1），对应「VMware Network Adapter VMnet8」一类接口。
你要把 HTTP/HTTPS 代理或 SOCKS 指向的，是宿主机在该 VMnet 上的地址（多为 .1）+ Clash 的混合端口或 HTTP 端口，而不是把「默认网关」改成 Clash 端口——网关仍然是 VMware NAT 角色，Clash 提供的是应用层代理入站。
在 Windows 宿主机上可用 ipconfig 核对 VMware Network Adapter VMnet8 的 IPv4；在 Linux 虚拟机内用 ip route 看默认路由，再对照 traceroute 理解下一跳。若你改过「虚拟网络编辑器」子网，请以当前界面为准，不要硬背某一组数字。
ipconfig | findstr /i "VMnet8"4 桥接：把宿主机当作局域网里的一台电脑
桥接模式下，虚拟机与宿主机往往处于同一二层广播域，虚拟机应使用宿主机在物理网卡所在网段上的 IPv4（例如 192.168.1.0/24 中的某个地址）。此时 Clash 必须对局域网开放监听——即打开 Allow LAN，否则进程仍只绑在 127.0.0.1，虚拟机永远连不上。
「与宿主机抢端口」在此模式下通常指误解：桥接时虚拟机是独立一台主机，你在虚拟机里再起一个监听 7890 的服务，与宿主机 7890 并不冲突（IP 不同）。真正会冲突的，是你在同一台机器同一地址上重复绑定同一端口，或做了端口映射/转发把两路流量拧到一个端口上。
若使用公司或校园 Wi‑Fi，请留意客户端隔离：虚拟机即便与宿主机同网段，也可能禁止无线客户端互 ping。表现为「虚拟机上网正常，就是访问不到宿主机代理端口」——这不是 Clash 配置单方面的问题，需要换有线、换网段或改用 NAT/Host-Only 做固定拓扑。
5 Host-Only（常见 VMnet1）：封闭网段里访问宿主机
Host-Only 网络里，虚拟机与宿主机在独立私网互通，默认不经过 VMware NAT 上外网。若你仍希望「虚拟机里所有外网访问都走宿主机 Clash」，本质是：虚拟机把应用流量送到宿主机在 VMnet1 上的地址的代理端口，由宿主机 Clash 再出口——这与 NAT 场景一样，属于显式 HTTP/SOCKS 代理或系统级代理，而不是改默认网关就能自动魔法分流。
某些用户会在 Host-Only 环境做纯内网靶场，此时若不需要外网，甚至可以只在虚拟机里访问宿主机上的内网服务；一旦需要外网，就要么改回 NAT/桥接，要么接受「全部经代理」的应用层路径，并关注 DNS 是否仍指向合理上游。
6 宿主机 Clash：何时必须开 Allow LAN
只要虚拟机（或任何非本机环回）需要访问宿主机上的 Clash 入站端口，就应满足：
- Allow LAN / 允许局域网连接已开启，使监听落在
0.0.0.0:端口（具体以客户端为准）。 - 记下混合端口或 HTTP 端口数值；HTTP 代理与 SOCKS 协议不要混填。
- Windows Defender 防火墙对专用网络放行 Clash 主程序与内核；若仍拒绝入站，可参考《Windows 11 防火墙放行 Clash》做最小放行（仅在可信网络下操作）。
宿主机的「系统代理」开关不会同步到虚拟机；虚拟机内 Windows 的代理设置、Linux 的 http_proxy / apt 配置需要单独写，与 Hyper-V 一文结论一致。
7 DNS 异常与「端口冲突」常见误解
DNS方面：若虚拟机沿用 DHCP 下发的 DNS，而宿主机 Clash 使用 FakeIP 或自定义 DoH，可能出现「浏览器走代理了但解析仍怪异」的现象。可在虚拟机内暂时改为与宿主机策略一致的 DNS，或按《彻底防止 DNS 泄漏》中的思路，把解析路径与代理路径分开审视。
另一类高频问题是：虚拟机内 curl 显示连接被拒绝，实际是协议填错（把 SOCKS 当 HTTP 用）或仍写 127.0.0.1。先用带 --proxy 的测试命令指向「宿主机 IP:端口」，再在宿主机日志里确认是否有入站记录。
8 建议验收顺序（避免同时改多处）
- 宿主机 Clash：确认端口、Allow LAN、防火墙。
- 虚拟机：用 ping 或
Test-NetConnection（PowerShell）探测宿主机 IP 与代理端口是否 TCP 可达（若环境禁 ping，可只看端口探测）。 - 应用层：浏览器设置系统代理或使用
curl -v --proxy http://HOST:PORT https://example.com验证。 - 对照宿主机连接日志，确认来源 IP 落在 VMware 网段；若无记录，仍是监听地址或隔离策略问题。
9 总结
VMware 下让虚拟机走宿主机 Clash，关键是三件事：选对虚拟网卡模式（NAT / 桥接 / Host-Only），在虚拟机里填写该模式下宿主机可达的那张 IP，并为跨机访问打开 Allow LAN 与防火墙。默认网关负责「IP 包往哪送」，Clash 端口负责「应用层代理从哪进」，两者不要混成一个开关。
与 Hyper-V 相比，VMware 用户更应熟悉 VMnet 与虚拟网络编辑器中的子网；与桥接下的「同路由器网段」相比，NAT/Host-Only 更依赖宿主机在对应 VMnet 上的地址。把这条线对齐后，再配合 DNS 与协议类型排查，大部分「虚拟机里上不了」的问题都能快速归因。
相比在虚拟机里反复试错路由表，在 Windows 宿主机上使用日志清晰、局域网开关一目了然的 Clash 系客户端，能显著降低排障成本；规则与 DNS 已在宿主机理顺时，虚拟机侧只需稳定指向同一代理入口即可。
相比其他同类工具，Clash 系在规则可读性与 Mihomo 内核演进上的综合体验仍然更均衡；在 VMware 与物理桌面之间切换开发环境时，这种一致性尤其省时。
