1. 共享网络到底共享了什么先把三种模式的边界划清楚很多人第一次在 Parallels Desktop 里遇到宿主机访问不了虚拟机、虚拟机也 ping 不通宿主机第一反应是网卡坏了或者版本有问题然后开始重装、重置网络、换桥接折腾一下午。实际上这类问题九成以上出在对共享网络这个模式的语义理解有偏差——它不是把宿主机和虚拟机放进同一个局域网而是让宿主机临时扮演一个路由器兼 NAT 网关的角色。这个角色的定位一旦搞错后面所有的排查方向都是歪的。我在自己的 Mac 上长期跑 Windows 和 Linux 两套虚拟机做开发验证共享网络Shared Network是我用得最多的一种模式原因很简单它不依赖宿主机当前连的是 Wi-Fi 还是有线也不怕会议室里换了个网段就失联。但它带来的互通是有方向的、有条件的尤其涉及端口转发、防火墙、服务监听地址这几件事时坑特别密集。这篇内容就是把这些年踩过的、能复现的坑整理出来从模式选型一路讲到静态地址计算、防火墙放行、端口转发配置再到网络初始化失败的恢复姿势和彻底卸载的清理顺序适合刚接触 Parallels Desktop 的新手也适合已经用了几年但一直靠重装大法解决问题的老用户。1.1 共享网络宿主机兼职做路由器共享网络模式下Parallels Desktop 会在宿主机上创建一块虚拟网卡macOS 上通常以vnic0的形式出现并给它分配一个私有网段的网关地址。虚拟机的流量先发到这块虚拟网卡再由 Parallels 的网络组件做地址转换后从宿主机真实的物理网卡发出去。默认情况下这个私有网段常见的是10.211.55.0/24宿主机的虚拟网卡拿.1网关和 DNS 一般也指向它但不同版本、不同配置下这个网段是可能被改过的必须自己去机器上看不能背数字这一点后面会详细讲怎么确认。这种宿主机当网关的结构带来两个直接后果。第一虚拟机对外只有出站能力外界看到的源地址是宿主机的物理网卡地址所以你在家里路由器上永远找不到虚拟机的名字第二虚拟机与宿主机之间确实有一条直连链路因为那块虚拟网卡就长在宿主机上宿主机完全可以把它当成同网段的邻居来访问。很多人误以为共享网络 孤岛其实不是孤岛的是它和外部的其他设备跟宿主机之间反而是通的。还有一个容易忽略的点共享网络下虚拟机的 DNS 请求默认会被转发到宿主机当前使用的 DNS 上。这意味着你在公司网络里换了 DNS 服务器虚拟机的解析行为会跟着变而不是固定在某个公共服务上。这个特性在排查虚拟机里能 ping 通 IP 但域名解析不了的问题时非常关键因为问题往往出在宿主机的解析链路上而不是虚拟机配置里。1.2 桥接网络虚拟机直接站到物理局域网里桥接Bridged走的是另一条路虚拟机的虚拟网卡被接到宿主机的某一块物理网卡上虚拟机会像一台新插进交换机的机器一样通过局域网的 DHCP 拿到地址。好处是全网段可见别人能直接访问它做测试服、跑容器、给同事演示最方便。代价是它强绑定在某一块物理网卡上。你选了桥接到有线网口那虚拟机只能看到有线网口所在的那个网络你带着笔记本从办公室回到家里有线口根本没插线虚拟机就会拿不到地址或者拿一个无效地址表现为网络突然不通了。这也是热词里新电脑用网线能否共享网络如何配置网口共享无线网卡的网络这类问题的根源——它描述的就是物理层换了个出口虚拟机还盯着老出口的典型场景。顺带说一句桥接模式下虚拟机是否能上网取决于宿主机本身在那个网络上是否通畅它并不会因为宿主机同时连着 Wi-Fi 就自动借用 Wi-Fi。这个认知偏差非常普遍后面第 4 章会专门拆。1.3 仅主机网络一条不出门的内部链路仅主机Host-Only模式是三条路里最内向的一条它也会创建虚拟网卡、也有网关但这条链路不接任何出口虚拟机完全出不了外网只能和宿主机以及同样挂在这条链路上的虚拟机通信。这个模式在什么场景下有用我一般用它做两件事一是搭内网靶机环境故意断掉外网避免自动更新干扰实验二是做宿主机与虚拟机之间的数据库、缓存同步既不想暴露给局域网也不想被宿主机当前的 Wi-Fi 状态影响。它的默认网段和共享网络不同常见是10.37.129.0/24宿主机端为.1同样需要以实际显示为准。三条路的定位理清了选型其实就变成一道很直白的判断题需要被局域网里的其他设备直接访问选桥接只需要宿主机与虚拟机之间互通、同时还要能上外网选共享完全不需要外网选仅主机。绝大多数共享网络互通踩坑的案例都是把共享网络当成了桥接来用或者反过来。2. 一次连通要过几道关共享网络的链路拆解与选型逻辑2.1 从虚拟机到外网NAT 表、DHCP 与虚拟网卡三个角色把共享网络的出站链路想象成家里的宽带路由器就很容易理解了。虚拟机相当于家里的手机宿主机的虚拟网卡相当于路由器的内网口Parallels 的 NAT 组件相当于路由器里的地址转换模块宿主机的物理网卡相当于路由器的 WAN 口。虚拟机发出一个请求先按自己的路由表把包交给默认网关也就是虚拟网卡的地址Parallels 记下这次连接的五元组然后替换源地址从物理网卡发出去回包到达时再按记录反向替换送回虚拟机。这里有一个非常重要的推论NAT 表是有状态的只有虚拟机先发起的连接才能收到回包。外部设备想主动连进虚拟机NAT 是不知道往哪转的必须手动配置端口转发规则这是硬性限制不是配置问题。DHCP 的角色也很值得说。共享网络下虚拟机通常是从 Parallels 内置的 DHCP 服务拿地址租约和网段都由它管理。这个服务的地址池一般覆盖整个网段的大部分地址所以如果你在虚拟机里手填静态地址理论上是存在和动态分配地址撞车的可能性的。这个细节后面在第 3 章我会给一个折中方案。2.2 从宿主机到虚拟机那条直连链路比你想的更好用很多人不知道的是共享网络下宿主机是可以直接访问虚拟机的。因为虚拟网卡就在宿主机上宿主机把它当作同网段邻居只要知道虚拟机的地址SSH、数据库、Web 服务都能直连不需要任何端口转发。我自己的日常就是虚拟机跑 Linux宿主机用终端直接ssh进去写代码文件同步走rsync完全不经过任何转发层。这个用法比桥接稳因为它不受宿主机换网络环境影响——你在星巴克连 Wi-Fi虚拟机的地址依然是那个私有地址SSH 照连不误。但这条链路会卡在三件事上一是虚拟机自己的防火墙Windows Defender 防火墙默认就拦 ICMP 和大部分入站端口导致ping不通但服务其实是起的二是宿主机侧如果要主动连虚拟机不需要额外放行但反过来就不一定了三是虚拟机的地址如果每次重启都变你的书签、脚本、端口转发规则全都要跟着改。第三点是最容易被低估的麻烦解决办法在第 3 章。2.3 选共享还是桥接四个判断维度对照与其记结论不如按下面这张表逐条对照自己的场景答案基本会自己浮出来。判断维度共享网络桥接网络仅主机网络虚拟机能否访问外网能经宿主机 NAT能取决于物理网卡所在网络不能局域网其他设备能否直接访问虚拟机不能需宿主机做端口转发能直接访问虚拟机地址不能宿主机能否直接访问虚拟机能直连私有网段能同网段访问能宿主机切换 Wi-Fi / 有线时是否受影响基本不受影响强相关换网络就可能失联虚拟机地址是否稳定默认动态可手工固定由上级 DHCP 决定默认动态可手工固定适合的场景本地开发、内网调试、需要外网演示、测试服、需要被外部访问隔离实验、内外网分离选型之外还有一个常被忽视的替代思路如果你只是想让同一台 Mac 上的宿主机访问虚拟机的服务永远优先用共享网络直连而不是去折腾桥接。桥接的复杂度主要来自它把虚拟机的可达性交给了外部网络一旦外部网络不受你控制公司 Wi-Fi 隔离、酒店网络禁止多设备你会陷入无论怎么改配置都不通的境地。3. 从零搭一套稳定的共享网络互通环境3.1 动手前的一张检查清单我现在的习惯是任何网络类排查都先花三分钟做一遍基础确认避免在错误的前提上折腾。下面这份清单是从多次折腾两小时发现是虚拟机防火墙没关的经历里总结出来的。确认 Parallels Desktop 主程序版本与当前 macOS 版本兼容网络组件依赖系统扩展版本错配会直接表现为网络初始化异常。确认虚拟机的网络适配器已勾选已连接有些时候它会被意外取消勾选表现为虚拟机里连网卡都看不到。确认虚拟机安装了 Parallels Tools虽然网络本身不强制依赖它但地址同步、共享、剪贴板等功能会一起失效容易造成误判。确认宿主机当前能正常上网。宿主机上不了网共享网络下的虚拟机必然也上不了别急着怀疑虚拟机。记录虚拟机的当前地址、网关、DNS 三项后面每一步排查都要对比。3.2 宿主机侧确认虚拟网卡与网段参数第一步是在宿主机上找到那块虚拟网卡看清楚真实的网段不要凭记忆。macOS 上用终端执行# 列出所有网络接口找 vnic0 / vnic1 这类虚拟网卡 ifconfig | grep -A 4 vnic # 或者更直观地看接口名与地址对应关系 ifconfig -l你会看到虚拟网卡的inet地址比如10.211.55.1那这个10.211.55.0/24就是当前的共享网络网段。接着用netstat -rn看一眼路由表确认这个网段的路由指向虚拟网卡本身。这一步的意义在于如果你改了网段却还在用旧地址配端口转发规则会全部失效而界面上不会有任何提示。然后在 Parallels Desktop 的偏好设置里进入网络配置页面切换到共享网络那一栏你能看到网段信息以及一张端口转发规则表。这张表是共享网络能否被外部访问的唯一入口建议先把当前规则截图存档后面加规则时有个对照。注意改网络配置前先关闭所有正在运行的虚拟机配置变更在虚拟机运行中未必能立即生效容易造成改了没反应的假象。3.3 虚拟机侧静态地址怎么算、怎么填共享网络默认走 DHCP地址会变。如果你要长期用 SSH、端口转发、数据库连接地址漂移的代价很大。我的做法是给虚拟机固定一个静态地址同时尽量降低撞车风险。按10.211.55.0/24举例可用地址是.1到.254其中.1是宿主机虚拟网卡占用的网关地址不能给虚拟机。选地址时按下面的原则来避开.1那是网关。如果你不确定 Parallels 的 DHCP 池范围尽量选靠后的地址段相对不那么容易被动态分配命中。选好之后立刻在宿主机上做一次冲突探测确认没人占用。记录下这个地址写进你的 SSH 配置或脚本里别再靠肉眼看。具体配置上Windows 虚拟机可以在网络适配器属性里改 IPv4 为手动填上地址、子网掩码255.255.255.0、网关指向宿主机虚拟网卡地址DNS 先指向同一个地址共享网络的 DNS 转发通常就走这里如果不生效再换成公共 DNS。Linux 虚拟机建议走发行版自己的配置方式NetworkManager 的nmcli或 netplan不要直接改resolv.conf那个文件经常被覆盖。# 冲突探测示例宿主机上执行替换为目标地址 ping -c 2 10.211.55.100 # 查看宿主机 ARP 表确认地址是否已有邻居 arp -a | grep 10.211.55如果ping无响应且 ARP 表里也没有对应条目基本可以认为这个地址是干净的。3.4 让宿主机顺利访问虚拟机服务防火墙与端口转发静态地址配好之后宿主机直连虚拟机应该立刻可用。先做一次最小验证从宿主机 ping 虚拟机的静态地址不通的话按顺序查三层虚拟机网卡是否连接、地址是否配置正确、虚拟机防火墙是否放行了 ICMP。Windows 虚拟机上最常见的坑就是防火墙。默认情况下 Windows Defender 防火墙会拦截入站 ICMP导致ping不通但服务其实是好的。用一个更贴近真实业务的验证方式能避免误判# 宿主机上测试虚拟机的具体端口比 ping 更可靠 nc -vz 10.211.55.100 22 nc -vz 10.211.55.100 3306如果ping不通但nc能连上那就不是网络问题是 ICMP 被拦了不用管。如果需要让虚拟机的服务被宿主机之外的其他设备访问就必须配端口转发。假设虚拟机里跑了 SSH宿主机想用2222端口暴露出去就在端口转发表里加一条宿主机2222→ 虚拟机10.211.55.100:22的规则然后从局域网内其他机器连宿主机的2222端口即可。注意端口转发规则的生效依赖虚拟机地址稳定。虚拟机的地址一变转发规则会指向一个不存在的目标表现为连接超时而不是明确报错这类问题非常隐蔽。3.5 反过来虚拟机访问宿主机服务要用哪个地址这是我最想强调的一个坑几乎每个新手都栽过。你在宿主机上跑了个服务监听在127.0.0.1然后在虚拟机里访问127.0.0.1当然连不上——虚拟机的127.0.0.1是虚拟机自己不是宿主机。正确的做法是把宿主机服务的监听地址改成0.0.0.0如果服务本身支持配置监听地址然后在虚拟机里访问共享网络的网关地址也就是那块虚拟网卡的地址比如10.211.55.1。这个地址在虚拟机里就是一个真实可达的远端主机。更进一步macOS 的应用防火墙可能会拦截来自虚拟网段的入站连接尤其是服务第一次被访问时。如果确认监听地址和端口都对、虚拟机也能 ping 通网关、但就是连不上服务去系统设置的防火墙里看一眼有没有对应的放行提示。这里还有一个环境层面的细节较新的 macOS 引入了本地网络类权限控制虚拟机与宿主机之间的本地通信可能受这类权限影响排查时值得顺手确认一下。4. 桥接到有线口却上不了网网口共享无线网络的做法4.1 为什么会掉进这个坑这个场景很典型笔记本平时用 Wi-Fi 上网桌面上有一台交换机或者一根网线接了个独立设备你希望虚拟机桥接到有线网口去对接那个设备同时也希望它还能上外网。结果虚拟机桥接之后能看见局域网设备却完全没有外网。原因在上一章其实已经埋好了桥接是把虚拟机的出口绑在某一块物理网卡上它只能看到那块网卡所在的网络。有线网口只连着本地设备、没有通往外部网络的路径虚拟机自然就只能看到本地这一段。共享网络因为走 NAT 出口是宿主机的物理网卡反而不会有这个问题这也解释了为什么很多人最后退回去用共享网络才解决。4.2 两种修法改桥接目标 vs 开启互联网共享第一种修法最简单如果只是要外网不需要对接有线口的那个设备直接把桥接的目标网卡换成当前上网的 Wi-Fi 网卡虚拟机就能像局域网内其他设备一样拿到地址。这个方案的前提是所处网络允许新设备接入公司或酒店的访客网络有时会做设备隔离这种情况桥接得到的地址可能拿不到需要换方案。第二种修法适合确实要同时满足对接有线设备和能上外网的需求在宿主机上把 Wi-Fi 的网络共享给有线网口。macOS 在系统设置的共享功能里提供互联网共享源选择当前上网的网络比如 Wi-Fi目标选择有线网口。开启之后有线网口会被赋予一个新的私有网段并承担网关角色此时桥接到有线网口的虚拟机就能顺着这条链路出去。这个方案有几个必须提前知道的副作用。第一开启共享后宿主机的有线网口地址会变成一个新的私有地址如果之前给这个网口配过静态地址会被覆盖掉。第二它依赖宿主机保持开机状态宿主机睡眠或者 Wi-Fi 切换时共享链路会一起断。第三桥接目标必须选有线网口选错成别的网口就白折腾。第四如果原本这个有线网口下挂的设备有自己的网段规划共享之后网段可能冲突表现为部分设备能通、部分不通这时候需要重新规划地址段。4.3 共享之后的地址变化与失效场景开启互联网共享之后虚拟机会从宿主机拿到该共享网段的新地址原来记录的静态地址、SSH 配置、端口转发规则全部失效。这是很多人明明昨天还好好的的真实原因不是系统抽风。我的经验是把共享有线口当成一种临时方案用在需要现场对接的场景用完就关掉不要把长期开发环境建立在这上面。长期环境还是回到共享网络加静态地址这套稳定性高得多切换网络环境时几乎无感。如果确实需要长期桥接务必在虚拟机里保留 DHCP并且每次接入新网络后先确认拿到的地址再进行业务操作。5. 踩坑实录那些看着通其实不通的细节5.1 网络初始化失败从权限、系统扩展到配置重置网络初始化失败是搜索量很高的一个报错表现形式通常有三种Parallels Desktop 启动时直接弹提示虚拟机里能看到网卡但拿不到地址宿主机上根本看不到虚拟网卡。这三种表现指向的原因并不相同按下面的顺序排查效率最高。先确认系统层面的授权是否完整。Parallels Desktop 的网络能力依赖系统扩展和后台服务macOS 升级之后这类授权有时需要重新确认。去系统设置的隐私与安全性相关页面检查是否有被拦截的扩展提示同时确认与虚拟化相关的本地网络权限处于允许状态。授权类问题通常伴随着宿主机上完全看不到虚拟网卡的表现这是一个很好用的判别特征。再检查后台服务状态。宿主机终端里可以列出与 Parallels 相关的后台项看关键服务是否在运行。如果服务处于异常状态重启宿主机往往比反复重启应用更有效因为网络组件在系统启动阶段初始化重启能重新走一遍完整流程。# 查看与 Parallels 相关的后台服务项 sudo launchctl list | grep -i parallels最后才是配置重置。如果前面两步都正常可能是网络配置文件里残留了旧的网段或规则导致初始化时冲突。我的做法是先把配置目录整体备份再清理网络相关的配置文件然后重启应用让它重新生成默认配置。这一步务必先备份并且要清楚会丢失自定义的端口转发规则和网段设置。注意任何一次网络配置重置之后第一件事是重新确认网段和网关地址然后逐条恢复端口转发规则不要假设它们还在。5.2 IP 冲突、租约漂移与休眠唤醒后的失联地址冲突在共享网络里不算高频但一旦发生就很难查因为它表现为时好时坏而不是完全不通。典型症状是虚拟机网络偶尔断一下、SSH 连接莫名断开、大文件传输中途失败。如果你给虚拟机配了静态地址而 Parallels 的 DHCP 又把同一个地址分给了另一台虚拟机就会形成这种间歇性故障。排查方式很直接宿主机上查看 ARP 表同一个 IP 出现两个不同 MAC 地址就是冲突了。彻底解决只能让其中一台改地址或者调整地址规划把静态地址和动态池彻底分开。另一个高频问题是休眠唤醒后的失联。Mac 合盖休眠再打开NAT 会话会全部失效虚拟机里已经建立的连接长连接、数据库连接池会处于假死状态页面转圈但不断开。解决办法是唤醒后主动断开重连或者在虚拟机里配置更积极的 TCP 保活。这个细节在做长时间构建、跑长连接任务时特别重要我踩过好几次最后干脆改成唤醒后重启虚拟机的网络服务。5.3 名字解析、DNS 顺序与 IPv6 的干扰共享网络下的 DNS 通常是转发到宿主机当前使用的解析服务这带来一个特性宿主机换了网络或换了 DNS虚拟机的解析行为跟着变。常见症状是能 ping 通 IP 但域名解析失败或者解析结果和预期不一致。排查思路是先在一个已知可用的公共 DNS 上做对照测试确认是解析链路问题还是服务本身问题。如果对照可用说明是转发链路出了问题可以临时在虚拟机上指定公共 DNS 作为兜底。另外如果你在宿主机的 hosts 文件里做了本地域名映射虚拟机是看不到的因为那是宿主机的本地解析范围这类宿主机能打开、虚拟机打不开的情况不要往网络上找原因。IPv6 是另一个隐形干扰源。共享网络对 IPv6 的支持取决于宿主机当前网络环境如果宿主机所在的网络下发了 IPv6 但虚拟机侧支持不完整会出现解析优先走 IPv6、连接超时后回落 IPv4 的现象表现为第一次访问特别慢。遇到这种情况可以在虚拟机里临时关闭 IPv6 做对照验证确认是这个原因再做长期配置。5.4 双网卡叠加导致的默认路由错乱给虚拟机配两块网卡是常见操作一块共享网络出外网一块仅主机或者桥接对接特定环境。这个组合很容易出现路由优先级问题表现为访问某个网段时流量走了错误的出口或者干脆没有出口。配置顺序上我建议把出外网的那块适配器放在第一位然后在虚拟机里检查默认路由指向。Windows 上用route print看清0.0.0.0那一条的接口Linux 上用ip route看default via后面的地址是不是共享网络的网关。如果默认路由指向了仅主机网卡那虚拟机就彻底出不了外网但内部通信又正常这种半通状态最容易让人误判成 DNS 问题。6. 常见问题速查表与分层排查套路6.1 四层排查法网络问题最忌讳东改一下西改一下越改变量越多。我习惯固定用四层法每一层只验证一件事验证通过才进入下一层。第一层是链路层确认虚拟机里有网卡、网卡处于已连接状态、有地址。第二层是网关层从虚拟机 ping 网关地址不通就说明虚拟网络本身没建立起来往上查宿主机。第三层是宿主机连通性从宿主机 ping 虚拟机地址这一层验证的是共享网络那条直连链路。第四层才是应用层用nc或者具体的客户端去连端口验证服务和防火墙。这四层顺序的好处是每一层的失败原因都是明确的、互不重叠的。我做支持工作的时候问对方三个问题基本就能定位虚拟机里ipconfig拿到的地址是多少能 ping 通网关吗宿主机能 ping 通虚拟机的地址吗三个答案一出来问题在哪一层就确定了。6.2 故障速查表现象最可能的原因处理方向宿主机看不到虚拟网卡系统授权未通过或后台服务异常检查隐私与安全性里的扩展授权重启宿主机虚拟机拿不到地址虚拟网卡未连接或 DHCP 异常确认适配器已勾选连接重启虚拟机网络虚拟机 ping 不通网关虚拟网络未建立重置网络配置后重启应用宿主机 ping 不通虚拟机虚拟机防火墙拦 ICMP改用端口探测验证服务是否可达端口转发无效虚拟机地址变了改为静态地址重建转发规则虚拟机连不上宿主机服务服务监听在回环地址改为监听全部地址访问网关地址桥接后无外网桥接目标网卡无外网出口换桥接目标或开启互联网共享解析异常但 IP 可通DNS 转发链路问题指定公共 DNS 做兜底长期连接频繁断开休眠唤醒导致 NAT 会话失效唤醒后重连配置 TCP 保活偶发断流地址冲突检查 ARP 表重新规划地址6.3 常用诊断命令与读法命令本身不难难的是读懂输出。下面这几个是我用得最多的附上读法要点。# 宿主机确认虚拟网卡与网段 ifconfig vnic0 # 宿主机查看路由表确认虚拟网段指向哪块网卡 netstat -rn | head -20 # 宿主机查看 ARP 邻居判断地址冲突 arp -a # 宿主机探测虚拟机端口 nc -vz 10.211.55.100 22# Windows 虚拟机查看完整地址信息重点是网关与 DNS ipconfig /all # Windows 虚拟机确认默认路由走哪块网卡 route print -4 # Windows 虚拟机测试端口可达性比 ping 更接近真实业务 Test-NetConnection 10.211.55.1 -Port 3306读ifconfig时重点看inet后面的地址和status: active读netstat -rn时找default那一条确认出口读arp -a时注意同一 IP 是否对应两个 MAC。这三处看懂了绝大多数疑难杂症都能定位到位。7. 收尾之前配置备份、快照与彻底卸载7.1 配置备份与快照策略网络配置有个很讨厌的特性它不跟着虚拟机快照一起回滚。你把虚拟机恢复到上周的状态宿主机侧的端口转发规则、网段设置还是现在的样子于是出现虚拟机回滚了但网络不通的诡异现象。我的做法是给网络配置单独做一份存档把 Parallels 偏好设置里的网络界面截图同时把自定义的端口转发规则、静态地址规划写进一个文本文件和项目代码放在一起。虚拟机快照则按重要节点打比如环境初始化完成后、装完依赖后、接入新网络前。这两套东西分开管理互不干扰恢复的时候心里有数。另外建议把虚拟机的静态地址规划做成固定表格记录每台虚拟机的地址、用途、端口映射关系。虚拟机一多这个表格能省掉大量排查时间。7.2 卸载顺序与残留清理彻底卸载是个容易被轻视的环节尤其是你换机器或者升级大版本的时候。卸载不干净的典型后遗症是系统设置里残留一块虚拟网卡导致其他网络软件行为异常或者占用大量磁盘空间找不到源头。我的顺序是这样的先关掉所有虚拟机退出应用本体然后在系统设置里检查是否存在残留的虚拟网络接口如果有就在那里删掉接着清理用户目录和系统配置目录下与应用相关的配置文件夹注意这些目录里可能有你之前的网络配置和导出文件动手前先扫一遍最后检查后台服务项是否还有残留有就一并处理。# 清理前先看有哪些相关目录确认内容再删 ls -la ~/Library/Parallels ls -la /Library/Preferences | grep -i parallels # 检查后台服务残留 sudo launchctl list | grep -i parallels删完之后重启一次再去系统设置里确认虚拟网卡没有复活。这一步的验证很关键因为有些虚拟网卡是服务启动时创建的不重启看不出来。如果你在卸载之前已经用了很长时间建议顺手把虚拟机磁盘镜像文件的位置也确认一遍这些文件往往体积极大是最容易被遗忘的空间占用来源。我在实际使用中的体会是Parallels Desktop 的网络问题遵循一个很朴素的规律你越是想让它做成跟真机一样越容易出问题因为它本质上是宿主机上的一个受控隔离环境。接受这个前提把共享网络当成宿主机与虚拟机之间的一条私有直连链路外加一个受控的外网出口剩下的配置就都顺理成章了。静态地址定下来端口转发规则写清楚宿主机服务监听地址改对日常开发基本不会再有意外。最后分享一个小习惯我每次接入一个新的网络环境换办公室、换家里路由、去客户现场第一件事不是直接开工而是先花一分钟在虚拟机里确认三件事——地址、网关、外网可达性。这三项确认完了后面无论写代码还是连数据库都不会踩到网络的坑。这个一分钟的检查帮我省掉过至少十次两个小时的排查。