先分清 NAT 与桥接：虚拟机眼里的「宿主在哪」
Parallels Desktop 与 VMware Fusion 给每台客户机虚拟出一块网卡，常见两种模式：NAT（共享网络）与桥接（Bridged）。宿主上的 Clash 写入的是宿主操作系统的代理设置；虚拟机相当于另一张桌子上的电脑，默认不会继承那张设置，除非你手动指定 HTTP／SOCKS 上游，或把整个 TCP 栈改成透明转发（后者属于旁路网关，不在本文两步法里）。先把模型选对，后面填 IP 才不会抄错门牌。
在 NAT 下，客户机拿到私网地址，默认网关通常指向虚拟路由器的一段接口；宿主扮演「同一私网里的邻居」，常见表现形式是与你虚拟机 IP 同网段的某一个地址（具体数值因产品与版本而异，可能是 10.0.x.1、192.168.x.1、Parallels 共享网络段或 Host-Only 段等）。你要找的，是从虚拟机里 ping 得通、且宿主在该地址上真实监听 Clash 端口的那一侧，而不是盲目套用教程里的示例数字。
在 桥接 下，客户机直接出现在与你的 Wi‑Fi／有线局域网同一二层网段，此时最直接的做法是使用宿主在路由器 DHCP 表里的 IPv4 地址（例如 192.168.1.23），与手机连同一 Wi‑Fi 时填「电脑的局域网 IP」是同一逻辑。若宿主还有 VPN 或多块物理网卡，请以与客户机同一广播域的那一个为准。
判读流量是否真进了内核，可边看宿主 Clash 连接列表边在虚拟机里打开测试页；若完全没有新条目，优先怀疑IP 填错或监听仅限 127.0.0.1，再走 timeout 与 TLS 日志专文 对照握手阶段，而不是先怀疑节点宕机。
宿主准备：端口、allow-lan 与防火墙
在动手改虚拟机之前，宿主侧需要满足三件事：Clash 正在运行；mixed-port（或你分开配置的 port／socks-port）已在 YAML／图形界面里固定下来；对局域网其它主机的可达性已打开。绝大多数「虚拟机里填了代理仍 connection refused」的根因，是 Clash 仍只监听 127.0.0.1——这对宿主本机够用，对虚拟机却是另一台机器，必须通过 allow-lan: true（或 GUI 中等效选项）并在系统防火墙里放行对应 TCP 端口。
Windows 主机可在「高级安全 Windows Defender 防火墙」里为入站新建规则放行 mixed 端口；macOS 若在首次监听时弹出对话框需点「允许」。绑定地址、网段是否与手机热点／隔离 VLAN 冲突等细节，请同步对照 局域网共享与绑定地址专文， 避免「宿主 curl localhost 成功，虚拟机却一律超时」的假阳性。
动手抄到小本本上的三个数：计划在虚拟机里填写的宿主 IPv4（桥接优先抄路由器网段；NAT 则以虚拟机视角里稳定可达的那段为准）、HTTP 代理端口（常与 mixed 相同）、以及独立 SOCKS 场景下的第二端口。若你同时在宿主启用 TUN，希望只靠「应用层手动上游」而不是全局透明，可先阅读 TUN 深度解析 厘清两套路径差异，减少「开了 TUN 却仍指望手写 HTTP 代理兜底」的心智打架。
第一步：在客户机确认指向宿主的 IP
Windows 虚拟机：在 PowerShell 执行 ipconfig，记下 IPv4 与默认网关；再对你推断的宿主地址执行 ping。若网关 IP 并不是宿主本身，通常仍以同网段内能往返通的宿主接口作为代理主机名——关键是二层／三层都能抵达监听端口。
Linux 虚拟机：使用 ip route 查看默认路由下一跳，配合 ip -4 addr 理解接口名；可用 ping 与 nc -vz 宿主IP 端口 验证 TCP 半握手是否被防火墙挡住。
macOS 客户机（嵌套虚拟化场景较少见）：在「系统设置 → 网络」同样能看到默认路由器；手动代理仍填对虚拟机路由可达的宿主 IPv4。
若在 NAT 下长期 ping 不通宿主，检查虚拟网络编辑器是否启用客户机隔离、或产品文档里的「共享网络／Host-Only」组合是否限制了宿访客。临时切换到桥接做一次 A／B，往往能一眼分辨是虚拟交换机策略还是Clash bind-address问题。
第二步：系统代理与环境变量（浏览器／apt／curl）
图形界面（推荐给浏览器）：在 Windows 11「设置 → 网络和 Internet → 代理」选择手动代理，服务器填上一节的宿主 IP，端口填 mixed-port；「请勿将代理用于本地地址」是否勾选，取决于你是否仍要直连虚拟网段里的 NAS 或另一台 VM。macOS 与常见 Linux 桌面环境同理，在 HTTP／HTTPS 代理处指向同一主机与端口即可。
终端与包管理器：思路与宿主完全一致，只是把 127.0.0.1 换成宿主可达地址。示例（端口务必改成你的现场值）：
export http_proxy="http://192.168.1.10:7890"
export https_proxy="http://192.168.1.10:7890"
export ALL_PROXY="socks5://192.168.1.10:7890"
export no_proxy="localhost,127.0.0.1,::1"
apt、curl、git 多数会读取上述变量；个别工具需要单独写配置文件。批量容器与 CI 场景的命名差异，可对照
Docker／CLI 环境变量专文
一并收拾。
建议用 curl -I https://www.cloudflare.com/cdn-cgi/trace 观察出口字段是否随策略组变化；再回到宿主连接视图核对会话源地址是否落在虚拟机网段，避免「偶发走了宿主浏览器缓存」的误判。
常见翻车点：DNS、端口漂移与策略路由
DNS 分叉：TCP 进了代理，解析仍在客户机本地完成时，会出现「页面半加载、控制台全是域名超时」。可把虚拟机 DNS 临时改成跟随网关，或在 Clash 侧重审 fake-ip 与 fallback 链，细节叠读 Meta DNS 专文。
端口漂移：客户端升级或导入新配置后 mixed-port 变了，虚拟机还在写旧数字——建议把「宿主监听端口」当成基础设施常量记录在密码管理器或内部 Wiki。
策略路由与企业 VPN：宿主侧若对「来自虚拟网段的回程」做了拆分隧道，可能在 Clash 日志里能看到 SYN 却没有完整 TLS。此类问题要在宿主路由／VPN 文档里排查，而不是重装 Parallels Tools。
与「改网关／透明劫持」方案的区别
本文刻意不修改虚拟机默认网关，也不把 DHCP DNS 强行指向 Clash——那是透明网关／旁路小主机路线，运维成本高但能省去每台客户机维护代理 UI。若你需要 Linux 充当全网网关配合 nftables 与 TUN，请阅读 Linux 旁路网关实测， 它与本文「手动指向宿主 IP:端口」是正交选项： household 用户通常先落地后者即可。
与微软栈相比，
WSL2 专用教程
讲解的是 localhost 转发语义；虚拟机场景几乎没有 magic localhost，请始终把宿主局域网 IP当作代理主机名。
结语
NAT 与 桥接 的差别，归根结底只有一句话：虚拟机准备把 HTTP CONNECT 交给哪一张可达的宿主网卡。只要 allow-lan、防火墙与端口三件事对齐，Parallels 里的 Windows、VMware 里的 Ubuntu，都能与宿主共用同一套 Clash 策略——这正是「宿主 Clash + 手动代理」最具性价比的组合。
先把虚拟机 → 宿主 IP:端口 → Clash 日志这条三角链路跑通，再去微调规则集与 DNS，排障顺序会比盲目复制网关教程稳妥得多。
→ 立即免费下载 Clash，开启流畅上网新体验：在宿主集中维护订阅与健康检查，让所有虚拟机客户机只记住一组 IP 与端口即可。