上周同事的实验机上出了一件特别典型的事：VMware Workstation 里跑着一台最小化安装的 CentOS，宿主机是 Windows 11。他在虚拟机终端里敲ping 192.168.109.1，四条记录全是 Request timeout；反过来在宿主机 cmd 里ping 192.168.109.128，四个包一个不丢。同一对机器、同一个虚拟网络，两个方向的结果完全相反，他一度怀疑是虚拟机装坏了。
这不是玄学。虚拟机 ping 主机这件事，背后同时牵扯到虚拟交换机、虚拟 NAT 设备、宿主机路由表、两侧防火墙策略这几层东西，任何一层少了一块，"ping 不通"就会发生。也正因为如此，VMware 虚拟机 ping 不通主机从来不是一个问题，而是一类问题的统称——你看到的报错是同一个，但根因可能完全不同。
这篇内容就是把这套链路拆开讲清楚：先讲 ping 在虚拟网络里到底走了哪些路，再讲桥接、NAT、仅主机三种模式的差异，然后给出一套从下往上、可以照着抄的排查顺序，最后补上几个只有踩过才会知道的细节，比如 NAT 模式下回包走错网卡、DHCP 租约漂移导致的"昨天还通今天不通"。无论你是刚装完虚拟机的学生，还是天天拿虚拟机做测试环境的运维和开发，都能从里面找到能直接用的东西。全文以 Workstation 为主，Player 和 Fusion 的逻辑基本一致，只是界面入口略有差别。
1. ping 在虚拟机场景里验证的究竟是哪一层
1.1 一个 Echo 包从虚拟机到宿主机要走完的六步
很多人把 ping 理解为"测试两台机器通不通"，这个理解没错，但太粗。真实情况是，一个 ICMP Echo Request 从虚拟机里发出去，至少要经历下面这六个动作，缺一环就断。
第一步，ping 命令在内核里生成一个 ICMP Echo Request 报文，类型 8、代码 0，带上一个标识符和序号。第二步，内核查自己的路由表，决定这个目标地址该走哪块网卡、用哪个源 IP 发出去。这一步用的是最长前缀匹配，不是"哪块网卡先起来就用哪块"。第三步，判断目标地址和本机地址是不是同网段：同网段就查 ARP 缓存拿对方 MAC，缓存里没有就发一个 ARP 广播；跨网段就不查目标 MAC 了，直接把包发给网关对应的 MAC。第四步，报文交给 VMware 的虚拟网络组件——在 NAT 和仅主机模式下是 VMnet8、VMnet1 这两块虚拟交换机，在桥接模式下则通过 VMnet0 直接桥到物理网卡上。第五步，虚拟网络组件决定这个包的归宿：送进宿主机的协议栈，还是经过虚拟 NAT 设备转换后放到物理网络上。第六步，宿主机内核收到包之后，查自己的路由和防火墙策略，决定要不要回一个 Echo Reply。
回程的六个动作是对称的。所以"ping 不通"这四个字，可能对应的是 ARP 没解析成功、可能对应的是宿主机防火墙把入站 ICMP 丢了、也可能对应的是回包从另一块网卡出去了。你在排查时看到的现象一样，要查的地方完全不同，这就是为什么必须按顺序排查，而不是到处乱试。
1.2 一个容易被混淆的结论：ping 通不等于服务能访问
这是我带新人时反复强调的一点。ICMP 工作在网络层，HTTP 的 80 端口工作在传输层，两者互不隶属。很多生产环境为了减少被扫面，会主动关掉 ICMP 响应，但 Web 服务照跑不误；反过来，你 ping 得通，不代表 22 端口一定开着。
举个实际的例子：你在虚拟机里跑了一个 Nginx，宿主机浏览器打不开，但ping虚拟机地址是通的。这时候如果继续在 ping 上较劲，就完全跑偏了。正确做法是转身去查服务本身——第一，确认 Nginx 的listen是不是写成了127.0.0.1:80，只监听回环地址的话外部永远连不上，得改成0.0.0.0:80或者具体网卡地址；第二，确认虚拟机的防火墙放行了 80，firewall-cmd --list-ports或者ufw status；第三，确认端口真的在监听，ss -lntp | grep 80。这三步比反复 ping 有效得多。
我在排查时习惯把 ping 定位成一个"最低成本的链路探活工具"，它的价值在于快速把问题切成两半：ping 通，说明网络层没问题，往上层查；ping 不通，说明网络层就有问题，往下层查。仅此而已，不要给它赋予更多含义。
1.3 排查时真正用得上的几个参数
ping 的默认输出信息量其实不够，几个参数能让它变得好用很多。下面这张表是我自己在排查虚拟网络时常用的组合。
| 参数 | 平台 | 实际用途 |
|---|---|---|
-c 4 | Linux | 只发四个包，避免一直刷屏，适合脚本化验证 |
-n 4 | Windows | 同上，同时加-w 1000把单包超时压到 1 秒 |
-4/-6 | 双平台 | 强制走 IPv4，避免解析到 IPv6 地址后误判不通 |
-I ens33 | Linux | 指定从哪块网卡发出，用来验证源地址选择是否正确 |
-S 192.168.109.1 | Windows | 指定源地址，宿主机多网卡时特别关键 |
-s 1400 | 双平台 | 指定包大小，用来定位 MTU 相关的诡异问题 |
tracert/traceroute | 双平台 | 看包在哪一跳停住，是定位"包出去了但没回来"的主力工具 |
有一点很隐蔽但经常遇到：某些系统上ping 主机名会优先解析到 IPv6 地址，然后报一个"未知的名称或服务"或者直接超时，让你以为网络断了。其实强制加-4就通了。排查虚拟网络时，我建议一律用 IP 而不是主机名，先把 DNS 这个变量从等式里拿掉，等网络层确认没问题了再回头查解析。
2. 三种网络模式决定了 ping 的转发路径完全不同
2.1 桥接模式：虚拟机就是同一网段里的另一台机器
桥接模式（Bridged）的逻辑最接近物理世界。虚拟机通过 VMnet0 桥接到宿主机的物理网卡上，从物理网络的 DHCP 服务器（通常是家里的路由器）拿到一个和宿主机同网段的地址，比如宿主机是 192.168.1.10，虚拟机是 192.168.1.11。
这个模式下，"虚拟机 ping 主机"和"家里的另一台笔记本 ping 主机"几乎没有区别，包直接从虚拟交换机桥到物理网卡，再进宿主机的协议栈。所以桥接下 ping 不通，八成不是 VMware 的问题，而是宿主机的防火墙或者物理网络的隔离策略在起作用，比如某些公司 WiFi 开了客户端隔离，同一网段的设备互相看不到。
桥接模式有个坑要注意：当宿主机同时有有线网卡和无线网卡时，VMnet0 默认桥接的到底是哪一块，需要在虚拟网络编辑器里确认。如果桥错了网卡，虚拟机会拿不到符合预期的地址，ping 主机的结果自然一团糟。我一般会在虚拟网络编辑器里把桥接目标手动指定成正在上网的那块物理网卡，而不是留给它自动选择。
2.2 NAT 模式：真正干活的是背后的虚拟 NAT 设备
NAT 模式是 Workstation 的默认配置，结构比桥接复杂一层。这里有三样东西同时在位：VMnet8 这块宿主机上的虚拟网卡，一个虚拟 DHCP 服务器，以及一个虚拟 NAT 设备。
默认情况下，宿主机的 VMnet8 地址是 192.168.x.1，虚拟 NAT 设备的地址是 192.168.x.2，DHCP 分配给虚拟机的地址从 192.168.x.128 到 192.168.x.254。虚拟机拿到的默认网关指向的就是那个 .2，也就是虚拟 NAT 设备。这个网段号在你安装时是随机生成的，所以每个人的数字不一样，别照抄别人的 192.168.109，先用自己的ipconfig看一眼。
NAT 模式下最有价值的认知是这句话：虚拟机 ping 宿主机，要分清楚你 ping 的是哪个地址。ping 192.168.x.1 走的是虚拟交换机内部，属于同网段直连，路径最短；ping 宿主机物理网卡上的地址（比如 192.168.1.10），包得先发给网关 .2，经过虚拟 NAT 设备做地址转换才能到宿主机，这条路径长得多，中间环节也多得多。
所以我给的建议很明确：在 NAT 模式下验证虚拟机和宿主机的连通性，一律 ping VMnet8 那块虚拟网卡的地址。这是最干净、变量最少的路径。等这条通了，再去排查访问物理网络的问题，思路会清楚很多。
2.3 仅主机模式：通主机是设计目标，通外网不是
仅主机模式（Host-only）只有 VMnet1 这一块虚拟交换机和宿主机上的对应虚拟网卡，连虚拟 NAT 设备都没有。虚拟机之间、虚拟机和宿主机之间可以互通，但出口是封死的。
这个模式非常适合做隔离实验，比如你搭一个只在本机可见的测试集群，不想让里面的机器碰到外网。但要清楚一点：在仅主机模式下，虚拟机 ping 外网地址必然失败，这不是配置错误，是设计如此。很多人在这个模式下折腾半天"为什么 ping 不通百度"，其实只要切一次网络模式就好了。判断方法很简单，看虚拟机的默认网关——仅主机模式通常压根没有网关，或者网关指向一个不存在的地址。
2.4 三种模式的能力对照与确认方法
| 能力 | 桥接 | NAT | 仅主机 |
|---|---|---|---|
| 虚拟机与宿主机互通 | 可以 | 可以（建议走 VMnet8 地址） | 可以 |
| 虚拟机访问外网 | 可以 | 可以 | 不可以 |
| 外网设备访问虚拟机 | 可以 | 需要端口转发 | 不可以 |
| 虚拟机能拿到的地址来源 | 物理网络 DHCP | VMware 虚拟 DHCP | VMware 虚拟 DHCP |
| 宿主机的网关是否参与 | 是 | 是（经虚拟 NAT） | 否 |
| 宿主机上的对应适配器 | VMnet0 | VMnet8 | VMnet1 |
要确认自己的网络到底长什么样，入口在 Workstation 菜单的"编辑"→"虚拟网络编辑器"。那里能直接看到每块虚拟交换机的子网地址、DHCP 分配范围和 NAT 设置。我强烈建议在做任何网络实验前先打开看一眼，把三个数字记下来：VMnet8 的宿主地址、网关地址、虚拟机当前地址。这三个数字对上了，网络层基本就是通的，对不上，后面怎么调都是白费劲。
注意：虚拟网络编辑器里的"还原默认设置"会重建全部虚拟网卡，把之前手工改过的子网、DHCP 范围全部冲掉。如果你的实验环境是照着一份文档配的，慎用这个按钮，用了之后要重新核对所有地址。
3. 动手之前先把两端的地址清单捋清楚
3.1 虚拟机这一侧要确认的四样东西
第一是接口地址，Linux 用ip addr或者ip -4 addr show，Windows 用ipconfig /all。重点看两件事：网卡是不是 UP 状态、有没有拿到 IPv4 地址。如果只有127.0.0.1和::1，说明 DHCP 没成功，网络层压根没起来，后面所有排查都是浪费时间。
第二是路由表，Linux 用ip route，Windows 用route print -4。你要确认存在一条default via 192.168.x.2这样的默认路由，并且网段和接口对得上。NAT 模式下没有默认路由，虚拟机就只能在本网段内活动。
第三是 ARP 缓存，这个后面单独讲。第四是 DNS，cat /etc/resolv.conf，顺带确认一下systemd-resolved有没有把配置顶掉。DNS 只影响用域名 ping 的场景，用 IP ping 时可以先不管它，但如果你 ping 的是主机名，就必须先确认这一项。
3.2 宿主机这一侧要确认的三样东西
第一，ipconfig /all里有没有 VMware Network Adapter VMnet8 和 VMnet1，状态是不是"已启用"。这两块适配器被禁用是最常见的"莫名其妙不通"原因之一，有时候是装了某个网络工具包之后被顺手关掉的。
第二，VMnet8 的地址是不是还在那个 192.168.x 网段，有没有被其他软件改过。我就遇到过宿主机上装了某个容器平台，它往同一网段插了一块虚拟网卡，抢了路由优先级，导致虚拟机发出去的包被路由到了错误的地方。
第三，宿主机上是不是有多块同网段的适配器。这个问题在 NAT 模式下特别致命，因为它会导致回包选错出口，具体在第五节展开。
3.3 ARP 表是判断"包到底出没出去"的最快工具
排查网络问题时，ARP 表给我的信息量往往比 ping 本身还大。顺序是这样的：在虚拟机里先ping -c 2 192.168.x.1，然后立刻arp -n（Linux）或者arp -a（Windows），看网关地址 192.168.x.2 或者宿主机地址有没有解析出 MAC。
如果 ARP 表里有对应的 MAC 地址，说明二层是通的，包确实发出去并被回应了，问题更可能在 ICMP 策略层面。如果 ARP 表里是incomplete或者压根没有这一条，说明二层就没通，包发出去没人应答，这时候该去查虚拟交换机、网卡状态、网段配置，而不是去查防火墙。这一步能帮你省掉大量盲试成本。
Linux 上还可以用ip neigh show dev ens33只看某块网卡，比全量arp -n干净。MAC 地址出现FAILED或者INCOMPLETE状态，就是明确的二层不通信号。
3.4 用 traceroute 定位丢包停在哪一跳
当 ping 不通时，traceroute -n 目标地址（Linux）或tracert -d -4 目标地址（Windows）能告诉你包走到哪一步停住。加-n或者-d是为了跳过反向解析，速度快很多。
结果怎么读：第一跳就是网关地址，如果第一跳就全是星号，问题在虚拟交换机和网关这一层，比如网关地址配错了、虚拟 NAT 设备没起来。第一跳通、后面全断，说明包已经交到宿主机的协议栈了但被拦下了，方向应该转到宿主机防火墙。如果第一跳通、第二跳就是目标地址但显示无响应，那就是目标主机主动不回 ICMP，属于策略问题而非链路问题。
4. 宿主机侧最容易吞掉 ICMP 的两个位置
4.1 Windows 防火墙默认不放行入站 Echo
这是"宿主机 ping 虚拟机通、虚拟机 ping 宿主机不通"这个特定现象的第一嫌疑人。Windows Defender 防火墙的默认策略是入站阻止、出站允许，而 ICMP Echo Request 的入站规则默认不开。也就是说，请求能出去，回来的应答进不来，表现就是虚拟机侧一路超时。
临时验证的方法很简单：把当前网络配置文件的防火墙先关掉试一次。如果关了立刻通，根因就锁定了。但验证完一定要打开，别图省事长期关着。
长期方案是单独放行 ICMPv4 的入站规则，用管理员权限的 PowerShell 或者 cmd 执行：
netsh advfirewall firewall add rule name="Lab-ICMPv4-In" protocol=icmpv4:8,any dir=in action=allow这条规则只放行 Echo Request，范围可控。如果只想对某个网段放开，可以加上remoteip=192.168.109.0/24，把暴露面收敛到实验网段。用完不想要了就按名字删掉：
netsh advfirewall firewall delete rule name="Lab-ICMPv4-In"图形界面的路径是"高级安全 Windows Defender 防火墙"→"入站规则"→"新建规则"→"自定义"→"协议和端口"里选 ICMPv4，再选"回显请求"。操作本身不复杂，但注意一定要在"入站规则"里建，有人误建到出站规则里，然后疑惑为什么没效果。
4.2 第三方安全软件和企业策略会覆盖你的规则
如果宿主机装了第三方安全套件，或者加入了域、有统一下发的策略，你手工加的规则可能不生效。判断方法是执行netsh advfirewall show allprofiles，看当前活动的是哪个配置文件（域、专用、公用），以及防火墙是否被组策略接管。
我一直用的一个快速定位技巧：在虚拟机里 ping 宿主机的过程中，同时在宿主机上用netsh advfirewall firewall show rule name=all | findstr ICMP确认规则存在，再打开防火墙日志（netsh advfirewall set allprofiles logging droppedconnections enable，日志默认落在系统目录下的防火墙日志文件里），看丢包记录里有没有你的源 IP。有记录，就是防火墙拦的，铁证。
4.3 虚拟机自己的防火墙也在拦
方向反过来也一样。宿主机 ping 虚拟机不通，很可能是虚拟机自己的防火墙不放 Echo。
firewalld 的常见情况是默认不拦 echo-request，但如果有人手动加过--add-icmp-block=echo-request，就会被拦。检查命令是firewall-cmd --list-icmp-blocks，有输出就说明被拦了，用下面两条解除：
firewall-cmd --permanent --remove-icmp-block=echo-request firewall-cmd --reloadufw 的默认策略通常是拒绝入站，但自带的/etc/ufw/before.rules里一般预留了 ICMP 放行段。如果你精简过这个文件，或者从别处拷了一份配置，这段就没了。检查方式是grep -n "echo-request" /etc/ufw/before.rules，没有匹配项就说明要补回去。
如果系统上是直接的 iptables 或 nftables 规则，用这条看有没有 ICMP 相关的拒绝规则：
iptables -L INPUT -n -v --line-numbers | grep -i icmp排查这类问题时，我一般先临时清空策略确认链路通不通，确认之后再加回最小必要的放行规则，而不是反过来一条条加规则试。先证明链路没问题，再谈策略，顺序不能反。
5. NAT 模式下回包走错路，这个隐蔽问题值得单独讲
5.1 宿主机多网卡时的源地址选择
NAT 模式下有一个现象特别迷惑：虚拟机 ping 宿主机的物理网卡地址，有时候通、有时候不通，重启一下又变了。这类不稳定现象，十有八九是源地址选择或者回程路由的问题。
原理是这样的：宿主机可能同时拥有物理有线网卡、无线网卡、VMnet1、VMnet8，再加上各种开发工具装出来的虚拟适配器。当宿主机要回一个包给虚拟机时，内核会查自己的路由表决定从哪块网卡发。如果多块网卡上存在同网段或者重叠网段的路由条目，内核可能选中一块"看起来对但实际不对"的网卡，包从错误的接口发出去，虚拟机那边自然收不到。
这个问题的典型触发场景是：宿主机连的是 192.168.1.0/24 的 WiFi，而某次装软件时不小心把某块虚拟适配器也配成了 192.168.1.x 网段，和物理网络撞了。这时候两套路由条目打架，回包方向就不确定了。
5.2 用路由查询命令验证回程路径
Linux 上最直接的命令是ip route get，它会明确告诉你内核会怎么处理这个目标地址：
ip route get 192.168.109.128输出里会带上走哪块网卡、源地址是谁。如果源地址不是你预期的那个，问题就找到了。Windows 上没有完全等价的单条命令，但可以用route print -4看路由表，配合tracert -d -4看实际路径，再结合ping -S 源地址 目标地址强制指定源地址做对照实验。如果强制指定源地址之后通了，那就百分百确认是源地址选择问题。
5.3 把对话地址固定在 VMnet8 上
解决思路其实很朴素：不要让虚拟机和宿主机在多个地址之间"随便挑一个"来对话。在 NAT 模式下，把虚拟机的连通性测试目标固定成 VMnet8 的宿主地址，把宿主机侧访问虚拟机的目标固定成虚拟机的 DHCP 地址，两边都锁定在同一块虚拟交换机内部。这条路径不经过物理网络，不参与任何 NAT 转换，路径最短、变量最少、最稳定。
如果你一定要在 NAT 模式下访问宿主机的物理网卡地址，那就老老实实把源地址和路由确认清楚，别指望它每次都稳。这不是配置质量问题，是 NAT 这个机制本身的特性决定的。
6. 从下往上的六步排查顺序与现象对照
6.1 六步走的固定动作
第一步，确认虚拟网卡存在且启用。宿主机ipconfig /all看 VMnet8、VMnet1 有没有、是不是"已启用"。虚拟机上ip link show看网卡状态是不是 UP。
第二步，确认两端地址同网段。虚拟机地址、VMnet8 宿主地址、网关地址，三个数字必须落在同一个 192.168.x.0/24 里。对不上，先去虚拟网络编辑器里改，别往下走。
第三步，确认 ARP 能解析。按 3.3 的方法看 ARP 缓存里有没有对端 MAC。没有就回头查网卡和虚拟交换机。
第四步，交叉验证防火墙。Linux 上systemctl stop firewalld或ufw disable，Windows 上临时关防火墙，两边各关一次，看 ping 是否立刻恢复。恢复就锁定根因，然后按第 4 节的方法加最小规则，不要长期关着。
第五步，确认路由和源地址。用ip route get或者ping -S确认回程方向正确，特别是有多网卡的宿主机。
第六步，抓包确认。前面五步都没定位到，就在宿主机和虚拟机上同时抓包看 ICMP 报文到底走到哪一步。这是最后手段，但最准确。
6.2 现象与根因对照表
| 现象 | 最可能的原因 | 验证命令 | 处理动作 |
|---|---|---|---|
| 两个方向都不通，ARP 缓存为空 | 网卡未启用或不在同网段 | ipconfig /all、ip addr | 检查虚拟网卡状态与子网配置 |
| 虚拟机 ping 宿主机超时，反向正常 | 宿主机入站 ICMP 被拦 | 临时关防火墙对比 | 加入站 ICMPv4 放行规则 |
| 宿主机 ping 虚拟机超时，反向正常 | 虚拟机防火墙拦 Echo | firewall-cmd --list-icmp-blocks | 移除 icmp-block 项 |
| 时通时不通，重启后结果变化 | 多网卡导致源地址选择异常 | ip route get、ping -S | 统一走 VMnet8 地址 |
| 仅主机模式下 ping 外网全失败 | 该模式本身无出口 | 看默认网关是否存在 | 需要外网就换 NAT 或桥接 |
| ping 通但网页打不开 | 服务监听地址或端口未放行 | ss -lntp、firewall-cmd --list-ports | 改监听地址与端口放行 |
| 昨天还通，今天突然不通 | DHCP 租约变更导致地址漂移 | 对比当前地址与文档记录 | 改为静态地址或固定租约 |
这张表我基本是手边常备的。遇到问题先对号入座能省掉一半时间，剩下的靠具体验证。
7. 通了之后：主机访问虚拟机服务与共享目录
7.1 宿主机直接访问虚拟机里的 Web 服务
网络层通了之后，下一步通常是让宿主机访问虚拟机里跑的服务。桥接和 NAT 两种模式的做法不一样。
桥接模式下最简单，虚拟机的地址就在物理网段里，宿主机浏览器直接输http://虚拟机IP:端口就行，中间没有任何转换。前提是虚拟机的防火墙放行了对应端口，服务监听地址不是回环。
NAT 模式下有两种做法。一种是把虚拟机当成一台网段内的机器，宿主机通过 VMnet8 直接访问虚拟机的 192.168.x.128 地址，因为宿主机本身就有这块网卡，同网段直连，不需要端口转发。我推荐这一种，简单直接。另一种是配端口转发，让宿主机以外或者物理网络上的其他设备也能访问，那就需要在虚拟网络编辑器里给 VMnet8 加一条 NAT 端口映射，把宿主机的某个端口映射到虚拟机的 IP 加端口上。
两种做法的选择逻辑很清晰：只有宿主机自己要访问，走 VMnet8 直连；需要让局域网里的其他设备访问，才配端口转发。别为了一个本机测试的需求去折腾端口转发，白白多一层出错可能。
7.2 加端口转发的具体位置和注意点
端口转发配置在虚拟网络编辑器的 VMnet8 条目里，点"NAT 设置"，在"端口转发"标签页添加。填写的四项分别是：宿主机端口、虚拟机 IP、虚拟机端口、协议类型。
几个容易出错的点。第一，填完之后一定要点"确定"再点"应用"，只关窗口不生效。第二，宿主机端口不要选已经被占用的，选之前用netstat -ano | findstr 端口号确认一下。第三，虚拟机 IP 建议先改成静态，否则 DHCP 换租约之后转发规则就指向一个不存在的地址了。第四，转发规则只在 NAT 模式下有效，切到桥接或仅主机模式后自动失效，别到时候疑惑为什么规则没生效。
7.3 装不装工具包，决定的不是网络而是体验
网络通了之后，另一个高频需求是宿主机和虚拟机之间的文件互传和剪贴板共享。这件事和网络配置无关，取决于虚拟机上有没有装 VMware Tools 或者它的开源版本 open-vm-tools。
Linux 上现在的主流做法是直接装开源版本，源里都有：Debian 系apt install open-vm-tools open-vm-tools-desktop，RHEL 系dnf install open-vm-tools open-vm-tools-desktop。带-desktop的包负责图形界面的分辨率自适应、剪贴板共享和拖拽复制，不带的后台服务负责共享文件夹、时间同步这些。装完重启一次，体验会明显不一样。
共享文件夹需要在虚拟机设置里先启用，指定宿主机上的一个目录，然后虚拟机里挂载才能看到。这个功能我用来在宿主机编辑代码、虚拟机里直接跑，比每次走 SFTP 传文件效率高不少。
8. 两个后遗症：地址漂移和快照回滚
8.1 DHCP 租约导致的"昨天还通今天不通"
这是我遇到次数最多的"非故障故障"。虚拟机的地址是虚拟 DHCP 服务器分配的，租约到期或者虚拟机重启时间够长，拿到的地址可能就变了。你昨天配好的端口转发、写好的 hosts 记录、记事本里记的访问地址，一夜之间全部指向一个失效的地址。
判断方法很简单：把当前地址和昨天记录的地址比一比。一样就不是这个问题，不一样就找到了。
彻底解决的办法是改成静态地址。有两种做法，一种是在虚拟机系统内部配置静态 IP，另一种是在虚拟 DHCP 服务器的配置里给虚拟机 MAC 绑定固定租约。我一般选前者，因为配置在虚拟机里，跟着虚拟机走，迁移快照或者换宿主机都不用重新配。配置时要注意把网关、DNS 一起写全，尤其是 NAT 模式下的网关，必须指向虚拟 NAT 设备的地址，写错了就直接没网。
顺带提一个有用的东西：宿主机的 DHCP 租约文件，Windows 上通常在C:\ProgramData\VMware目录下，里面有各台虚拟机拿到过的地址记录。排查地址冲突或者确认租约状态时可以翻一翻。
8.2 快照回滚之后网络配置对不上
快照是个好东西，但它会带来一个副作用：你回滚的不仅是系统文件，还有一部分网络状态。如果回滚前的虚拟机和宿主机的虚拟网络配置相比现在有变化，回滚之后就可能出现地址对不上、路由失效的情况。
我的习惯是，在做和网络相关的实验之前先打一个快照，做完之后如果不理想就回滚。但回滚之后一定会做一件事：把宿主机和虚拟机的 IP 配置重新核对一遍，特别是那些在快照之后手工改过的子网、DHCP 范围、端口转发规则。这些改动不会因为虚拟机回滚而自动还原，两边状态就错位了。
还有一点，如果实验过程中改过虚拟网络编辑器的配置，那就要留意"还原默认设置"这个按钮的行为——它会重建所有虚拟网卡和子网，快照里的虚拟机可能带着一份和当前虚拟网络完全不匹配的 IP 配置。这种情况的表现就是网络怎么都不通，但看配置又好像都对，因为对的是"过去的"配置。
讲了这么多，我自己在实际操作中体会最深的一点是：虚拟机 ping 不通这件事，八成的根因就那么两三个——防火墙没放行 ICMP、IP 和网关没对上、NAT 模式下对话地址选错了。真正的功夫不在"能不能修好"，而在"能不能在五分钟内判断出是哪一类"。我的做法是每次遇到问题先按第 6 节的顺序走一遍，先看 ARP，再看防火墙，最后看路由，绝大多数情况下走到第二步就有答案了。另外强烈建议把每台虚拟机的地址、网关、子网固定下来之后写进一个文档，别指望脑子记得住那些 192.168 开头的数字，等你手上有七八台虚拟机的时候，这份文档能救你很多时间。
