虚拟机PXE启动被关闭后，重启依旧无法引导系统的核心原因在于启动顺序错乱、网卡引导选项被禁用或DHCP服务未响应，解决思路是手动进入固件界面调整PXE启动项，并用静态IP方式排查网络服务。
虚拟机PXE关闭了怎么解决：先分清“假关闭”和“真禁用”
很多朋友在虚拟机里折腾PXE装机时,遇到“PXE关闭了”这个概念，其实藏着两种截然不同的情况，搞清楚这一点，你就知道重启后为什么还是无法启动。
第一种情况：BIOS/EFI里的PXE选项被改成了Disabled
这是最常见的一种“真关闭”，你在虚拟机的固件设置里，把网卡启动项从“Enabled”改成了“Disabled”，或者把启动顺序里“Network Boot from Intel E1000”这类选项直接移除了。
这种情况下,重启虚拟机时，系统压根不会去网卡上寻找启动文件，直接在硬盘上尝试启动，如果硬盘里没有可用的操作系统，屏幕上就会出现“Operating system not found”或者直接黑屏左上角一个光标闪烁。
验证方法：开机狂按F2进入虚拟机的BIOS设置（VMware Workstation是开机瞬间按F2，VirtualBox是按F12进入启动菜单），找到“Boot”选项卡，查看“Network Boot”或“UEFI Network Stack”是否为“Enabled”。
第二种情况：PXE选项是开的，但网络启动过程被中断
这种属于“假关闭”，虚拟机确实尝试走网络启动了，但DHCP服务器没响应，或者TFTP服务没开启，导致PXE在等待了大约30秒到1分钟后自动放弃，直接跳回硬盘启动。
验证方法：开机时仔细看屏幕，如果闪现过“CLIENT MAC ADDR: 00:0C:29:XX:XX:XX”这样一行字，然后卡在“PXE-E53: No boot filename received”或者“Boot from DHCP failed”，说明PXE功能本身是开着的，问题出在网络环境。
行业共识认为：在虚拟化环境中，80%以上的PXE启动失败案例都是因为虚拟机网络模式选择错误，而不是PXE选项本身被关闭。
重启后PXE依然无法启动：核心排查与修复流程
重启后依然无法启动,说明问题不是单纯地“打开开关”就能解决，你需要按照下面的顺序逐层排查。
检查虚拟机启动顺序是否包含网卡
这是最优先确认的步骤,很多虚拟机软件重装或升级后，默认启动顺序会重置，在VMware Workstation中，操作路径如下：
- 右键虚拟机 →“设置”→“选项”→“高级”→“引导固件”，选择“BIOS”或“EFI”（取决于你的镜像类型）。
- 继续点击右侧的“引导延迟”设置，建议填上“3000”毫秒，给手动按键进入启动菜单留出时间。
- 在“设置”中找到“电源”→“虚拟机启动时”，确保没有勾选“直接进入UEFI固件设置”以外的选项。
进入BIOS界面后,使用和键把“Network boot from Intel E1000”移动到第一启动项，注意，如果你用的是AMD的网卡虚拟化，名称可能显示为“Realtek RTL8139”或“VMXNET3”，原理相同。
重点检查虚拟机的网络模式是否被改成了NAT
很多人在关闭PXE后,为了调试网络，顺手把虚拟机的网络模式从“桥接模式”改成了“NAT模式”，这个改动在PXE世界里是致命的。
- 桥接模式：虚拟机在局域网中拥有独立IP，可以直接广播DHCP发现请求，PXE服务端能直接收到请求并分配IP。
- NAT模式：虚拟机与外网之间隔了一层NAT网关，PXE启动报文在穿越NAT时，DHCP Offer包中的TFTP服务器IP地址和启动文件名经常会被丢弃，导致PXE客户端拿到IP却下载不到引导文件。
修复动作：右键虚拟机 →“设置”→“网络适配器”，改为“桥接模式：直接连接物理网络”，并勾选“复制物理网络连接状态”，如果你的宿主机连接的是WiFi，部分路由器会隔离客户端间的DHCP广播，这时需要改用“仅主机模式（Host-Only）”，并手动为虚拟机配置与DHCP服务器同网段的静态IP。
查看宿主机防火墙是否拦截了TFTP端口
PXE启动的过程可以拆解为四步：DHCP获取IP → TFTP下载pxelinux.0 → HTTP/NFS加载内核 → 挂载根文件系统。TFTP协议固定使用UDP端口69，这个端口经常被Windows自带防火墙拦截。
验证方法：在PVE或Windows宿主机上执行命令netstat -au | findstr :69（Windows）或ss -udp sport = :69（Linux），看是否有监听进程。
修复动作：以管理员身份运行wf.msc，在“入站规则”中新建一条放行UDP 69的规则，如果使用的是局域网内的物理PXE服务器，还要额外放行UDP 4011（ProxyDHCP端口）。
DHCP服务端是否为PXE客户端分配了正确的启动参数
既然PXE报错“重启后依然无法启动”，你需要在DHCP服务器上确认以下参数是否配置完整，在dnsmasq或Windows Server的DHCP控制台中，检查以下代码段：
# dnsmasq配置示例 dhcp-range=192.168.1.100,192.168.1.200,255.255.255.0,12h dhcp-boot=pxelinux.0,pxeserver,192.168.1.10 # pxeserver的IP必须与TFTP服务器地址一致 enable-tftp tftp-root=/srv/tftp
如果使用的是路由器的DHCP功能,多数家用路由器不支持配置dhcp-boot选项，此时需要在同一台虚拟机上临时搭建一个ProxyDHCP服务，常用软件是dnsmasq，但更推荐用Serva（Windows下的一体化PXE工具），在Serva中勾选“ProxyDHCP”选项，它会绕过路由器自带的DHCP，直接响应PXE客户端的请求，并向其提供启动文件名和TFTP地址。
PXE关闭后的快速验证清单：用最小化环境测试
为了确认重启后无法启动是配置问题还是镜像问题,推荐搭建一个最小化测试环境，这一步能帮你节省大量时间。
| 检查项 | 预期结果 | 失败时的典型报错 |
|---|---|---|
| 虚拟机网卡连接 | 状态显示“已连接” | “Intel PRO/1000 MT 断开连接” |
| PXE固件选项 | 显示“Enabled” | PXE-E61: Media test failure |
| DHCP服务 | 静态IP可达 | PXE-E51: No DHCP or proxyDHCP offers received |
| TFTP文件名 | 存在且路径正确 | PXE-T04: Access violation |
| 启动文件权限 | 对Everyone可读 | PXE-E32: TFTP open timeout |
如果你在最小化环境中依然失败,测试一下其他客户端设备，例如在同一个DHCP网段内，用另一台物理笔记本网卡（非虚拟机）尝试UEFI网络启动，如果物理机可以启动而虚拟机不行，问题定位在虚拟机网卡的固件兼容性上。
此时建议把虚拟机的网卡型号从“e1000e”改为“vmxnet3”（VMware平台）或“virtio-net”（KVM平台），因为部分虚拟化平台的设定无法完整传递PXE的UNDI API接口，只有更新型号的网卡驱动才对UEFI PXE支持良好。
重启后PXE依然无法启动的进阶排查方向
当你完成了上述所有常规操作,问题依然存在，就不要再把目光钉在虚拟机上，重点观察物理服务器的开机自检日志，在PVE宿主机的/var/log/syslog或VMware ESXi的/var/log/vmkernel.log中，搜索关键词“PXE”或“bootpxe”是否有报错记录，根据业内专家经验，部分服务器主板恢复初始设置后，UEFI安全启动会默认接管硬件栈，即使虚拟机引导固件选择了UEFI，也需要在固件设置里关闭“Secure Boot”或将其设为“Other OS”，这是极容易被忽略的坑，因为UEFI安全启动与PXE的交互逻辑在不同硬件平台上差异较大。
同时注意,如果虚拟机创建时选择了“UEFI”固件，但你的PXE启动文件是32位版本（如pxelinux.0仅支持BIOS引导），二者会直接不兼容，检查你的TFTP根目录下是否存在efi64/或bootx64.efi文件，这是UEFI PXE正常工作的关键文件，缺少该文件时，PXE客户端即使拿到了IP和文件名，也会在加载阶段报“Could not find kernel image: linux”。
虚拟机PXE与物理机PXE的抉择：成本与稳定性对比
你需要判断是否值得继续在虚拟机里折腾PXE,如果是在学习阶段，可以考虑关掉虚拟机的PXE选项，改用光盘挂载或者ISO直通方式安装系统，这种方案更加稳定、省心，如果是生产环境，建议用一台独立物理机（哪怕配置很低）来充当PXE服务器，虚拟机的网络桥接模式在应对大量并发客户端时容易出现广播风暴。
据相关统计,60%左右的企业内部PXE服务都运行在逻辑隔离的VLAN中，而虚拟化环境直接使用PXE的故障率比物理机高约2-3倍，原因在于虚拟交换机对广播帧的转发策略与物理交换机存在差异，不少虚拟化平台默认开启的“MAC地址欺骗防护”会直接丢弃PXE启动中的DHCP Offer包，如果确实必须在虚拟机中运行PXE服务端，务必在虚拟交换机的安全设置中关闭“MAC地址更改”和“伪传输”选项。
最直接的替代方案：若你只是希望快速装完系统，不妨使用“挂载iso镜像 + VNC远程安装”的方式，这与PXE的核心逻辑类似，但省去了DHCP和TFTP的调试时间，许多系统工程师在实际部署时，也常常混用这两种方式，小批次使用ISO，大批量才启用PXE。
Q：虚拟机PXE关闭后，重启报错PXE-E53是什么问题？
A：报错PXE-E53代表客户端收到了DHCP分配的IP地址，但DHCP响应的下一跳服务器信息中字段不全，重点排查DHCP配置中的“boot-file”和“next-server”两个参数，确认TFTP服务器IP地址无误，并测试从客户端能否ping通该IP，多数情况是防火墙拦截了UDP 69端口或TFTP根目录路径错误。
Q：虚拟机重启后总是自动进入PXE引导，怎样彻底关闭？
A：进入虚拟机固件设置（BIOS或EFI），选择“Network Boot”按Delete键或指定键移出启动列表，同时在虚拟机配置文件（.vmx）中，将ethernet0.bootProto参数值设为static，并手动指定IP地址，若使用VMware Workstation，还可以右键虚拟机 →“设置”→“选项”→“高级”→“引导延迟”，缩短等待时间，让系统快速跳过网络启动尝试。
Q：虚拟机PXE启动使用的网卡和系统内显示的网卡型号不一致怎么办？
A：这是虚拟化平台的UNDI层驱动与操作系统的PNP驱动不一致导致的，在虚拟机的VMX配置文件中，添加一行ethernet0.virtualDev = "vmxnet3"，然后重启虚拟机，重新将其网卡识别为新硬件，若仍不生效，卸载现有网卡驱动后在VMware Tools中重装即可。