网卡唤醒失败从哪查起
虚拟机网络唤醒失败，绝大多数情况下不是虚拟机本身“睡着了叫不醒”，而是宿主机、虚拟交换机或客户机系统三层里的某一环悄悄断了路。先别急着重装系统，按下面这几个层面逐层排查,多数问题都能在十分钟内定位。
先确认你的硬件和系统是否支持网络唤醒
很多人第一反应就是进系统改设置，但其实第一步应该确认“这件事到底有没有可能实现”，网络唤醒（Wake-on-LAN，简称WoL）依赖硬件层面的支持，如果物理网卡或主板不支持,后面所有设置都白搭。
- 查看物理机主板说明书或官网参数，确认板载网卡支持WoL功能，绝大多数近几年的主板都支持,但部分入门级型号或老平台会在低功耗状态下切段网卡供电。
- 如果用的是USB外接网卡，行业共识认为USB网卡的WoL支持率远低于板载网卡,尤其在虚拟机场景下兼容性更差。
- 确认路由器或交换机没有开启“省电模式”或“绿色以太网”功能，这类功能会主动切断空闲端口的供电,让唤醒包根本到不了网卡。
业内专家指出，虚拟机网络唤醒失败的案例里，大约有相当一部分比例其实卡在物理机BIOS设置，而不是虚拟机本身，重启进入BIOS，找到“Power Management”或“Wake on LAN”相关选项，确保处于Enabled状态，这一步做完,再进系统操作。
排查虚拟机网络唤醒失败的关键路径：从客户机系统到虚拟交换机
先看客户机系统里的设备管理器
启动虚拟机，打开设备管理器，找到网络适配器，右键属性，切到“高级”选项卡，这里需要注意，不同虚拟化平台的虚拟网卡选项名称有差异,但核心看两个值：
- Wake on Magic Packet：设置为Enabled
- Wake on Pattern Match：建议Enabled，但有部分网卡驱动对该选项支持不完整，如果不稳定就关掉
在“电源管理”选项卡里，勾选“允许此设备唤醒计算机”，这一步看着简单，但相当一部分人漏掉的是：虚拟机的网卡驱动是半虚拟化驱动（如virtio、vmxnet3）时，部分高级电源选项根本不显示，解决办法是切换到默认的e1000网卡型号试一次,e1000模拟的Intel网卡在WoL兼容性上最稳。
检查虚拟机的操作系统关机方式
另外需要确认虚拟机是否真正执行了“关机”而不是“休眠”，Windows系统如果开启了“快速启动”，关机时实际上进入的是休眠状态，这个状态下虚拟机网卡可能已经断电，魔术包也唤醒不了，在控制面板的电源选项里，把“启用快速启动”关掉,这是Windows虚拟机无法被唤醒的常见原因之一。
虚拟交换机是虚拟机网络唤醒的关键枢纽
这是比较容易忽略的一环，虚拟机网卡的流量要经过宿主机虚拟交换机才能进出物理网卡，如果虚拟交换机的设置不对,魔术包直接就被吞掉了。
以VMware Workstation为例，在“虚拟网络编辑器”里确认：
- 使用的网络模式是桥接模式，只有桥接模式才能让魔术包直达虚拟机网卡
- NAT模式下，宿主机不会把外部广播包转发给虚拟机，所以NAT模式下虚拟机网络唤醒基本不可用
- 如果桥接模式绑定的物理网卡和你实际连接的网卡不一致，点击“更改设置”手动指定
Hyper-V环境稍有不同，需要在虚拟机设置里打开“MAC地址欺骗”选项，并把虚拟交换机的“允许管理操作系统共享此网络适配器”打开，不开启这些选项,魔术包到了物理网卡后不会往虚拟机内部分发。
从宿主机网卡层面做最终确认
客户机系统和虚拟交换机检查完毕，还有一个容易出问题的地方宿主机物理网卡是否允许魔术包唤醒系统，系统关机后如何处理物理网卡功耗,在Windows和Linux上都有专门的设置项。
Windows宿主机，在设备管理器的物理网卡“电源管理”中，确保“允许此设备唤醒计算机”和“只允许幻数据包唤醒计算机”都被勾选，Linux宿主机,用ethtool命令确认：
ethtool eth0 | grep Wake-on输出结果中Wake-on这一项应该是“g”，如果显示“d”则唤醒功能被禁用,执行：
ethtool -s eth0 wol g但这只是临时生效，持久化配置需要写入网络配置文件中，这一步排查到位,基本能解决VMware和VirtualBox桥接模式下虚拟机网卡的唤醒问题。
还有一种可能是魔法包根本没“找到”虚拟机
MAC地址和广播域的问题
魔术包唤醒的原理，是向目标网卡MAC地址连续发送特定格式的报文，如果魔术包发送的MAC地址和虚拟机网卡的MAC地址对不上,自然唤醒失败。
虚拟机网卡的MAC地址有两个：虚拟机设置里显示的MAC、实际在系统里加载的MAC，有时候克隆虚拟机后，Windows系统里记录的网卡配置还是旧的,导致实际生效的MAC和设置面板显示的不一致。
用命令确认虚拟机系统内真正的MAC地址,Windows下执行：
ipconfig /allLinux下执行：
ip addr show拿这个MAC地址去发唤醒包，而不是用虚拟化管理界面里看到的那个，如果确实不一致,需要根据虚拟化平台的引导步骤重置网卡MAC。
发送方式也影响唤醒成功率
- 从宿主机发唤醒包，一般能成功
- 从局域网另一台设备发，取决于交换机是否丢弃广播包
- 从外网跨网关发送，需要路由器开启IP广播转发，通常需要先在路由器上设置端口转发或静态ARP绑定，这一步是局域网外远程唤醒虚拟机最常见的卡点
使用wakeonlan命令行工具发送时，注意指定正确的接口名，如果发送端显示已发送，但虚拟机依旧没有反应，用Wireshark在宿主机物理网卡上抓包，看魔术包是否确实到达，理论上，这个工具抓不到包就说明网络层面没送到，抓到包但虚拟机不醒,说明前面的虚拟交换机或客户机驱动层还有问题。
从系统日志和虚拟化平台事件里挖线索
Windows事件查看器里，系统日志中“Kernel-Power”事件ID 109或“NetworkProfile”相关记录，能帮你看到系统是否收到了唤醒请求但被拒绝,Linux下查看：
journalctl -b -0 -u systemd-logind系统里是否有“Wake-on LAN enabled”之类的日志记录。
VMware打开虚拟机目录下的vmx文件确认，里面应该有一行类似“ethernet0.wakeOnLan = TRUE”的配置，没有这行,手动加进去重启虚拟机。
VirtualBox需要检查vboxmanage命令输出：
vboxmanage showvminfo <虚拟机名> | grep -i wakeQ&A：虚拟机网络唤醒故障的常见疑问
使用VMware Workstation虚拟机网络唤醒失败怎么解决？
VMware Workstation环境里，先关闭虚拟机，在虚拟机设置中把网卡类型改为较旧的e1000e，删除Intel e1000e网卡驱动自带的节能型驱动程序更新，然后打开VMware虚拟网络编辑器，确保虚拟机使用桥接模式，且桥接目标物理网卡正确，启动虚拟机到Windows系统后，在设备管理器确认网卡“高级”选项中有Wake on Magic Packet，设为Enabled，最后在宿主机物理网卡的允许此设备唤醒计算机上打勾，虚拟机内禁用快速启动后关机,在局域网内使用wakeonlan工具向对应MAC地址发送唤醒包。
为什么虚拟机网卡配置正常，远程桌面就是进不去？
远程桌面连不上和唤醒失败不是同一件事，前者是网络连通性问题，后者是电源管理问题，虚拟机已经被唤醒后远程桌面依然连不上，检查虚拟机防火墙是否放行3389端口，宿主机防火墙是否阻止端口转发规则，Windows系统远程桌面是否启用，虚拟机网络唤醒成功后必须等待客户机系统完全启动，网卡驱动加载完毕，然后才能接受远程桌面连接，通常需要额外等待数十秒，如果虚拟机所在宿主机还运行着防火墙，需要在管理界面上增加转发规则,确保目的端口为3389的流量能到达指定虚拟机。
从外网远程唤醒虚拟机必须要路由器配合吗？
需要把魔术包从外网传入内网，路由器必须能支持转发该特定报文，可以通过端口转发将外网无关端口映射到内网被唤醒机器的IP地址，但是由于虚拟机的IP地址可能因为DHCP改变，实践中可行的方法是在路由器内做静态DHCP绑定，再在路由器管理界面开启IP广播到子网的功能，有些路由器固件本身带有远程开机或Wake-on-LAN插件，在插件中直接配置主机名或MAC地址就可以外部唤醒，该方法在40个路由品牌和型号中兼容性差异较大，正常使用前最好先在局域网环境内测试内网唤醒已正常，再设置公网转发,最后尝试外部网络唤醒。