电脑开机显示“Start PXE over IPv4”，随后停在TFTP超时。此时浏览器能否访问外网几乎没有参考价值：PXE发生在操作系统启动之前，依赖固件、DHCP引导信息以及TFTP或HTTP下载链路。
PXE启动分成哪些阶段
- 网卡固件发出DHCP或网络启动发现请求；
- 客户端获得IP、网关及引导服务器信息；
- 固件下载与自身架构匹配的初始启动程序；
- 启动程序再获取菜单、内核、initrd或安装镜像；
- 安装环境启动后，才进入更常见的HTTP、文件共享或软件仓库阶段。
每个阶段使用的协议可能不同，必须根据屏幕错误和服务端日志定位停在哪一步。
DHCP租约不等于引导信息完整
客户端拿到IP，只证明某个DHCP服务响应。启动服务器、文件名或架构选项可能缺失、被另一台DHCP覆盖，或ProxyDHCP没有返回。保存完整租约与引导选项，比只拍一张IP地址截图更有用。
跨VLAN为什么需要Relay
PXE早期发现依赖本地广播，而广播通常不穿过路由器。企业网络一般在三层设备上配置DHCP Relay或IP Helper，把必要请求转发到指定服务。应精确配置服务器地址与协议，避免把客户端VLAN合并成大广播域。
TFTP为什么容易超时
TFTP使用UDP并建立后续数据交换，不等同于FTP，也不能直接通过HTTP代理。防火墙若只放行最初请求却不跟踪后续会话，客户端会看到超时。NAT、负载均衡与服务器工作目录权限也可能让请求到达但文件无法返回。
UEFI与传统BIOS需要不同文件
x86 BIOS、x64 UEFI和ARM64 UEFI通常不能共用同一个首阶段文件。服务端要依据客户端架构选择正确引导程序。BIOS成功而UEFI失败时，先检查架构选项、文件存在性、大小写和Secure Boot签名，不要直接更换整套镜像。
HTTP Boot与后续HTTP下载
部分UEFI支持HTTP Boot，很多PXE方案也在下载初始程序后改用HTTP获取大文件。HTTP适合传输较大镜像，也便于缓存与日志，但固件是否支持代理、TLS和证书能力差异很大。应以设备固件文档为准，不要假定系统里的代理设置在开机前生效。
文件路径为什么看起来正确仍失败
TFTP根目录、Web根目录和配置中引用的相对路径可能不同。Linux服务区分大小写，Windows制作的配置文件还可能带来路径分隔符或编码问题。从服务进程实际工作目录验证文件，并检查运行账号权限和安全策略。
大镜像不要全压在TFTP上
TFTP设计简单，在高延迟或丢包网络上传输大文件效率较差。常见做法是仅用它获取小型引导程序，后续转到HTTP或其他受支持协议。网络质量诊断可以参考ping、traceroute与MTR的使用边界，但要注意这些工具仍不能代替实际TFTP测试。
安全边界不能省
PXE服务器可能提供操作系统镜像、自动安装脚本和配置秘密。应限制允许启动的VLAN与设备，避免把无人值守凭据写入公开文件，使用短期注册令牌或安装后的身份引导。启动日志中的MAC地址和资产信息也应受控保存。
现场排查顺序
- 记录固件模式、设备架构、VLAN、MAC和准确时间；
- 确认由哪台DHCP或ProxyDHCP响应了哪些选项；
- 核对Relay、引导服务器、启动文件名与架构；
- 在服务端确认请求到达、文件存在且可读；
- 检查TFTP会话、防火墙状态和后续HTTP路径；
- 分别测试BIOS、UEFI与Secure Boot组合，避免混用结论。
结论
PXE启动是DHCP发现、引导文件下载和安装环境获取资源组成的链条。准确定位失败阶段，再核对VLAN Relay、固件架构、TFTP或HTTP路径，比尝试给裸机配置一个网页代理更符合实际。
