企业官网建设流程全解析

机房搬迁那阵子，二十几台没有光驱的工控机堆在货架上，U 盘插上又拔下，一轮系统装下来两个小时就没了，中间还遇到 U 盘被识别成只读、install.wim 超过 4GB 放不进 FAT32 分区的破事。后来我把一台闲置的小主机改成引导服务器，用 Windows 系统部署 Serva PXE 网络引导安装操作系统，客户端开机按个 F12 就能进安装界面，十几台机器可以并行走，效率直接翻了好几倍。这套方案的核心就是 PXE（Preboot Execution Environment）网络引导，配合 Serva 这个在 Windows 上跑的一体化服务程序，把 DHCP、TFTP、HTTP、BINL 都塞进一个进程里，不用装 WDS 角色、不用加域、不用折腾 Linux 上的 dnsmasq 和 tftp-hpa。如果你手上有一批机器要批量装 Windows，或者单纯想搞明白网络引导背后的门道，又或者是做运维、装机、教学实验的同行，这篇内容应该能帮你少走几天弯路。

1. 先说清楚：PXE 网络引导到底解决了什么问题

1.1 从机房里的真实痛点说起

批量部署操作系统这件事，最传统的方式是一个一个插 U 盘，改 BIOS 的启动顺序，进安装界面点下一步，等半个小时，再换下一台。这种模式在机器数量少于五台的时候完全可以接受，一旦上了两位数，时间成本和人力成本就开始失控。更麻烦的是变数太多：有的机器 USB 接口供电不足导致安装中途掉盘，有的老主板认不出 USB 3.0 的启动盘只能插到 2.0 口上，还有的机器干脆被锁了 BIOS 密码，你连启动项都改不了。我遇到过最离谱的一台工控机，进 BIOS 之后是按 F10 保存而不是 F10 是启动菜单，找了半天才反应过来。

PXE 网络引导的出发点很朴素：既然每台机器都有网卡，而网卡在出厂时就固化了一段引导 ROM（或者主板集成的 PXE 代码），那干脆让网卡自己去网络上找启动文件。机器开机后不走本地硬盘、不走光驱、不走 U 盘，而是发一个广播包出去问"谁有启动镜像给我一份"，网络上负责应答的那台服务器把引导程序和系统镜像喂给它，客户端就在内存里跑起一个 WinPE 环境，接下来的安装流程和本地装系统几乎一模一样。

这套机制最大的价值在于"去介质化"。你不需要给每台机器准备 U 盘或者光盘，所有镜像集中放在服务器上，更新一次全网生效。对于经常需要重装、恢复、刷机位的场景，省下的时间非常可观。它的短板也很明确：必须在同一个二层网络里，或者网络设备上做好跨网段的转发配置；服务器的服务一旦挂掉，所有客户端都装不了。

1.2 一套 PXE 环境里，DHCP、TFTP、HTTP 各自干什么活

很多人第一次接触 PXE 的时候会被一堆名词绕晕，其实拆开看，这就是几个各司其职的服务在配合。

DHCP 负责"指路"。客户端开机后广播一个 DHCP Discover 包，除了正常的 IP 地址、网关、DNS 之外，它还会额外请求两个关键信息：一个是"引导服务器的地址"（Option 66，通常叫 Next Server），另一个是"引导文件的名字"（Option 67，Bootfile Name）。只要这两个选项给对了，客户端就知道该去找谁、该下载哪个文件。如果网络里已经有一台现成的 DHCP 服务器，你不想动它，那就用 ProxyDHCP 模式，让 Serva 只回应 PXE 相关的部分，IP 地址还是由原 DHCP 发放。

TFTP 负责"搬小件"。客户端的网卡 ROM 本身功能极其简陋，它能理解的协议只有 TFTP 这一种，所以最初加载的那一小段引导程序（几十 KB 到一两 MB）必须用 TFTP 传输。TFTP 基于 UDP，没有复杂的握手和流控，实现简单但速度慢、丢包不重传，指望它传几百兆的 boot.wim 基本是自虐。

HTTP 负责"搬大件"。Serva 的高明之处就在这儿：TFTP 阶段只送一个很小的引导器（比如 iPXE 或者 wimboot），这个引导器接管之后，会通过 HTTP 去下载几 GB 的 install.wim 和几百兆的 boot.wim。HTTP 跑在 TCP 上，有拥塞控制、有重传机制，在千兆内网里跑到 900Mbps 以上毫无压力。同样的镜像，TFTP 可能要传二十分钟，HTTP 两三分钟就完事。

注意：DHCP 的 67/68 端口、TFTP 的 69 端口、BINL 的 4011 端口、HTTP 的 80 端口，这几个是 PXE 链条上的关键节点，任何一个被防火墙拦掉或者被其他程序占用，客户端都会卡在某个环节上不动。

1.3 为什么我用 Serva 而不是微软自带的 WDS

Windows Server 上确实自带 WDS（Windows Deployment Services）角色，功能更"正规"，支持组播、支持驱动注入、支持和企业域集成。但它的门槛也摆在那儿：必须是 Server 版本的系统，必须装角色，必须配置 AD DS 或者至少是一台域控，部署完还要处理权限委派。对于一个只有十几台机器的小机房来说，为了装个系统专门搭一套域环境，纯属杀鸡用牛刀。

Serva 的定位就非常务实：一个绿色小工具，解压就能跑，在 Windows 10、Windows 11、Windows Server 各个版本上都能用，甚至有人直接把它跑在客户端的笔记本上临时当服务器。它把 DHCP、TFTP、HTTP、BINL 全部内置，你只需要在图形界面里点几下、改一个 ini 文件，服务就起来了。它还自带对单实例多 ISO 的支持，把不同的 Windows 镜像丢到指定目录里，PXE 启动菜单会自动列出每一条，客户端按方向键选就行。

代价是社区版有一些限制，比如启动菜单上会有一小段等待时间，商业生产环境中需要留意授权条款。但对实验室、小团队、个人折腾来说，它是我目前见到的性价比最高的选择。相比之下，如果你追求极致的可控性，Linux 下用 dnsmasq 加 nginx 的组合也很优雅，只是配置全在命令行里，对不熟悉 Linux 的同行不太友好。

2. 部署前的环境准备：硬件、网络与镜像

2.1 服务器端该用什么机器和什么系统

服务器端的要求其实低得超出很多人想象。我目前用的是一台退役的迷你主机，四核低压处理器、8GB 内存、128GB 固态，跑 Windows 10 专业版，常年挂着 Serva 服务，同时给五到八台客户端供镜像，CPU 占用长期在 5% 以下。真正的瓶颈在网络带宽和磁盘读取速度上，不在算力上。

系统版本的选择上，我建议用 Windows 10 专业版或者 Windows Server 2016 之后的版本，原因有两个。一是驱动兼容性好，尤其是网卡驱动，Serva 需要独占绑定一块物理网卡来接管 DHCP 和 TFTP，如果网卡驱动不稳定，服务起来之后会莫名其妙断掉。二是这些系统对防火墙规则的粒度控制比较细，方便你精确地只放行需要的端口，而不是简单粗暴地整体关闭防护。

服务器至少要有两块网卡，或者一块网卡但要支持 VLAN。理想的做法是一块网卡接办公网络，用于你自己远程管理；另一块网卡专门接一台交换机，所有待装机器的客户端都接在这台交换机上。这样 PXE 广播被限制在独立的小网络里，不会污染公司的主网络，也不用担心和现有的 DHCP 服务器打架。如果实在只有一块网卡，那就得用 ProxyDHCP 模式，让 Serva 只补充引导信息，不发放 IP 地址。

内存方面，8GB 是舒适线，4GB 也能跑。硬盘上，镜像本身是占空间的大头，一个 Windows 11 的 ISO 大概 5 到 6GB，展开之后还要更多，所以建议留出至少 200GB 的可用空间。如果你的机器上有 NVMe 固态，把镜像目录放上去，客户端拉镜像的速度会明显更稳。

2.2 IP 规划与参数计算，别等冲突了才后悔

网络参数这块，我见过太多人栽跟头，所以单独拿出来讲。假设我们采用完全独立的方案，也就是 Serva 所在机器同时充当 DHCP 服务器和引导服务器，那么首先要给它自己配一个静态 IP。

举一个我常用的规划例子：服务器网卡地址设为 192.168.100.1，子网掩码 255.255.255.0，也就是 /24 的网段，可用地址范围是 192.168.100.1 到 192.168.100.254，一共 254 个可用主机地址。把服务器自己占掉 192.168.100.1，剩下的地址池可以划给客户端。为了留出管理余量，我一般把动态分配范围设成 192.168.100.100 到 192.168.100.200，一共 101 个地址，足够应付绝大多数场景。

为什么要留出 192.168.100.2 到 192.168.100.99 这一段？因为你可能还要在这台服务器上跑别的东西，比如文件共享、远程桌面、监控面板，或者未来会加一台交换机做管理。地址留宽一点，后面加设备的时候不用重新规划。

网关和 DNS 的填法有个小细节：如果这个网络是纯内网、不上外网，网关可以直接填服务器自己的地址，DNS 也填服务器地址，客户端能解析到本地就行。但如果安装过程中需要联网下载东西（比如某些驱动的在线安装、或者 Windows 更新），那就得把网关指向真正能出去的路由器，DNS 填可用的公共解析服务。这里要注意，Windows 安装过程中对网络的依赖其实很轻，纯离线装也能完成，所以别为了联网把网络结构搞复杂。

子网掩码的计算方式这里顺带说一下，255.255.255.0 对应 24 位网络位，剩 8 位主机位，2 的 8 次方是 256，减去网络地址和广播地址两个，就是 254 个可用地址。如果你要装机的客户端超过 250 台，就得改成 255.255.254.0（/23），可用地址会扩展到 510 个左右。这个换算在规划网络的时候一定要提前算清楚，中途改网段是最麻烦的。

2.3 镜像文件和目录结构的准备工作

Serva 对目录结构是有约定的，搞错了它就找不到镜像。安装完之后，程序目录下会出现几个关键文件夹，其中和我们要用的最相关的是 WIA_WDS 这个目录，全称是 Windows Installation Automation / Windows Deployment Services 的意思。你只要把从官方渠道下载下来的 Windows ISO 原封不动地丢进去，Serva 在启动服务的时候会扫描这个目录，自动解析 ISO 里的 sources\boot.wim 和 sources\install.wim，然后把它注册成 PXE 菜单里的一项。

这里有几个必须注意的细节。第一，ISO 文件不要改名字，也不要带空格和中文路径，很多解析异常的锅其实是路径里有个中文字符导致的。第二，镜像的完整性要校验，下载完之后对一下 SHA256，一个字节坏掉就可能导致客户端启动到一半蓝屏。第三，Windows 11 的 install.wim 普遍在 4GB 以上，这个是正常的，Serva 走 HTTP 传输不受 FAT32 单文件 4GB 的限制，这也正是它比 U 盘方案省心的地方。

如果你还想做网络引导下的 PE 工具箱，比如分区、备份、密码重置这类活儿，可以在 NWA_PXE 目录里放自定义的 WinPE 镜像，Serva 同样会识别并加进菜单。我自己习惯放一个精简版的维护 PE，装系统之前先跑一遍磁盘检测，有问题当场就发现了，不用装到一半才发现硬盘有坏道。

还有一点值得提前考虑：镜像数量多的时候，PXE 菜单会长得需要滚动。Serva 支持给每个镜像配一个说明文字，我一般会在文件名后面加个前缀，比如"WIN11-23H2"、"WIN10-LTSC"、"SERVER2022"，这样在客户端的字符菜单里一眼就能分清。别小看这个习惯，客户端的 PXE 字符界面显示区域很窄，名字太长会被截断，反而看不出是哪个版本。

3. Serva 安装与服务配置实操

3.1 首次运行与服务模式选择

Serva 的部署过程简单到有点不真实。从官网下载压缩包，解压到一个没有中文和空格的路径下，比如 C:\Serva，然后右键以管理员身份运行 serva.exe。第一次启动它会做一些初始化，把默认的目录结构和服务配置生成出来。这里一定要用管理员权限，否则它没法绑定 67 和 69 这两个低位端口，服务启动会直接失败。

启动之后进入主界面，你会看到一个菜单栏和几个功能区块。核心操作集中在 Settings 这一项里，点开会看到一个服务开关列表。默认情况下这些服务是没全开的，你需要手动勾选。我一般的顺序是先配置参数，再启动服务，避免带着错误配置启动之后反复重启。

Serva 支持三种工作模式，这个必须在动手之前想清楚。第一种是 Standalone 模式，也就是它自己当 DHCP 服务器，负责发 IP 也负责发引导信息，适合完全独立的小网络。第二种是 ProxyDHCP 模式，网络里已经有 DHCP 服务器在正常发地址了，Serva 只补充 Option 66 和 67 这两个 PXE 相关的选项，适合接入现有办公网络的场景。第三种是不接管 DHCP，只在客户端已经拿到地址之后提供 TFTP 和 HTTP 服务，这种一般是配合手工指定引导服务器使用。

选错模式的典型症状是：客户端能拿到 IP 但一直提示找不到引导文件，或者反过来，客户端拿不到 IP，网络直接瘫痪。所以动手之前先确认一件事，你的网络里到底有没有别的 DHCP 服务器在跑。

注意：如果在同一个二层网络里同时存在两台 DHCP 服务器，客户端的 IP 获取会变得极其随机，一会儿拿到这个服务器发的地址，一会儿拿到那个的。这不仅影响装机，还可能影响到办公网络里其他正常设备。所以在不确定的环境里，优先选 ProxyDHCP 模式。

3.2 Serva.ini 关键参数逐条拆解

图形界面上能改的东西有限，真正决定行为的参数都在安装目录下的 serva.ini 文件里。不同版本的字段名和分组会有细微差异，所以我这里讲的是结构和含义，具体字段以你下载到的版本里自带的注释为准，那一行行注释其实就是最好的文档。

配置文件一般分成几个区块，和 DHCP 相关的参数在一个区块里。IPADDRESS 填服务器自己那块网卡的地址，SUBNETMASK 填掩码，ROUTER 填网关，DNS 填解析服务器地址。这几个值必须和你网卡上实际配置的一致，写错了会直接导致服务启动报错。

然后是地址池相关的参数，通常是起始地址和结束地址，或者用地址范围加一个长度来表示。这块要和前面规划的动态地址池对得上。有些版本还支持给特定 MAC 地址固定分配 IP，做批量装机的时候很有用，因为你可以根据 MAC 预判客户端会拿到什么地址，出问题的时候查日志方便定位。

服务端口相关的参数里，HTTP 端口默认是 80，TFTP 是 69，BINL 是 4011。如果你的服务器上装了 IIS 或者有其他程序占用了 80，要么把那个程序停掉，要么在配置里把 HTTP 端口改掉。我个人的建议是尽量保持 80 不动，因为有些客户端的引导器对非标准端口的支持参差不齐，改端口虽然能绕开冲突，但可能引入新的玄学问题。

还有一个容易被忽略的参数是引导文件的名字。在 Legacy BIOS 模式下，这个文件名通常是引导程序的名字，比如 ipxe.pxe 或者 wimboot 之类；在 UEFI 模式下则是 bootx64.efi。Serva 一般会根据客户端的架构自动适配，你不需要手动区分，但如果你在日志里看到它一直在请求某个文件却 404，那就是这个参数配错了。

; 以下为配置结构示意，字段名请以实际版本为准 [DHCP] IPADDRESS=192.168.100.1 SUBNETMASK=255.255.255.0 ROUTER=192.168.100.1 DNS=223.5.5.5 POOLSTART=192.168.100.100 POOLEND=192.168.100.200 [SERVER] HTTPPORT=80 TFTPPORT=69

改完 ini 之后必须重启服务才生效，而且有时候需要把 Serva 整个退出再启动，光点重启按钮不一定能重新加载配置。这个坑我踩过好几次，改完参数发现没反应，折腾半天才发现是进程没真正重启。

3.3 服务自检：端口、防火墙与日志

服务启动之前，先在服务器本机确认一下端口占用情况。打开命令提示符，跑一行 netstat -ano | findstr :80，看看 80 端口有没有被别的进程占着。同样的方法查一下 69 和 4011。如果发现被占用，记下那个进程号，回头在任务管理器里查是谁。

防火墙方面，Windows 默认会在检测到网络位置变化的时候弹窗询问是否允许程序通信。第一次运行 Serva 的时候一定要点允许，而且要注意，如果你事后切换了网络类型（比如从公用网络改成专用网络），这条规则可能会失效，需要重新放行。稳妥的做法是手工在防火墙的高级设置里给 serva.exe 建一条入站规则，把所有需要的端口一次性放行，免得后面反复排查。

服务起来之后，第一件事是看日志。Serva 的日志窗口会实时滚动显示客户端的请求，包括 DHCP 请求、TFTP 传输、HTTP 下载。如果你看到 DHCP 那一行有正常的 Offer 和 Ack，说明地址分配没问题；如果看到 TFTP 那一行开始传输但速度极慢，说明网络链路可能有问题；如果看到 HTTP 请求返回 404，说明镜像路径或者文件名不对。日志是排查问题最直接的入口，比任何猜测都靠谱。

本机自检可以做一个小实验：在同一台机器上再开一个命令提示符，用 tftp 命令（Windows 自带，需要在功能里启用）去拉一个引导文件试试，能拉下来就说明 TFTP 服务本身是通的。HTTP 服务更简单，直接在浏览器里访问服务器地址，能看到目录列表就说明服务正常。这两个都通了，再上真机测试，效率会高很多。

4. 客户端引导与系统安装全流程

4.1 Legacy BIOS 与 UEFI 两条引导路径的区别

这是整个方案里最容易出问题的环节，必须重点说。现在的机器分两类固件：一类是传统的 Legacy BIOS，另一类是新的 UEFI。两者的 PXE 引导行为差别很大，混在一起会导致客户端卡在某个阶段。

Legacy BIOS 的 PXE 流程比较老派。网卡 ROM 通过 DHCP 拿到引导服务器地址和文件名之后，用 TFTP 把那个文件拉下来执行。这个文件通常是一个 iPXE 或者类似的小引导器，它负责后续通过 HTTP 下载 WinPE 镜像。整条链路对服务器端的兼容性要求不高，怪毛病也少。

UEFI 的 PXE 流程基于 EFI 规范，客户端请求的引导文件名是不同的，x64 架构下通常是 bootx64.efi，32 位是 bootia32.efi。而且 UEFI 客户端在 DHCP 请求里会带上一个叫 Client Architecture 的选项（Option 93），值不同代表不同架构，服务器要能识别并返回对应的引导文件。Serva 对这套机制是内置支持的，正常情况下会自动判断，但如果客户端固件实现不规范，就可能出现请求了错误的文件类型然后失败的情况。

还有一个绕不开的话题是 Secure Boot（安全启动）。开启状态下，UEFI 只允许加载有签名的引导程序，一些非签名的引导器会被直接拒绝执行。解决办法有两个：一是在 BIOS 里关闭 Secure Boot，二是使用已经过签名的引导文件。在做内网装机的时候，我通常选择前者，装完之后再根据需要决定是否重新打开。

4.2 在客户端上触发 PXE 启动

客户端这一侧的操作其实很标准。开机之后按对应的按键进 BIOS 设置，把网络启动加到启动顺序的最前面，或者直接按快捷键调出一次性启动菜单。不同品牌的快捷键五花八门，戴尔一般是 F12，惠普是 F9 或者 Esc，联想是 F12 或者 Fn+F12，华硕是 Esc 或者 F8，微星是 F11，技嘉是 F12。工控机就更乱了，很多是 Del 进 BIOS 之后再手动挑。

有一个特别实用的小技巧：如果机器数量多，你不想一台一台改 BIOS，可以在服务器上观察客户端的 DHCP 请求来确认它们的 MAC 地址和架构信息。只要客户端开机时网卡是启用的，即使不从网络启动，也会发出 DHCP 请求。通过日志你就能提前知道有哪些机器在线、它们是什么架构，做到心里有数。

客户端成功进入 PXE 之后，你会先看到一个很简陋的字符界面，通常是引导器的 logo 加上一行提示，然后跳转到 Serva 生成的镜像选择菜单。菜单里会列出所有可用的镜像条目，用上下方向键选择，回车确认。选中之后就是漫长的等待，具体时长取决于镜像大小和网络速度，千兆网络下单台机拉一个 5GB 的镜像大概两三分钟。

这里有个细节值得提醒：同一时间太多客户端一起拉镜像，会互相抢带宽。我测过，千兆交换机上同时跑四到五台是舒服的，超过八台就会明显变慢，二十台以上基本就卡成幻灯片了。所以批量装机的时候，最好分批上，比如每批五台，装完再换下一批。如果你的服务器是万兆网卡、交换机也是万兆的，那可以放宽这个限制。

4.3 进入 WinPE 后的分区与安装操作

镜像下载完成之后，客户端会在内存里启动一个 WinPE 环境，界面上出现的就是我们熟悉的 Windows 安装向导。到这一步，操作逻辑和用 U 盘装系统几乎没有区别，选择语言、键盘布局、点击"现在安装"、接受许可条款，然后进入分区界面。

分区这一步是很多新手卡住的地方，我说几个实操要点。如果你要给系统盘做干净安装，先把磁盘上已有的所有分区全部删除，直到只剩一块未分配空间。然后直接选中这块未分配空间点下一步，安装程序会自动创建必要的 EFI 分区、MSR 保留分区和主分区。不要手动去创建一堆分区，Windows 安装程序的处理方式比手工分更规范，尤其是 UEFI 模式下，手工分区很容易漏掉 EFI 分区或者把它格式化成了错误的文件系统。

如果你需要的是一个自定义的分区方案，比如系统盘 200GB、数据盘单独分开，那就先手动新建并格式化这几个分区，注意系统盘所在的磁盘必须是 GPT 分区表（UEFI 模式）或者 MBR（Legacy 模式），这个和你客户端的引导方式必须对应。分区表不匹配的典型症状是安装程序报错说无法安装到这个磁盘，或者装完之后启动不了。

安装过程本身没什么可操作的，就是等。中途机器会重启几次，这时候要注意，一定要在第一次重启之前把启动顺序改回硬盘，或者在服务器上把对应客户端的引导停掉，否则它可能又从网络启动，进到 PE 里循环了。这个坑很多人踩过，看着屏幕上又出现了镜像选择菜单，一脸茫然。

提示：Windows 11 的安装流程里有一段强制联网和强制登录微软账户的环节。如果你做的是离线批量部署，可以在安装界面按 Shift+F10 调出命令行，执行 oobe\bypassnro 这个脚本，机器重启后就会出现跳过联网的选项。这是微软官方脚本，在内网无外网的场景下用得很普遍。

4.4 多镜像菜单与无人值守应答文件

手动点下一步的方式在数量少的时候没问题，一旦要装几十台，每台都点一遍选择语言、分区、设账户，累加起来是巨大的浪费。这就是应答文件的用武之地。

Windows 安装程序支持一个叫 autounattend.xml 的应答文件，放在安装介质的根目录或者指定位置，安装程序启动时会自动读取，把你预先写好的设置全部填进去。分区方案、产品密钥、时区、计算机名规则、管理员账户、首次登录后的脚本，这些都能写进去。写完之后，客户端从 PE 启动到系统准备就绪，全程无人干预，你只需要在最后检查一下结果。

在 Serva 的环境里，把 autounattend.xml 放到对应镜像的目录下，让它和 ISO 的处理流程配合起来。Serva 在解析镜像的时候会把某些目录暴露出去，你可以参考它的目录结构把应答文件放到正确的位置。如果发现安装过程没有读取你的文件，先检查文件名拼写，必须是 autounattend.xml 全小写，一个字母都不能错，这是微软的硬性规定。

计算机名这块有个实用做法，用规则自动生成而不是写死，否则所有机器装完之后名字都一样，加网络之后会冲突。常见的做法是在应答文件里用通配符加随机数，或者干脆在首次启动脚本里读取机器序列号来命名。我自己的习惯是装机前先记录好每台机器的位置，装完之后统一用脚本批量改名，这样名字和物理位置能对应起来，后续维护省心。

菜单的整理也很重要。当你的 WIA_WDS 目录里堆了七八个 ISO 的时候，PXE 菜单会长得让人抓狂。我的做法是只保留当前批次要用的镜像，其他的移到别的目录暂存，用完再换回来。Serva 扫描目录是实时或者定时扫描的，移走之后重启服务菜单里就干净了。

5. 踩过的坑与故障速查

5.1 常见报错速查表

网络引导的报错信息都很短，但每一条背后对应的原因差别很大。我把这些年遇到的、加上同行群里高频出现的报错整理成下面这张表，遇到问题先对号入座。

这张表里的每一条我都实际遇到过，其中最容易误判的是"EFI PXE boot failed"这一条。很多人第一反应是镜像坏了，反复替换 ISO，其实问题出在 Secure Boot 或者引导文件名上。排查顺序建议是先用一台确定支持 Legacy 模式的老机器测试，如果老机器能进，新机器不行，那基本就是 UEFI 相关的问题，方向就明确了。

5.2 跨网段部署与 DHCP 冲突的处理

前面一直强调要在同一个二层网络里，但实际工作中经常遇到机房分布在不同楼层、跨了三层交换机的情况。这时候 PXE 广播是过不去的，需要在网络设备上做转发配置。

标准的做法是在客户端所在的网段对应的网关设备上配置 DHCP 中继，把 PXE 相关的请求转发到引导服务器所在的位置。关键是要把 Option 66 和 Option 67 一起带过去，有些设备的默认中继配置只转发基础 DHCP 信息，不带扩展选项，结果客户端拿到地址但拿不到引导文件名，卡在 PXE-E53。

另一个高频问题是和现有 DHCP 的冲突。我见过最典型的场景是：运维同事按照教程把 Serva 配成了 Standalone 模式，结果整个办公网的新接入设备开始随机掉线，因为地址池冲突了。所以在接入现有网络之前，务必确认清楚：如果网络里已有 DHCP，就老老实实用 ProxyDHCP 模式，只补充 PXE 信息。判断方法很简单，找一台普通电脑连到那个网络，看它拿到的 IP 是不是由原来那台设备发的。

还有一个小概率但很烦人的情况：网络里存在多台无线路由器，它们的 DHCP 功能没关，都开着默认的 192.168.1.1 网段。这时候客户端发出的请求会被多台设备应答，行为完全不可预测。遇到这种环境，最省事的做法是物理隔离，把待装机器的交换机单独拉出来，不接到办公网络上。

5.3 性能优化与几条实操心得

性能这块，瓶颈永远在磁盘读取和网络带宽上，不在 Serva 本身。我做过一个对比测试，同样的 Windows 10 镜像，放在机械硬盘上单台客户端的下载速度大概在 200Mbps 上下波动，换成 NVMe 固态之后稳定跑到 850Mbps 以上。所以如果条件允许，把镜像目录放到固态盘上，这是性价比最高的优化。

第二个优化点是网络。用六类网线，确认交换机端口协商速度是千兆而不是百兆。我遇到过一次特别隐蔽的问题，客户端下载速度一直在 100Mbps 左右，换了网线也没用，最后发现是交换机上那个端口的自动协商出了岔子，手动固定成千兆全双工之后就正常了。这种问题用眼睛看不出来，只能靠测速来判断。

第三点关于日志和记录。每次做完一批装机，我都会在服务器上留一份记录，写清楚这次用了哪个镜像、客户的机型、遇到过什么问题、怎么解决的。时间长了这份记录就变成了自己的经验库，下次遇到类似机型的时候能少走很多弯路。这不是什么高大上的方法论，就是老老实实记笔记。

最后分享一个我在实际使用中养成的习惯：正式批量装机之前，先用一台机器走完整流程，从 PXE 引导一直到系统进入桌面，确认全流程没问题再放量。这看起来很浪费时间，但比起十台机器同时卡在同一个环节上再回头排查，这一台机器的验证时间花得太值了。装机这件事没有什么黑科技，把每个环节验证清楚，把每次踩的坑记下来，稳定就是靠这种笨办法堆出来的。

如果后续你想把这套环境做得更完善，可以往几个方向扩展：一是把应答文件写得更细，做到真正的零干预；二是给不同的硬件型号准备各自的驱动包，在 PE 阶段注入网卡和存储驱动，避免遇到新硬件识别不出硬盘的情况；三是在服务器上加一个简单的文件服务，把装完机之后常用的软件打包放上去，客户端首次启动时自动拉取安装。这些扩展都是在这个基础上往外生长，核心的引导链路不动，加东西的风险就很低。