VMware 与 Parallels 虚拟机里怎样走宿主机 Clash？桥接/共享与代理逐步配置

为什么 Guest 虚拟机不能照搬 WSL2 的修法

WSL2 是与 Windows 同机不同网络命名空间的 Linux 内核，你在子系统里访问 127.0.0.1 时指向子系统自己；要用宿主 Clash，需要宿主机在局域网中可达的地址、mixed-port 或拆分的 HTTP/S 端口、以及 allow-lan 等——这在 WSL2 专文 里已逐步写过。而 VMware、Parallels、Hyper-V 等全功能 VM 里，Guest 是一台逻辑上独立的「另一台电脑」：有独立的默认网关、可能走虚拟 NAT、也可能与宿主机同网段。你要解决的是「访客机到宿主机上某个监听端口是否路由可达」，而不是在 Guest 里寻找「镜像 localhost」。先把这句话理解透，能省掉一半无效尝试。

桥接、NAT、仅主机、共享各是什么

下表是面向「对接宿主机 Clash」时的使用侧理解，不是替代官方文档的完整网工课。

模式	典型表现	与宿主机 Clash 的衔接
桥接 / Bridged	Guest 与物理机接入同二层网段，常从路由器 DHCP 拿到与宿主同段的地址	Guest 访问宿主机在此网段上的 IPv4 地址 + Clash 监听端口，路径最直；需开启 Clash 的 allow-lan
NAT / 共享 / Shared	Guest 在私网内，出网被宿主或虚拟化层做源地址转换；宿主机多扮演「小型路由器」	从 Guest 到宿主机常有一个稳定可达的「网关侧或宿主虚拟网卡」地址，同样指向 主机IP:端口；各厂商默认网段不同，以在 Guest 里实际能 ping 通的为准
仅主机 / Host-only	仅 Guest 与宿主（及彼此）互通，不经由物理网上外网（若未做额外共享）	可访问宿主 Clash 做「出口代理」；但无默认外网时，需依赖代理本身或再配路由/ICS，排障时别误判为 Clash 坏了

第 0 步：在宿主机把「局域网可连」与端口对齐

无论 VMware 在 Windows 上还是 Parallels 在 macOS 上，Guest 要连到的是宿主机上 Clash 的入站。实践上你需要同时满足：

• 在 Clash 配置或图形端里打开 允许局域网连接（常见字段名 allow-lan: true），并确认 mixed-port 或你打算使用的 HTTP 与 SOCKS 端口在宿主上对局域网接口监听，而不是只绑 127.0.0.1。
• 在 Windows 防火墙或 macOS 入站规则里，为对应端口显式允许来自「虚拟子网 / 同网段」的访问；否则会出现「能 ping 宿主却连不上代理端口」的假象。

更细的 mixed-port 与 allow-lan 关系、同网段下其它设备入站，可参考 《局域网、mixed 端口与 allow-lan》。Windows 上若你尚未装通 Clash 本体与 TUN 基线，可先看 《Clash for Windows 安装与配置》；macOS 用户别跳过 《Clash Verge Rev 首次在 macOS 上配置》 中的权限与 Network Extension 步骤。

宿主机 TUN 会不会自动「带走」访客机流量

这是高频误解。宿主机上开启的 Clash TUN，主要影响该操作系统里被内核转发层拦截的会话。访客机在 NAT 下发出的数据包，经虚拟化后是否还会被「同一套 TUN 规则」完整覆盖，与宿主机系统、厂商虚拟网卡与转发路径强相关。工程上可依赖的一条经验是：与其赌 TUN 自动代劳，不如在 Guest 中显式配置系统代理，或对终端与包管理器设置 HTTP(S)_PROXY 与 ALL_PROXY（Socks5）指向 宿主IP:端口，行为最可解释、可排障。若你在宿主侧为浏览器已开 TUN、同时在 Guest 里要跑 Docker 等，也请注意 Guest 内 DNS 与规则库是另一套——别把 fake-ip 现象误判到错误的层次上，参见 《已连接却上不了网与 fake-ip 排查》。

VMware Workstation / Player（Windows 宿主）操作要点

在适配器设置里为虚拟机选择桥接 / NAT等模式后，在 Guest 内打开命令行，记下宿主机在 Guest 视角下应访问的地址。桥接时多直接使用与你 PC 同网段里能 ping 通的那块无线或有线网卡地址。NAT 时，VMware 常见默认网段里主机的虚拟适配器常扮演 .1 或 .2 一类网关角色，具体以你当前版本与虚拟网络编辑器里已生效的 VMnet 配置为准。

在 Windows 宿主机上，请用 ipconfig 对照与 Guest 同逻辑网段的那块接口地址；若有多块虚拟网卡，容易抄错。把「代理目标」写为 http://<该地址>:<mixed 或 http-port>，再在 PowerShell 里 curl 或浏览器验证。若仅浏览器需要，设置系统「代理服务器」为上述地址与端口即可；apt、dnf、pip 等常需再配环境变量或自身配置文件。

Parallels Desktop（macOS 宿主）与 VMware Fusion 的差异提示

在 Parallels 的网络选项中，共享网络、桥接与仅 Wi‑Fi/默认适配器等会改变 Guest 的默认路由与到 macOS 的可见地址。共享网络时，从 Linux 或 Windows Guest 访问宿主机，常见写法是使用在 Guest 路由表里指向的网关或 Parallels 文档中给出的「到 mac 主机的稳定地址」——不同版本界面上叫法会微调，以实际能通的为准。VMware Fusion 的 VMnet 与桥接在概念上与 Workstation 一致，可平行套用上一节的「先辨网段、再对 IP:端口」。

在 macOS 上，系统防火墙、Little Snitch 等「出站/入站」工具可能拦掉来自 Parallels 虚拟网段对 Clash 端口的入站。若你已在 Verge 教程 里为 Network Extension 放行，但 Guest 仍连不上，下一刀通常砍在「第三方防火墙规则」上。

在访客机中落地：系统代理与终端环境变量

以 Linux Guest 为例，多数场景在 /etc/environment 或 shell 的 ~/.bashrc 中设置：

# Use your host address and the port your Clash exposes (http / mixed / socks)
export HTTP_PROXY="http://<HOST_IP>:<PORT>"
export HTTPS_PROXY="http://<HOST_IP>:<PORT>"
export ALL_PROXY="socks5://<HOST_IP>:<SOCKS_PORT>"
export NO_PROXY="localhost,127.0.0.1,::1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"

Windows Guest 可借助「设置 → 网络和 Internet → 代理」指向同一 HOST_IP:PORT。若你使用需要 TLS 解密的规则集，要意识到在 Guest 里未安装信任证书时，少数 HTTPS 仍可能表现异常——这属于证书链问题，与「代理端口不可达」需分开查。

至于容器或 Kubernetes 在 VM 里再跑一层：那是套娃网络，常要在 Docker daemon.json 或 HTTP_PROXY 中再次指向能路由到宿主的地址，有时要避开 127.0.0.1 这类只指向容器的写法。

DNS：不要假设 Guest 自动继承宿主的 Clash 解析

即使 HTTP 已走代理，若 Guest 仍用本地直连的上游 DNS 解析，某些场景会出现「部分域名解析不对、规则永远匹配不到」的现象。可选择在 Guest 内将 DNS 指到可信任的递归，或在你明确理解后果的前提下，让 DNS 查询也经代理栈处理——细节与 fake-ip 的关系仍以 DNS 专文 的排查顺序为准。

排查清单：从物理到应用一层层收紧

• Guest 与宿主的网络模式是什么？在 Guest 里能 ping 宿主的哪个 IP？
• Clash 是否 allow-lan、端口在宿主上对本机 127.0.0.1 已验证可用？
• 防火墙/安全软件对入站到该端口的规则是否放通？
• 是「端口不通」还是「端口通但 HTTPS/DNS 异常」？用分层 curl 分清楚。

从一款维护良好的客户端开始

把虚拟机里的出网需求接到宿主 Clash，本质上是「把 Guest 的显式或环境变量式代理，对准监听在宿主上、对局域网开放的那一个入口」——与 WSL2 的 127.0.0.1 陷阱不同、与「指望宿主机 TUN 一口吃下去」的期望也不同。把这条链路打通后，规则与订阅仍由宿主 Clash 统一维护，Guest 里只做最小配置即可。

立即免费下载 Clash，开启流畅上网新体验