服务器pxe一直重启是因为什么

服务器PXE一直重启的核心原因与排查方法

服务器PXE一直重启，绝大多数情况下是PXE引导流程走不通后触发了主板的重启策略，而不是系统或硬件真正崩溃。 简单说，网卡找不到可用的启动映像，引导协议反复超时，于是机器陷入“获取IP→下载引导文件失败→重启→再获取IP”的循环，想要彻底解决，需要从PXE配置、DHCP服务、网络链路和服务器固件四个方向逐一排除。

PXE重启的本质：引导失败后的默认动作

很多人以为PXE重启是硬件问题,其实先想想PXE的工作过程，服务器开机后按PXE协议发送DHCP请求，DHCP服务器返回IP和引导文件位置，然后客户端通过TFTP或HTTP下载引导文件（比如pxelinux.0），再加载内核和initrd，这个过程中任何一个环节超时或拒绝，PXE固件都会报错并跳回启动项列表，而多数服务器的BIOS/UEFI默认“遇到PXE错误后重启”，看起来就成了无限重启。

行业共识认为,PXE重启的关键触发点集中在DHCP分配异常、TFTP/HTTP服务不通、引导文件路径错误、以及网卡PXE ROM与UEFI模式不匹配这四类，后面的排查也按这个顺序来。

排查DHCP：先从地址池和Option 67开始

DHCP服务器没回应或回应错误

PXE启动的第一步是获取IP,如果DHCP服务器没有正确配置PXE相关的Option，客户端就拿不到“下一步去哪个服务器下载什么文件”的指令。

• 检查DHCP地址池剩余量,耗尽会导致租约失败，客户端反复请求。
• 确认DHCP作用域中是否设置了Option 66（TFTP服务器地址）和Option 67（引导文件名）。
• 如果是跨网段部署,还要确保IP Helper或DHCP中继指向了正确的DHCP和TFTP服务器。

实操中经常遇到的现象是：服务器在PXE界面停留几十秒后重启，同时DHCP日志里不断出现“DHCPDISCOVER”但没有后续“DHCPOFFER”，这时直接在客户端所在VLAN的一台机器上抓包看，或者在DHCP服务器上开debug，能看到是否发出了OFFER。

Option 67写错文件名导致死循环

一个常见但隐蔽的错误：Option 67填了“pxelinux.0”，但PXE脚本里的默认引导项又指向了错误的文件名，或者文件名大小写和实际不一致，客户端下载到第一个引导文件后，又去请求第二个文件，第二个文件不存在，PXE返回错误，触发重启。

建议在TFTP服务器上对照tftpboot目录的真实文件名和大小写,逐一核对Option 67和default配置中的路径。

检查TFTP/HTTP服务：寻找重启的直接证据

TFTP根目录权限和防火墙

如果DHCP正常但客户端下载不到文件,PXE固件会显示类似“TFTP open timeout”或“File not found”然后重启，重点检查TFTP服务是否监听正确端口、根目录权限是否可读、SELinux或AppArmor是否拦了服务。

• 在TFTP服务器上执行 tftp <客户端IP> -c get pxelinux.0 测试能否下载。
• 查看TFTP服务日志,观察是否有来自PXE客户端的连接记录。
• 防火墙放行UDP 69端口和后续动态端口（如果使用tftpd-hpa，可能需要固定端口范围）。

引导文件依赖的目录结构不完整

即使pxelinux.0能下载，它还会读取pxelinux.cfg目录下的配置文件，再根据文件内容加载内核vmlinuz和initrd.img，如果目录缺失或文件名不匹配，客户端会在加载内核时静默重启，多数时候日志里只显示一条“Load failed”，很容易被忽略。

建议在配置文件中添加串口输出或VNC日志,让PXE的详细报错显示在屏幕上，而不是一闪而过重启。

UEFI与Legacy模式不匹配是重启的隐形杀手

固件引导模式与引导文件名必须对应

现在的服务器PXE有两种固件类型：传统BIOS（Legacy）和UEFI，这两种模式使用不同的引导文件：Legacy下常用pxelinux.0，UEFI下要用bootx64.efi或grubx64.efi，如果服务器设置为UEFI启动，而DHCP的Option 67返回的是pxelinux.0，客户端会直接拒绝加载，然后重启。

很多运维人员排查服务器pxe一直重启时,第一反应是看网络和DHCP，却忽略了服务器固件本身设置的启动模式，进入BIOS确认Boot Mode是UEFI还是Legacy，再回头改对应文件名。

安全启动（Secure Boot）导致PXE加载失败

新装的多台服务器如果开启了Secure Boot，PXE加载的引导文件没有有效的数字签名，同样会被阻断，系统会认为引导文件不安全，直接重启，此时需要在BIOS里暂时关闭Secure Boot测试，或者改用经过签名的shim引导链。

网络链路和交换机端口配置：容易被忽略的物理层因素

STP与端口协商延迟

当PXE客户端和DHCP/TFTP服务器之间隔着交换机，如果端口启用了生成树协议（STP），在链路刚up时会进入阻塞状态，导致PXE请求发出的前十几秒无人应答，客户端等待超时后重启，等再次重启时链路已正常，但DHCP租约可能又需要重来，这种问题在服务器批量部署时尤其明显。

• 将PXE客户端端口设置为Portfast或Edge端口。
• 确认交换机端口没有开启单端口环路保护导致流量被丢弃。
• 检查双网卡绑定模式,某些绑定策略下PXE只使用主卡，而主卡故障不会自动切换。

网卡PXE ROM版本过旧

部分老服务器的网卡PXE ROM有已知问题，会导致在特定网络环境下重复初始化，更新网卡固件和驱动可以解决，据厂商公开信息，近年来的服务器固件更新日志中，PXE引导稳定性和兼容性修复出现频率较高。

实操：一步步定位重启点

下面是通用排查顺序,按步骤执行可以快速缩小范围：

1. 服务器接显示器,观察PXE引导界面报错码，记下“PXE-EXX”格式的代码，比如PXE-E51表示没有收到DHCP响应，PXE-E78表示无法找到引导文件。
2. 在DHCP服务器上临时把租约时间缩短到1分钟,同时开启日志，观察客户端MAC地址是否正常获取IP。
3. 用同一台服务器接一个独立网口,手工指定IP，然后从本机tftp客户端去拉取引导文件，验证TFTP路径。
4. 进入BIOS,把启动模式改为Legacy（或UEFI），关闭Secure Boot，再试一次。
5. 如果还重启,用另一台已知正常的PXE客户端测试，排除服务器网卡硬件问题。

解决方案：从配置到固件的完整修正

大多数情况下,修复点并不复杂，这里列出最有效的三招。

• 修改DHCP选项：确保Option 66指向TFTP服务器IP，Option 67填写与固件匹配的引导文件名，多子网环境处理IP Helper，使转发广播请求的地址正确。



• 重做引导文件链：使用官方发行版的PXE引导包，不要手工拼接老旧的pxelinux.0和内核，比如Red Hat系用syslinux的pxelinux.0，Debian系用netboot.tar.gz里的引导文件，解压后检查每个软链接是否完好。
• 升级固件：更新BIOS/UEFI和网卡固件到厂商最新稳定版，同时确认BMC/IPMI固件版本，因为部分厂商的BMC会控制系统重启行为，PXE失败后是否重启由管理固件决定。

常见问题：PXE反复重启的典型疑问

为什么PXE启动的服务器在关机状态下还会重启？

服务器配置了Wake-on-LAN或者BMC的“PXE启动失败后自动重启”策略，关机后，BMC仍然带电运行，当收到网络唤醒包或定时任务触发时，会再次尝试PXE启动，可以在BMC设置中关闭“Boot Fail Restart”或“PXE Retry”选项。

如何区分PXE重启和因内核崩溃导致的重启？

PXE重启的屏幕会先显示网卡MAC地址和DHCP请求信息,而内核崩溃会输出一段堆栈或花屏后直接重启，更可靠的方法是串口日志，把服务器COM口接到采集机上，记录重启前的最后一条内核消息，如果串口输出停留在“iPXE”或“UNDI”驱动阶段，就是PXE层面的问题。

服务器pxe装系统一直重启和普通PXE启动区别大吗？

区别在于镜像加载阶段,如果是通过PXE安装操作系统，比如Windows部署或Linux Kickstart，重启点可能出现在加载安装程序、读取ks文件或分区挂载之后，此时优先检查NFS/HTTP镜像路径的权限和防火墙，以及kickstart中日志配置是否正常，多数情况下，安装程序已经跑起来但找不到安装源，就会自动重启回PXE引导，形成二次循环。

最后再强调一遍,遇到服务器PXE一直重启，别先怀疑硬件损坏，按DHCP、TFTP、引导文件、UEFI模式、交换机的顺序排查，每改一项就重启验证一次，只要把PXE启动的完整链路弄通，重启问题基本都会消失，如果你手头正好有台一直重启的机器，现在就去看看它的PXE-E报错代码，那串数字比任何猜测都更接近真相。