典型现象与底层原因
你会看到非常一致的组合：宿主机 上的 Chrome/Edge 已能访问目标站点，而同一块物理机 上的 Windows/Linux 客体内 要么超时，要么只能访问国内直连资源，和宿主机上的分流效果不一致。若你把虚拟机也设成使用宿主机在「设置里写的代理 127.0.0.1:端口」，在 NAT 下几乎必挂——因为 127.0.0.1 在客户机里指向的是客户机自己的环回，而不是 Windows 或 macOS 宿主机 上 Clash 监听的套接字。
网络地址转换（NAT） 为每台虚拟机分配虚拟网段上的地址，并通过 vmnet/虚拟交换把出网包交给宿主机，再由宿主机用真实网卡出公网。客户机要访问「宿主机本机服务」，必须使用在 NAT/Host-Only 网段上对虚拟机可见的宿主机侧 IP，而不是环回。Clash 若只在 127.0.0.1:7890 监听，对从虚拟机发起的 TCP 连接 来说，宿主机还必须在 0.0.0.0:7890 或该 vmnet 地址上可接受进连（见下文 允许局域网）。
先认清：NAT 的网关与网段长什么样
在 VMware 默认的 NAT 模式里，常见配置是类似 192.168.x.0/24 的私有网段：客户机拿 192.168.x.2、.3 这类地址，默认网关 常指向 192.168.x.1 或 .2 一侧（具体以你当前虚拟网络编辑器/偏好设置为准）。宿主机在 vmnet8（Windows）等接口上也会出现在同一子网中，这就是虚拟机访问「宿主机上开放的端口」时应当写成的目标 IP 前缀。不要在文章外抄死某一组数字，务必打开编辑 → 虚拟网络编辑器 / Fusion 网络偏好核对当前 子网与网关，避免和实验室或公司定制的第二套 NAT 混用。
Windows 宿主机上快速确认
在宿主机以管理员或普通 PowerShell 执行 ipconfig，找到 VMware Network Adapter VMnet8 对应的 IPv4，该地址在多数标准 NAT 中即供虚拟机访问宿主机时使用的目标之一（与虚拟 DHCP/网关设计一致时）。同时记下 Clash 的 mixed-port 或 port 值，下文以 7890 为例，你需替换为实际值。
macOS Fusion 上
在 VMware Fusion 的网络设置里查看 NAT/自定义网段，并在宿主机 系统设置 → 网络 中观察桥接/虚拟相关接口的地址。与 macOS 上 Clash 系统代理、Helper 与网络扩展 一文类似，图形客户端的权限 若异常会影响本机，但 虚拟机侧是否走代理 仍由「客户机到宿主机 IP:端口 是否通」决定，要分开排查。
1宿主机 Clash：混合端口、监听与允许局域网
在 Clash Verge Rev 等客户端中，确认 mixed-port（或 HTTP / SOCKS 分端口）已设置；在配置文件中对应项通常为纯数字。关键是：允许来自虚拟机网段（及局域网）的入站——在界面中常写作「允许局域网 / Allow LAN」；否则即使用对了宿主机在 vmnet 上的 IP，连接仍会被拒。与之并列的是 仅监听 127.0.0.1 的坑：应保证代理端口对 子网可路由地址 可达。更多 Windows 总览见 Windows 下 Clash 完整安装与配置；与纯 Wi‑Fi 下共享给手机不同，混合端口、防火墙与 allow-lan 那一套在「谁可以连上这个端口」上的逻辑可共用，只是 对端从手机换成了虚拟机的虚拟网卡。
若你使用 TUN 模式 接管了宿主机全局流量，客户机发出来的包在默认 NAT 下仍从 子系统/虚拟机协议栈 独立出去，不一定会与宿主 TUN 的劫持路径一致。对「只让浏览器和终端走代理」的诉求，显式在虚拟机里设系统代理或环境变量，指向宿主机 IP + Clash 端口 往往比强依赖 TUN 穿透到客户机 更可预期、更好写文档。
安全提示：打开「允许局域网」后，同网段内其他设备理论上也连接得上你的代理端口。仅在可信环境使用，用毕可关闭或收紧防火墙范围。
2在虚拟机里指向宿主机：HTTP/HTTPS 与 SOCKS
假设你在宿主机上通过 ipconfig 等途径确认 vmnet8 的 IPv4 为 192.168.174.1，Clash 混合端口为 7890（请换为你的实值）。在 Windows 客户机 中：进入「设置 → 网络和 Internet → 代理」或老版「Internet 属性」，手动设置代理，将 HTTP/HTTPS 代理填为 192.168.174.1，端口 7890。若需 SOCKS5，在支持的应用里使用 192.168.174.1:7890 或独立 socks-port。对 不读系统代理 的命令行工具，在 PowerShell 或 CMD 中设置 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 环境变量，与 WSL2 文中 的写法类似，区别只是 IP 从 WSL 的 resolv 换成 vmnet8 的 IPv4。
在 Linux 客户机（常见为 Ubuntu/Debian 系测试镜像）中，可临时在 shell 中导出：
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"
对 apt 需额外配置 Acquire::http::Proxy 或使用 sudo -E 保留环境，依发行版习惯而定。验证时用 curl -I https://www.google.com 看是否经代理；若只返回超时，回退到「宿主机能否从同一宿主机上 Test-NetConnection 192.168.174.1 -Port 7890 成功」的 分步连通性 检测。
为什么「127.0.0.1:7890」在虚拟机里几乎总是错
不少教程默认写 127.0.0.1，因在同一操作系统里 Clash 就监听在环回上。在 另一台虚拟计算机 里，那是 它自己的 127.0.0.1。除非你做了端口级别转发/反向代理（对新手极不常见），否则请 不要 在客体内把代理主机填成 127.0.0.1。这与 WSL2 里 127.0.0.1 不指向 Windows 的困境是 同一类概念，可对照 WSL2 与 Clash 代理 加深理解，只是 VMware NAT 的「宿主机侧 IP」来自 vmnet 表而不是 resolv.conf。
桥接（Bridged）和 NAT 怎么选？
桥接 模式把虚拟机放到与宿主机 同一层二层网络（与路由器同一广播域时），若宿主机是 DHCP 来的地址，虚拟机 也会直接拿和物理局域网同网段的 IP。此时在虚拟机里填 宿主机在局域网中的 IP 作为 Clash 代理地址往往可行，行为更像「多了一台物理机用你电脑的代理服务」。但桥接在 公司网、酒店认证 Wi‑Fi、多网卡 环境下更容易踩 MAC/策略限制。
NAT 则隔离性好，地址稳定，是多数读者本地实验的默认项；代价就是 必须 走本文这套「vmnet 上的宿主机地址 + 允许局域网 + 客体内显式代理」。先在一个模式下跑通，再比较另一种，会省大量时间。
「端口转发」在什么时候会用到？
搜索中常出现 端口转发 与 VMware NAT 设置 一起出现：在 从外网或宿主机通过固定端口访问虚拟机内服务（例如虚拟机里起的 Web 开发服务器）时，需要把宿主某端口映到客体内目标端口。这与「客户机 主动 访问宿主机上的 Clash」方向相反。本文主线是 出站到互联网经 Clash，一般 不需要 为 Clash 再配一条 VMware 端口转发；若你既要做开发端口映射、又要出网代理，请在脑子里保持 入站/出站两条箭头 别混。
宿主机防火墙与 Clash 规则、FakeIP 的交叉注意
Windows 防火墙 若对入站连接询问「是否允许 Clash 专用网络」，在虚拟机试连前请选择允许，或为 7890 这类端口在「专用/域」侧建立放行规则。若已通而只有 某域名 失败，则回到 Clash 的 规则与 DNS，例如 fake-ip-filter 与局域网/直连域 是否让 vmnet 内网或特定直连域名被误走 FakeIP。虚拟化不豁免 DNS/分流 逻辑，只是 流量从另一块网卡上来。
分步排错清单
- 宿主机 Clash 已运行，
mixed-port与界面「允许局域网」与预期一致。 - 宿主机上
netstat -an | findstr 7890（或等价）显示监听在0.0.0.0:7890或含 vmnet 地址，而不仅是 127.0.0.1。 - 用虚拟网络设置核对 子网/网关 与 ipconfig 中 VMnet 相关 IPv4，一致后写入客户机代理。
- 在客户机
ping宿主机 vmnet 地址（若禁 ICMP 可跳过）并优先用带代理的curl -v做应用层测。 - 公司安全软件/第三方防火墙再扫一遍，避免仅放开浏览器而未放开 Clash 核心进程。
合规提醒：请仅在法律与网络使用政策允许的前提下使用代理；企业或教育网可能禁止未授权代理绕行，任何后果由使用者本人承担。
关于获取客户端：Clash 系项目可在 GitHub 查阅协议与发布说明；安装包 请优先从 本站下载页 获取，与社区仓库的用途分开理解。
小结
VMware 下 NAT 与 宿主机 Clash 的组合，本质是：在 虚拟机 里用 可见的宿主机侧 IP 替代 127.0.0.1，在 Clash 侧 允许局域网/正确监听 并 放行防火墙，在客户机里 显式 配置 HTTP/SOCKS/系统代理 或 环境变量。与 WSL2、手机 Wi‑Fi 共享 等文章同读，能建立「谁访问谁、用哪个 IP、哪个 mixed-port」这一共同心智模型；相比临时把虚拟机改成桥接，按本文在 NAT 下跑通往往更 省权限、少变量。
在规则生态与 混合端口、订阅管理 上，Clash 系客户端对这类「开发/测试环境多网卡」场景一直比较友好。若你尚未安装宿主机端，可先从 一站式下载与文档 把基础打牢，再按 vmnet 实址回填。