PXE网络引导批量装机实战：原理、部署与排障全解析-代码聚汇网

PXE网络引导批量装机实战：原理、部署与排障全解析

谈国平·2026-10-15·阅读 26 GEO检测（免费）

PXE网络引导批量装机

|难度：普通|阅读约 42 分钟

前阵子甲方拉来几十台裸机服务器，要求两天内全部装好生产系统。我一开始想到的是插U盘一台台装，结果试了两台就放弃了。后面我把PXE网络引导这套老东西重新捡起来，配合自动应答文件，真正做到了“插电、开机、等重启”三步交付。这篇文章就把我从原理到落地排查的完整经验整理出来，包括配置文件和踩过的坑，希望能帮你少走点弯路。

1. 一次搞懂PXE网络引导的核心价值

1.1 什么场景真正需要PXE

PXE（Preboot eXecution Environment，预启动执行环境）是Intel在九十年代末定的一套网络启动标准，它让一台没有系统、没有硬盘数据的裸机，在开机通电的瞬间就能从网络侧取得引导程序和操作系统镜像。二十多年过去，这套协议依旧是批量装机、无盘启动、系统救援领域的基础设施。

需要PXE的场景非常明确：一是大批量标准化装机，比如新采购的服务器、教室电脑、网吧终端、机房节点，一台台插U盘装系统完全不现实；二是一台机器需要反复重装和测试，操作系统的交付要能被“一键重置”；三是无盘工作站场景，终端不装本地硬盘，完全通过网络引导进入工作桌面或计算节点；四是系统修复和救援，宿主机不能启动时，可以通过网络引导进入内存版救援系统去捞数据。日常工作中，最常遇到的是第一种和第二种。

刚接触这个领域的同学容易把它想复杂了，觉得PXE是某种“远程装系统软件”，其实它的定位非常朴素：它只解决“机器在没有任何本地启动介质的情况下，如何把第一个引导程序从网络拉进来”的问题。装完系统之后的正常运行，和PXE没有任何关系。

1.2 和传统U盘/光盘装机相比，优势在哪

传统的U盘装机方式有几个绕不开的痛点：U盘本身是消耗品，量多必有损坏；镜像版本更新一次，所有U盘要重新刷一遍；每台机器的固件设置、磁盘布局可能不同，需要人工逐台干预；更麻烦的是，机器分布在多个楼层或多个机房，运维人员得抱着U盘满场跑。

PXE网络引导把这些问题统一收拢到了服务器端。镜像只维护一份，存放在HTTP/NFS这类网络文件服务上；引导菜单集中在引导服务器上；应答文件可以针对不同机器做精细化配置。最终效果是：只要网线通、电源通、网卡支持PXE启动，机器就能自主完成“找引导、拉镜像、自动应答、分区安装、重启交付”的完整流程，整个环节里人的参与被压缩到只剩“开机”这个动作。

这一点在规模化运维里尤其重要。给一台机器手动装系统，算上U盘制作、固件设置、安装选项，快则二十分钟，慢则一小时；而PXE模式下，几十台机器同时开始安装，安装时长只取决于网络和磁盘速度，人力成本几乎为零。

1.3 学习PXE需要具备哪些前置知识

想把这套东西玩明白，不需要高深编程能力，但有几个基础概念必须清晰。

首先是DHCP的工作机制。PXE依赖DHCP获取网络参数和引导文件位置，你必须理解DHCP Discover/Offer/Request/Ack的交互流程，至少知道DHCP报文里可以携带自定义选项。其次是网络文件传输的基本概念，TFTP和HTTP的区别、端口号、传输特性要清楚。再次是引导加载程序的基本逻辑，传统BIOS下pxelinux.0和UEFI下grubx64.efi各自扮演什么角色，以及它们怎么读取配置文件。

如果你是零基础，建议先在一台虚拟机上搭一套最小环境，把流程跑通，再应用到真实机器。虚拟机能屏蔽很多硬件兼容性干扰，是学习PXE最好的练兵场。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 一条引导链拆到底：PXE的完整工作顺序

2.1 客户机启动：网卡固件是这个流程的“总导演”

PXE的起点其实不在服务端，而在客户端网卡里的PXE ROM芯片。现在的服务器和多数PC终端，网卡固件里都内置了遵循PXE协议栈的代码。当机器上电、BIOS/UEFI固件完成基本硬件初始化后，如果启动顺序里网络启动排在硬盘、光驱之前，或者你手动按快捷键选择网卡启动，网卡固件就开始执行PXE流程。

PXE ROM的功能非常有限。它不像操作系统里的网卡驱动那样可以处理TCP/IP全家桶，它只实现了UDP协议栈，以及DHCP客户端和一个精简的TFTP客户端。换句话说，这台机器此刻的“操作系统”就是那段固件代码，它只认得三件事：发DHCP请求、下载文件、把文件交给固件去执行。

如果你在实机上按了网卡启动，屏幕上一般会看到类似“Intel PXE ROM”或“Realtek PXE”的提示，然后开始“Attempting to boot from network”。从这一刻起，PXE进入了正式的协议交互阶段。

2.2 DHCP与文件获取：PXE如何拿到自己的“地址和节目单”

PXE客户端启动后会先发出一个标准DHCP Discover广播，向网络里寻找DHCP服务器，目的是拿到一个临时IP地址。这里有个非常关键的细节：PXE的DHCP过程其实分两条路走。

一条路是标准DHCP响应。DHCP服务器除了给客户端分配IP地址、子网掩码、网关等常规参数外，还额外携带了两项PXE相关选项：next-server和filename。next-server指定了后续去哪个服务器下载引导文件，一般就是TFTP服务器的IP；filename指定了要下载的引导文件名，比如传统BIOS下的“pxelinux.0”或UEFI下的“grubx64.efi”。

另一条路是proxyDHCP（代理DHCP）模式。当网络里已经有一台标准DHCP服务器在分发地址，你不想动它时，可以单独架一台“代理DHCP”服务，它不负责分配IP，只负责在收到PXE客户端的DHCP请求后，额外应答一个包含next-server和filename的代理报文，告诉PXE客户端“去那个TFTP服务器下载引导文件”。客户端再向标准DHCP获取IP，然后根据代理DHCP提供的信息继续流程。

不管走哪条路，客户端拿到IP和引导文件位置后，下一步就是通过TFTP协议去下载引导文件。TFTP是一种极其简单的UDP文件传输协议，没有加密、没有认证、没有目录遍历，但胜在实现简单，PXE ROM那点资源刚好够用。从这里也能看出PXE早期设计的“小心思”：引导阶段只负责拉一个很小的bootloader文件，真正的重量级数据（内核、镜像、安装源）都留给后续更强大的协议去处理。

2.3 Bootloader与配置文件匹配：从通用菜单到定向启动

当客户端通过TFTP把pxelinux.0或grubx64.efi下载到本地内存后，PXE ROM的任务就算完成了。ROM会把这段引导程序的入口地址交给固件，由固件跳转执行，从此PXE ROM退出舞台。

以传统BIOS下最常用的pxelinux.0（来自syslinux项目）为例，它启动后会按照一套非常讲究的顺序去查找配置文件。它会依次尝试以GUID/UUID、MAC地址、IP地址十六进制形式命名的配置文件，最后才会读取默认配置文件pxelinux.cfg/default。这套匹配机制的价值在于：既能让所有机器共享同一个默认菜单，又能针对某台特定机器做定向引导，比如按MAC地址给指定机器推送不同的安装参数或Linux内核。

如果在PXE服务器上直接执行主配置文件，pxelinux.0默认会去TFTP根目录下的pxelinux.cfg目录里找。这个配置文件的语法和早期Linux的syslinux.cfg几乎一致，核心包含默认启动项、提示时间、菜单定义、内核路径、initrd路径、以及传给内核的append参数。通过追加参数，部署人员可以把Kickstart应答文件、自动安装参数、网络根路径一股脑传给内核，从而让Linux内核在初始化阶段就知道“我该怎么完成后续安装”。

2.4 UEFI与传统BIOS在PXE上的分叉点

很多当年玩透了BIOS下PXE的运维，第一次面对UEFI网络引导时各种碰壁，因为这两者的引导文件体系完全不通用。传统BIOS下PXE客户端下载的是pxelinux.0，这是一个实模式下的引导程序，依赖BIOS中断服务；而UEFI下的PXE客户端下载的是基于UEFI API的EFI可执行文件，典型的是grubx64.efi、shimx64.efi等。固件直接拒绝加载格式不符的引导文件。

如果你的环境同时存在BIOS和UEFI机器，DHCP服务上文件名并不能写死。较稳妥的方式是在同一台PXE服务器上同时放置两套引导文件，再通过DHCP服务器的动态配置区分。例如在ISC DHCP中，可以通过vendor-class-identifier判断客户端的固件类型，把PXEClient映射到pxelinux.0，把EFI-IA32或EFI-x86_64映射到对应的EFI引导文件。

Secure Boot是另一个绕不开的坑。UEFI Secure Boot开启时，固件只允许加载带有效签名的EFI引导程序。简单的做法是用shimx64.efi作为引导文件，shim本身由官方签名，它再去加载GRUB2。很多发行版的PXE文档都明确支持这种部署方式，但如果你是自己交叉编译的EFI文件，可能就得临时禁用Secure Boot，或者做一套完整的签名流程。

3. 工具选型：从“全家桶”到“单独部署”

3.1 轻量化优先：dnsmasq一体化方案

对测试环境、小型实验室、临时机房，我强烈推荐用dnsmasq来做PXE服务。dnsmasq本身是轻量级的DNS和DHCP服务器，内置TFTP服务，一个进程把PXE涉及的最核心三项全部覆盖：DHCP、TFTP、还有可选的代理DHCP。

dnsmasq的配置风格是典型的“一条配置搞定一件事”。下面是一个最小可用的PXE相关片段：

code复制port=0
interface=ens18
dhcp-range=192.168.10.100,192.168.10.200,12h
dhcp-option=3,192.168.10.1
dhcp-option=6,192.168.10.1
dhcp-boot=pxelinux.0,pxeserver,192.168.10.10
enable-tftp
tftp-root=/var/lib/tftpboot

这里dhcp-range负责分配地址，dhcp-boot指定了引导文件名、TFTP服务器主机名和地址，enable-tftp开启内置TFTP服务。dnsmasq有一个特性很容易踩坑：它默认也会把域名解析服务带上，而配置里的port=0是关闭DNS功能的写法，避免和公司现有的DNS解析服务冲突。

不过dnsmasq的短板也很明显：它依然是单点服务，没有内置复杂的策略管理，日志相对简陋，做大规模高并发场景时不如独立服务灵活。我的建议是100台以内的环境随便用，生产核心网络还是拆开部署更稳。

3.2 生产环境经典组合：DHCP + TFTP + HTTP

生产环境我推荐采用经典的分层架构：DHCP服务器负责地址分发和PXE引导参数通告，独立TFTP服务负责引导文件下发，HTTP/NFS服务负责安装镜像和应答文件。每层独立，出问题排查域清晰，扩容也不用动其他层。

DHCP服务可以用ISC DHCP或者Windows Server自带的DHCP角色，只要支持自定义Option 66（next-server）和Option 67（filename）就行。TFTP服务在Linux上常用tftpd-hpa，Windows平台可以用OpenTFTP这类工具，但生产稳定性还是Linux更可靠。HTTP层就用Nginx或Apache，解压系统镜像后直接通过网卡传输，速度远快于TFTP。

这套组合的配置量比dnsmasq大，但每一个环节都可独立维护，也方便接入更强的PXE变种比如iPXE。生产环境里，独立性带来的排障效率提升是非常值得的。

3.3 引导文件体系：pxelinux.0与GRUB2网络引导

传统BIOS时代的标配是syslinux项目中的pxelinux.0，配合menu.c32实现美观的菜单界面。这个组合的优点是对老硬件兼容性好，配置语法直观，社区文档多。UEFI时代则普遍转向GRUB2或systemd-boot的网络引导支持。GRUB2的grub-mknetdir命令可以在TFTP根目录生成一套完整的网络引导目录结构，其中包含了grub.cfg，配置语法和本地GRUB一致。

实际部署中，我倾向于BIOS机器用pxelinux.0，UEFI机器用GRUB2。虽然pxelinux.0也有EFI版本（efi64/efi32），但UEFI的Secure Boot和解耦性决定了GRUB2是更长期的选择。如果网络环境里新老设备并存，我会在DHCP里根据客户端固件类型分别下发不同的引导文件名，把两套体系放在同一个TFTP根目录，互不干扰。

3.4 网络隔离与安全边界

PXE引导设计之初完全没考虑安全，TFTP文件加密、DHCP报文认证都是后来补的。因此部署PXE环境时，一定要把网络边界划清楚：PXE引导服务只放在受控的管理网段/装机VLAN，不要暴露在办公网或核心业务VLAN；引导环境中默认关闭不需要的启动项；生产环境不要直接复用PXE引导服务器作为日常业务服务器。

在物理网络中，如果可能，可以配合交换机的DHCP Snooping功能防止伪造DHCP服务器，网口接入认证（802.1X）可以有效阻止未授权设备接入后擅自发起网络引导。PXE是个功能强大的东西，但也要意识到它同样是把双刃剑——任何物理接入网络的人都能尝试网络引导，如果引导源暴露在不可信网段，风险不小。

4. 手把手部署一套PXE批量装机环境

4.1 环境规划和目录结构

下面以一套典型的Linux环境为例来完整演示。部署机的角色规划如下：PXE引导服务器IP为192.168.10.10，兼作DHCP、TFTP、HTTP三种服务；待装机目标机器位于同网段192.168.10.0/24；目标系统以CentOS Stream 9为例，你换成Rocky Linux、AlmaLinux、Ubuntu live镜像逻辑一致。

先规划TFTP根目录结构。pxelinux.0和menu.c32等文件放根目录，pxelinux.cfg目录放主菜单，images目录放各操作系统的内核和initrd。HTTP根目录存放解压后的安装树和Kickstart应答文件。

code复制/var/lib/tftpboot/
├── pxelinux.0
├── menu.c32
├── pxelinux.cfg/
│   └── default
└── images/
    └── centos9/
        ├── vmlinuz
        └── initrd.img
/var/www/html/
├── pxe/
│   ├── centos9/        # 系统安装树
│   └── ks/
│       └── centos9.ks # 应答文件

实际把镜像文件拷贝到对应目录并不难，但要确保目录权限让TFTP进程和HTTP进程能读取。很多新人搞了半天引导失败，最后发现只是TFTP目录里文件权限是600，子进程读不了。

4.2 DHPC/PXE服务配置

这里我演示用dnsmasq来实现一体化方案，并在注释里说明生产环境的差异。装好dnsmasq后，编辑/etc/dnsmasq.conf，核心配置如下：

code复制# 关闭DNS功能，避免干扰
port=0
# 指定监听网卡，避免把PXE服务暴露到别的网段
interface=ens18
# 地址池
dhcp-range=192.168.10.100,192.168.10.200,12h
# 网关和DNS
dhcp-option=3,192.168.10.1
dhcp-option=6,192.168.10.1
# 引导参数：文件名、服务器名、服务器地址
dhcp-boot=pxelinux.0,pxeserver,192.168.10.10
# 内置TFTP
enable-tftp
tftp-root=/var/lib/tftpboot
# 提高TFTP传输块大小，默认512字节太慢
dhcp-option=option:tftp-server,192.168.10.10

如果你的生产环境用的是独立ISC DHCP服务器，需要在subnet声明里加入next-server和filename：

code复制subnet 192.168.10.0 netmask 255.255.255.0 {
    range 192.168.10.100 192.168.10.200;
    option routers 192.168.10.1;
    option domain-name-servers 192.168.10.1;
    next-server 192.168.10.10;
    filename "pxelinux.0";
}

注意ISC DHCP中filename对UEFI机器可能不友好，需要按客户端vendor-class划分，下文排障部分会细讲。如果只是想学习验证，dnsmasq这部分配置已经够跑通整个流程了。

4.3 TFTP与引导文件放置

装好tftpd-hpa后，编辑/etc/default/tftpd-hpa，至少修改下面两项：

code复制TFTP_DIRECTORY="/var/lib/tftpboot"
TFTP_OPTIONS="--secure --create --blocksize 1468 -v"

--secure限制TFTP只能访问TFTP根目录，--blocksize 1468把默认的块大小从512字节调整到1468字节，能明显提升引导文件的传输速度，前提是网卡PXE ROM支持option negotiation，近十年的设备基本都支持。老设备如果下载卡住，可去掉这个参数再试。

接着从syslinux包中复制引导文件到TFTP根目录。不同发行版路径不同，RHEL系在/usr/share/syslinux/，Debian系在/usr/lib/syslinux/或/usr/lib/PXELINUX/。执行：

code复制cp /usr/share/syslinux/pxelinux.0 /var/lib/tftpboot/
cp /usr/share/syslinux/menu.c32 /var/lib/tftpboot/

如果找不到这些文件，说明syslinux没装全，直接安装对应包即可。menu.c32是图形菜单模块，没有它菜单也照样能显示列表，只是不好看。

4.4 HTTP镜像源与Kickstart自动应答

HTTP服务负责承载安装源。把系统镜像挂载后拷贝到/var/www/html/pxe/centos9/目录，确保目录下有repodata、images、isolinux等子目录，这些是Linux安装器识别安装源的关键。客户端通过HTTP访问到repodata，才能进入软件包选择阶段。

Kickstart应答文件是整个无人值守装机的“遥控器”。它的核心作用是把安装器交互界面里那些“选择语言、配置磁盘、设置root密码、选择软件包”的问题预先填好。下面是一个最小可用的CentOS Stream 9应答文件：

code复制#version=RHEL9
url --url=http://192.168.10.10/pxe/centos9/
lang en_US.UTF-8
keyboard us
rootpw --plaintext YourPassword
authselect --passwheel
network --bootproto=dhcp
zerombr
clearpart --all --initlabel
autopart --type=lvm
selinux --enforcing
firewall --enabled --service=ssh
reboot
%packages
@core
%end

注意rootpw那行里的--plaintext只是演示方便，生产环境务必使用--iscrypted的方式，把加密后的口令串放进去。clearpart和autopart两段是在清空磁盘后自动进行LVM分区，如果不小心会把同磁盘上旧数据全抹掉，千万别在保留数据的机器上测试这段配置。

4.5 PXE菜单设计

主菜单文件是/var/lib/tftpboot/pxelinux.cfg/default。我在这里定义了三个启动项：从本地硬盘启动、安装CentOS Stream 9、进入内存救援系统。其中“本地启动”是我强烈建议保留的，大批量装机时难免误碰网卡启动选项，没有这个兜底会一直卡在PXE菜单前。

code复制default menu.c32
prompt 0
timeout 60
menu title PXE Boot Menu

label local
    menu label 从本地磁盘启动
    localboot 0

label centos9
    menu label 安装 CentOS Stream 9
    kernel images/centos9/vmlinuz
    initrd images/centos9/initrd.img
    append inst.repo=http://192.168.10.10/pxe/centos9/ ks=http://192.168.10.10/pxe/ks/centos9.ks

label rescue
    menu label 内存救援系统 (Rescue)
    kernel images/centos9/vmlinuz
    initrd images/centos9/initrd.img
    append inst.rescue inst.repo=http://192.168.10.10/pxe/centos9/

menu.c32作为默认启动器会让菜单渲染成图形界面。timeout 60代表60秒不操作就执行default指定的项。批量装机时默认项取决于你的真实意图，一般建议默认local避免误装。

4.6 客户端引导实测与验证清单

配置完成后，把待装机机器网络启动顺序调整到第一位，或者开机按快捷启动键选择网卡。正常的PXE启动流程会依次在屏幕上看到：网卡初始化、DHCP获取地址、TFTP下载pxelinux.0、菜单出现、按回车后出现Linux内核启动日志，最后进入Anaconda安装界面。

如果你做的是全自动Kickstart安装，甚至Anaconda界面都只是闪现一下，机器就开始分区、拷贝软件包了。安装完成后主机会重启，PXE启动顺序又处于优先位置，这时务必让默认菜单指向本地启动，否则机器会再次进入PXE流程，陷入“装完又引导安装器”的死循环。

验证清单我习惯这样检查：在DHCP服务器上查看分配给客户端的IP和MAC；在TFTP和HTTP日志里确认请求是否正常；安装完成后进入系统，执行df -h检查分区结果，执行ip addr确认网络配置符合预期。任何一步没通过，往下诊断就是了。

5. 常见问题与排查技巧实录

5.1 开局就失败：DHCP阶段问题速查

PXE最常见的早期失败现象包括：

报错信息	典型原因	处理方法
PXE-E51: No DHCP or proxyDHCP offers were received	客户端没收到DHCP响应	确认网线、DHCP服务、防火墙、地址池剩余量
PXE-E77: Bad or missing discovery server list	未收到代理DHCP提供的引导服务器列表	检查proxyDHCP配置和dnsmasq的dhcp-boot参数
No boot filename received	DHCP分配了IP但没携带filename选项	检查DHCP配置中next-server/filename是否生效
能拿到IP但一直停在“Downloading...”	TFTP服务异常或文件名错误	确认TFTP进程、目录权限、文件名是否和DHCP配置一致

排查DHCP问题最快的手段是抓包看交互过程。在PXE服务器或客户端分别用tcpdump监听67端口和69端口：

code复制tcpdump -i ens18 -n port 67 or port 69 or port 4011

从DORA四步交互里可以直观看到客户端是否拿到了IP、服务端是否返回了DHCP选项、客户端是否发起了TFTP请求。抓包能力是PXE排障的核心技能，强烈建议多试几次，把正常启动和异常启动的差异对比着看，印象非常深刻。

5.2 引导文件下载卡住：TFTP与权限问题

客户端显示已经把pxelinux.0下载完，但执行到一半报“Permission denied”或者干脆卡在某个百分比，多半是TFTP目录权限或SELinux策略出了问题。

第一步检查TFTP目录里所有相关文件是否对TFTP运行用户可读，最简单的方式：

code复制chmod -R 755 /var/lib/tftpboot

RHEL系系统还要检查SELinux对TFTP的放行策略：

code复制setsebool -P tftp_home_dir 1
restorecon -Rv /var/lib/tftpboot

如果你在HTTP目录放镜像之后出现403，也是SELinux标签导致Nginx/Apache无法读取，执行restorecon -Rv /var/www/html通常就解决了。这类问题日志里看不到太多有效报错，全靠对安全策略的敏感度。

5.3 内核启动阶段挂住：initrd、参数问题

PXE引导文件下载成功、内核能加载，但启动过程中黑屏、死循环、或出现“unable to mount root fs”，问题多半落在内核参数或initrd上。重点排查initrd路径是否写错、内核和initrd版本是否匹配、append行里的inst.repo和ks参数URL能否被客户端访问到。

还有一种很微妙的坑：你用HTTP协议加载安装源，但内核启动阶段网络设备名发生了变化。在早期系统安装环境里，网卡名可能是eth0，也可能被Predictable Network Interface命名规则改成ens18，这会导致ks应答文件里的网络配置无法命中正确网卡。遇到这种情况，建议在append参数里加上net.ifnames=0 biosdevname=0关闭可预测命名规则，或者用ip=dhcp这类内核网络参数先保证基础网络就绪。

5.4 UEFI与Secure Boot的坑

UEFI机器连PXE菜单都进不去，最常见原因是DHCP下发的filename还是pxelinux.0。UEFI固件只认EFI格式引导文件，pxelinux.0在传统BIOS下没问题，但在UEFI下固件会直接拒绝执行。解决办法是在DHCP配置中按客户端标识区分文件名。

ISC DHCP中可以使用下面的配置片段：

code复制class "pxeclients" {
    match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
    filename "pxelinux.0";
}
class "efi" {
    match if substring (option vendor-class-identifier, 0, 10) = "EFI x86_64";
    filename "grubx64.efi";
}

如果用dnsmasq，可以在配置里通过dhcp-vendorclass和dhcp-boot搭配实现类似分流。Secure Boot开启的情况下，用发行版签名的shimx64.efi作为入口更省事。

还有一点容易忽略：某些主板UEFI网络启动默认使用IPv4 PXE，但也有些设备默认走IPv6 PXE，而DHCP服务只配置了IPv4，就会一直获取不到地址。进固件设置里确认网络启动协议类型，改成IPv4优先，能省掉不少排查时间。

5.5 传输慢、网络拥塞与批量并发优化

TFTP的默认块大小只有512字节，如果使用默认配置批量拉取vmlinuz和initrd，几十台机器同时启动，引导服务器很快变成瓶颈。优化途径有几个方向：

TFTP层面启用blocksize协商，在tftpd-hpa配置里加入--blocksize 1468，单文件下载耗时有明显改善。
更彻底的方案是使用iPXE作为引导加载器。iPXE是一个功能更强的PXE实现，支持从HTTP下载内核和initrd，速度远快于TFTP。先让PXE ROM通过TFTP下载一个很小iPXE的引导镜像，然后由iPXE接管网络，后续所有大文件都走HTTP。
HTTP服务上开启gzip压缩（对内核和initrd不一定有效），或使用sendfile加速静态文件传输。千万注意压缩只对文本数据有意义，vmlinuz本身已经压过，压缩没收益。

并发装机时HTTP服务默认的连接数限制也可能成为瓶颈。Nginx的worker_connections调大一些，同时文件系统层面留意inode数量，镜像解压出来的小文件数量远比你想象得多。

5.6 容易忽略的细节：默认菜单、MAC绑定与装机死循环

默认菜单是PXE部署里的安全保险。我见过不止一次，批量装机完成后忘了改默认菜单，导致服务器重启后又进入PXE安装流程，把新装好的系统又清掉重装，后果非常严重。所以PXE菜单里永远保留一个label local，并且批量装机主体完成后，把default切换回local。

MAC地址绑定可以实现“按机器发不同应答”。在pxelinux.cfg目录下创建一个以MAC地址命名的文件，文件名格式是01-aa-bb-cc-dd-ee-ff，前导01表示以太网类型，后面是MAC地址小写用连字符分隔。这个文件内的配置会优先于default被读取，适合用机器序列号绑定特定的回答文件、分区方案或内核参数。大规模服务器交付时，我会预先根据硬件清单生成一批这样的文件，每台机器的分区大小、主机名、网络配置各不相同，也能全自动完成。

PXE环境里千万不能放松安全意识。TFTP无认证、HTTP源无加密、Kickstart文件里的root密码明文传输，这些都意味着你的引导服务绝不能暴露在不可信网络。最稳的做法是把PXE服务放在独立管理网段，分开交换机VLAN，配合ACL限制只有特定网段能访问TFTP和HTTP端口。有条件的话，在核心交换机上启用DHCP Snooping，防止有人在局域网里私架DHCP服务器乱发地址。

写在最后

我在实际部署里最喜欢验证的一招是：在主菜单里把timeout设成5秒，默认项设成local，这样开机后不出意外就是普通启动，一旦我手动选择网卡启动又能快速进入PXE。这种“平时隐形、需要时立刻出现”的设计，才是PXE引导在规模化运维里最舒服的姿势。

后续扩展方面，建议有兴趣的朋友往iPXE和自动化平台方向走一走。iPXE可以把HTTP、iSCSI、FCoE这类更现代的存储协议纳入引导链；自动化平台则能把PXE菜单、应答文件、镜像版本全部做成模板化管理，甚至和CMDB打通，实现“新机器接入网络即完成初始化”的效果。这套技术虽然老，但越往后越发现，它才是数据中心交付环节里真正的大动脉。