1 与 VMware / Windows 宿主文章的区别：不要照搬 VMnet 地址
站内《VMware 虚拟机走宿主机 Clash：NAT、桥接与仅主机网卡配置步骤》讲的是 Windows 上 VMware 的 VMnet8 / VMnet1 与「宿主机在哪一段虚拟网卡上的 IP」。Parallels Desktop 跑在 macOS 上时，子网规划、菜单名称与客户机里能 ping 到的宿主机地址都与 VMware 不同，把文章里的示例数字原样填进 Parallels 往往会连不上或时好时坏。
不变的原则只有一条：虚拟机里的 127.0.0.1 永远是自己，要让客户机里的浏览器或终端走 Mac 上的 Clash Verge Rev，必须把代理地址写成从客户机路由可达的 Mac 侧 IPv4，并保证 Clash 在该地址上监听入站（通常对应打开 Allow LAN）且 macOS 防火墙没有静默丢弃来自 Parallels 网段的 TCP。
若你尚未在 Mac 上装好客户端，建议先完成《macOS 安装 Clash Verge Rev》，确认混合端口、SOCKS 端口与局域网相关选项的位置，再回虚拟机里填代理。
2 Parallels 网络模式一览：先选模式再填 IP
Parallels 里常见三种与本文相关的配置（具体文案以你安装的版本为准）：
- 共享网络（Shared / 推荐默认）：客户机经 Mac 做 NAT 访问外网，客户机与 Mac 落在Parallels 自己的私网，与家里路由器的
192.168.x.x不是同一网段。 - 桥接网络（Bridged）：客户机像同一局域网里的第二台电脑，通常从路由器 DHCP 拿到与 Mac 物理网卡同网段的地址。
- 仅主机式 / 封闭拓扑（Host-Only 类）：客户机主要与 Mac 互通，是否还能上公网取决于你选的模板；走 Clash 时仍要把流量显式指到 Mac 在该私网上的地址与端口。
宿主机开 TUN 模式只影响 Mac 本机协议栈被 Mihomo 接管的流量，不会自动把 Parallels 里所有套接字重定向到代理。客户机要稳定分流，仍要在虚拟机内配置系统代理、应用内代理或终端环境变量，思路与《Clash Verge Rev TUN 模式完全指南》里强调的「谁被谁接管」一致：先分清哪一层在发连接。
4 桥接：用 Mac 在物理网段上的地址，并留意 Wi‑Fi 客户端隔离
桥接时，客户机与 Mac 往往处在同一二层网段（例如家里路由下发的 192.168.1.0/24）。此时应把代理指向 Mac 在该网段上的 IPv4（可在 Mac 上按住 Option 点菜单栏 Wi‑Fi 图标查看，或在「系统设置 → 网络」里读当前地址）。同样必须打开 Clash 的 Allow LAN，否则监听仍可能只在 127.0.0.1，客户机永远连不上。
若你遇到「客户机能上网，但访问 Mac 上代理端口超时」，在公司或商场 Wi‑Fi 下请先怀疑客户端隔离：同一 SSID 下禁止无线终端互访时，换有线、换热点或改回共享网络通常比反复改 Clash 规则更有效。
桥接模式下客户机是独立一台主机，客户机内监听 7890 与 Mac 上 Clash 的 7890 不冲突（IP 不同）；真正要避免的是把协议类型写错，例如把 SOCKS5 填进只接受 HTTP 代理的输入框。
5 Clash Verge Rev on macOS：混合端口、SOCKS 与 Allow LAN
在 Clash Verge Rev 中先确认三件事：混合端口（mixed-port）是否启用、是否另有独立 socks-port、以及「允许局域网连接 / Allow LAN」是否打开。只有打开 Allow LAN（或等价配置），Mihomo 才会在 0.0.0.0 或局域网可见地址上接受来自 Parallels 网段的入站 TCP。
Windows 客户机里填「系统代理」时，若使用混合端口，通常同一端口可同时协商 HTTP 与 SOCKS（以你当前内核与配置为准）；若你分开配置了 HTTP 与 SOCKS 端口，请在系统设置里不要混用协议。Linux 下可分别导出 http_proxy、https_proxy 与 all_proxy（SOCKS），再用 curl -v --proxy 做对照测试。
宿主机的「系统代理」或菜单栏一键开关只作用于 macOS 本机，不会自动同步到 Parallels 里的 Windows；这与 Hyper-V、VMware 场景的结论相同：虚拟机内要单独配置。
6 macOS 防火墙：放行 Clash / Mihomo 的入站连接
即使 Clash 已监听在 0.0.0.0，macOS 防火墙仍可能拦截来自虚拟机的入站首包。请到「系统设置 → 网络 → 防火墙」（或你系统版本对应路径）中，为 Clash Verge Rev 或其底层内核进程勾选允许传入连接，或临时关闭防火墙做对照测试（仅在可信环境下用于定位，定位后请恢复最小放行策略）。
若你使用第三方安全或网络过滤软件，也要确认它们没有在 Parallels 虚拟网卡上再做一层阻断。排障时建议打开 Clash 的连接日志：若客户机发起 SYN 而 Mac 侧完全没有记录，优先怀疑监听地址、防火墙或 Wi‑Fi 隔离，而不是节点质量问题。
7 SOCKS、仅部分应用生效与 DNS
「只有浏览器能上、终端不走代理」多半是应用没有读系统代理：请在同一客户机里分别用浏览器与 curl 带显式 --proxy 测试。若显式代理正常而系统代理不生效，检查 Windows「代理」设置是否指向正确 IP 与端口，或是否被组策略锁定。
DNS 方面：若 Mac 侧使用 FakeIP 或自定义 DoH，而虚拟机仍用运营商或路由器下发的 DNS，可能出现「代理已开但解析路径与 Mac 不一致」的错觉。可将虚拟机 DNS 暂时改为公共递归或与宿主机策略对齐，并结合《彻底防止 DNS 泄漏》把谁在做解析、谁在做连接分开看。
另一类高频错误是把 SOCKS5 填进只接受 HTTP 的字段，或继续在虚拟机里写 127.0.0.1。请始终使用从客户机可达的 Mac 地址，并在宿主机日志里确认来源 IP 是否落在 Parallels 子网或桥接网段。
8 建议验收顺序（避免同时改多处）
- Mac：Clash 端口、Allow LAN、防火墙与相关安全软件。
- 客户机：核对到 Mac 的 IP，必要时
ping或 PowerShellTest-NetConnection测 TCP 端口（禁 ping 环境可只看端口）。 - 应用层：
curl -v --proxy http://MAC_IP:PORT https://www.example.com与 SOCKS 形式各测一遍。 - 对照 Mac 侧连接日志，确认有来自虚拟机网段的入站；若无，回到监听地址与防火墙。
9 总结
Parallels Desktop 与 macOS 上的 Clash Verge Rev 联用时，核心是四件事：选对网络模式（共享或桥接），在客户机里填写该模式下 Mac 可达的那张 IPv4，为跨机访问打开 Allow LAN，并检查 macOS 防火墙是否放行入站。默认网关与 Clash 入站端口职责不同，不要混为一谈。
与站内 VMware、Hyper-V 文章相比，Parallels 用户更应关注共享网络子网在客户机路由表里的真实呈现，而不是照搬 VMnet 示例地址；桥接时则要像物理两台电脑一样考虑 Wi‑Fi 隔离。
当规则与 DNS 已在 Mac 侧理顺，虚拟机侧只需稳定指向同一混合端口或 SOCKS 入口，排障会简单很多。相比在客户机里盲目改网关，用日志清晰的 Clash 系客户端先在宿主机确认「有没有入站」，是更省时间的习惯。
相比其他同类工具，Clash 系在规则可读性与 Mihomo 内核演进上的综合体验仍然更均衡；在 Mac 物理桌面与 Parallels 开发环境之间切换时，这种一致性尤其省时。
