DHCP 这东西，平时网络通的时候没人会想起它，一旦出问题，整层楼的人都跑来问你"为什么我的电脑上不了网"。我在机房和办公网里配过不少次 DHCP 服务，从最早照着文档一行行抄配置，到后来被各种"地址池耗尽""IP 冲突""租约不生效"折腾得够呛，慢慢才摸清这套东西的脾气。这篇就围绕在 Linux 上配置 DHCP 服务这件事，把原理、配置、排错、优化一条线讲透，适合刚接触网络服务配置的新手，也适合已经会敲命令但总在细节上翻车的朋友。
先把话说清楚：DHCP 的核心价值不是"自动发 IP"这么简单，它解决的是一整套地址生命周期管理问题——谁该拿地址、拿多久、续租怎么处理、地址冲突怎么防、不同设备怎么区分对待。你在配置文件里写的每一行，背后都对应着协议里的一个字段或一个交互阶段。理解了这层，配置就不再是背参数，而是按需求翻译成规则。
1. 先搞清楚 DHCP 到底在替谁干活
很多人一上来就急着装软件、改配置文件，结果连"为什么需要 DHCP"都说不明白。我见过有同事在只有五台机器的环境里手动配静态 IP，配完还觉得自己很稳，直到有人把笔记本插到另一个网口，地址冲突了才发现问题。DHCP 存在的意义，是把地址分配这件事从"人工记忆"变成"规则驱动"。
1.1 四个报文阶段：DISCOVER、OFFER、REQUEST、ACK
DHCP 的交互过程常被简化成"客户端要地址、服务器给地址"，但真正排错时你必须记住四个阶段。客户端开机后先发DHCPDISCOVER广播，意思是"这个网段里有没有 DHCP 服务器"。服务器收到后回DHCPOFFER，里面带着准备分配的 IP、租期、网关、DNS 等信息。客户端可能收到多个 OFFER，它会挑一个，然后发DHCPREQUEST广播，明确告诉所有服务器"我选了这个"。最后服务器回DHCPACK确认，地址正式生效。
这里有个容易被忽略的点：REQUEST 是广播的，目的是让没被选中的服务器收回它们预分配的地址。如果你在抓包时只看到 DISCOVER 和 OFFER 就断了，大概率是中间有防火墙拦了广播，或者服务器地址池里根本没有可用地址。我排查过一次"客户端一直拿不到地址"的问题，最后发现是交换机上开了某种广播抑制，DISCOVER 根本没到服务器，这种时候看服务器日志是看不出问题的，得从链路层往上查。
1.2 租约不是"永久占有"，续租机制决定了地址回收效率
DHCP 分配的地址是有租期的，默认常见是 12 小时或 24 小时。租期过半时，客户端会主动发 REQUEST 续租；如果服务器没响应，它会继续尝试，直到租期到 87.5% 时进入重绑定阶段，开始广播找其他服务器。这个机制的设计意图是：既保证客户端在正常使用时地址稳定，又能在设备离线后把地址回收给其他人用。
实际配置时租期设多长很有讲究。办公网里员工电脑流动性大，租期设短一点（比如 8 小时）能让地址回收更快，避免地址池被离线设备占着；但租期太短会增加续租报文量，网络里设备多的时候会有额外负担。机房里的服务器如果也用 DHCP，租期反而要设长，甚至做静态绑定，因为服务器地址频繁变化会带来一堆依赖问题。我一般给办公终端设 8 到 12 小时，给打印机、摄像头这类固定设备做 MAC 绑定并给长租期，这个组合用下来最省心。
1.3 为什么地址池规划比配置文件本身更重要
配置文件写错一行还能改，地址池规划错了就是返工。规划时要回答几个问题：这个网段有多少可用地址、要预留多少给静态设备、动态池从哪开始到哪结束、网关和 DNS 放在哪。举个具体例子，一个 /24 网段有 254 个可用地址，网关占 1 个，如果你有 20 台打印机和摄像头要做静态绑定，那动态池最好从 .100 开始往后分，前面 .2 到 .99 留给固定设备和预留。
我踩过的坑是：早期图省事，动态池直接从 .2 开始，结果后来加了几台网络打印机做静态绑定，地址和动态池重叠，某天打印机重启后拿到的地址和另一台设备冲突，整个打印队列卡住。从那以后我养成了习惯——动态池永远从网段中后段开始，前面留足静态空间，并且在配置文件里用注释标清楚每段地址的用途。这个习惯看起来笨，但能省掉大量事后排查。
2. 选型与安装：isc-dhcp-server 还是别的方案
Linux 上做 DHCP 服务，主流选择是isc-dhcp-server，老牌、文档多、配置直观。也有 dnsmasq 这种轻量方案，把 DNS 和 DHCP 合在一起，适合小环境。选哪个不是看哪个新，而是看你的场景需要什么。
2.1 isc-dhcp-server 的适用边界
isc-dhcp-server 功能完整，支持地址池、静态绑定、多网段、选项下发、租约文件管理，配置文件是经典的dhcpd.conf语法。它的优点是规则表达能力强，比如你可以按客户端类型、按 MAC 前缀、按请求的网段做不同处理。缺点是配置语法有点老派，出错时日志不够友好，新手容易在分号、括号上栽跟头。
我一般在中大型办公网、需要精细控制的场景用它。比如要给不同部门分配不同 DNS、给访客网络单独限速策略、给 IP 电话下发特定选项，这些用 isc-dhcp-server 都能干净地表达。安装命令在 Debian 系和 RedHat 系不一样，Debian/Ubuntu 是apt install isc-dhcp-server，RedHat/CentOS 是yum install dhcp或dnf install dhcp-server，装完之后服务默认不会正常启动，因为配置文件还是空的，这是正常的，别慌。
2.2 dnsmasq 适合什么场景
dnsmasq 体积小、配置简单，一个配置文件里几行就能跑起来，而且自带 DNS 缓存功能。它特别适合家庭网络、小型办公室、实验环境，或者你本来就需要一个本地 DNS 转发器的场景。缺点是复杂策略表达能力不如 isc-dhcp-server，比如按客户端类别做多套地址池这种需求，写起来会比较别扭。
我的经验是：设备数量在几十台以内、需求简单，dnsmasq 足够；一旦涉及多网段、多策略、静态绑定数量大，直接上 isc-dhcp-server，别为了省事后面再迁移。迁移成本比一开始选对要高得多。
2.3 安装后第一件事：确认监听网卡
装完软件后，Debian 系要改/etc/default/isc-dhcp-server里的INTERFACESv4，指定服务监听哪块网卡。这一步经常被跳过，结果服务起不来或者起来了但不响应。RedHat 系则是在/etc/sysconfig/dhcpd里配DHCPDARGS。指定网卡的意义在于：一台机器可能有多块网卡，你不希望 DHCP 服务在面向外网的那块网卡上也响应请求，那会带来安全和管理上的麻烦。
提示：改完网卡配置后一定要重启服务，并且用
ss -ulnp | grep dhcp确认服务确实在 UDP 67 端口监听。只看服务状态显示 active 不够，端口没监听等于没干活。
3. dhcpd.conf 的骨架：从全局到个体的规则层级
dhcpd.conf的结构是有层级的：全局配置在最外层，subnet声明网段，host声明单台设备。理解这个层级，你才知道一条配置该写在哪一层，以及层与层之间怎么覆盖。
3.1 全局段：租期、DNS、域名这些"默认值"
全局段通常写default-lease-time、max-lease-time、option domain-name-servers、option domain-name这些。它们的作用是给所有网段提供默认值，具体网段里可以覆盖。比如全局设default-lease-time 43200（12 小时），某个访客网段里可以单独设成 3600（1 小时），让访客地址回收更快。
这里有个细节：option domain-name-servers后面跟的是 IP 列表，多个 DNS 用逗号分隔，末尾要有分号。我见过新手写成域名，或者漏了分号，服务启动直接报语法错误。dhcpd -t -cf /etc/dhcp/dhcpd.conf这个命令可以在启动前做语法检查，养成习惯能省很多事。
3.2 subnet 段：地址池、网关、广播地址三件套
每个网段一个subnet块，里面必须写range（动态池范围）、option routers（网关）、option subnet-mask（子网掩码）。range可以写多段，比如range 192.168.10.100 192.168.10.150;和range 192.168.10.160 192.168.10.200;，中间留空给静态设备。这种写法在需要预留地址时很实用。
网关配置有个常见误区：有人把option routers写成服务器自己的地址，但服务器如果不在这个网段里，客户端拿到这个网关是走不通的。DHCP 服务器可以跨网段服务（通过中继），但下发的网关必须是客户端所在网段的网关地址。跨网段场景下，subnet块里的网关要写目标网段的网关，不是服务器地址。
3.3 host 段：静态绑定的正确姿势
静态绑定用host块，里面写hardware ethernet（MAC 地址）和fixed-address（固定 IP）。MAC 地址格式是冒号分隔的六组十六进制，比如00:1a:2b:3c:4d:5e。这里最容易出的错是 MAC 抄错一位，或者用了连字符格式，服务启动时报错或者绑定不生效。
我的做法是：绑定前先在客户端上用ip link或ifconfig确认 MAC，复制粘贴而不是手敲。绑定数量多的时候，我会在配置文件里按设备类型分组加注释，比如"打印机区""摄像头区"，后面维护时一眼能看出哪台是哪台。另外，fixed-address的地址必须在对应subnet声明的网段内，否则服务启动会报"not in subnet"之类的错误。
4. 让配置真正生效：启动、验证与租约文件
配置文件写完只是第一步，服务能不能正常分配地址，要靠验证来确认。这一步很多人跳过，结果上线后才发现问题。
4.1 启动服务与看日志的正确方式
Debian 系用systemctl restart isc-dhcp-server，RedHat 系用systemctl restart dhcpd。启动后立刻看日志：journalctl -u isc-dhcp-server -f或tail -f /var/log/syslog | grep dhcpd。日志里会显示服务监听了哪些网卡、加载了哪些 subnet、有没有语法警告。
如果服务起不来，先跑语法检查dhcpd -t -cf /etc/dhcp/dhcpd.conf，它会指出具体哪一行有问题。常见错误包括：漏分号、括号不匹配、subnet声明的网段和range不匹配、fixed-address不在网段内。这些错误日志里都会写清楚行号，照着改就行。
4.2 用另一台机器实测拿地址
配置对不对，最直接的验证是找一台客户端连到对应网段，让它重新获取地址。Linux 客户端可以用dhclient -v eth0看详细过程，Windows 用ipconfig /release再ipconfig /renew。观察客户端拿到的 IP 是否在池内、网关和 DNS 是否正确。
我习惯在验证时同时看服务器端的租约文件/var/lib/dhcp/dhcpd.leases，里面记录了每次分配：谁拿的、什么时间、租期多久。这个文件是排查"某台设备为什么拿到奇怪地址"的关键证据。比如你发现某设备拿到的地址不在你预期的池里，翻租约文件就能看到它是什么时候、以什么 MAC 拿的。
4.3 租约文件的手动干预与风险
租约文件理论上不该手动改，但排错时偶尔需要。比如某台设备换了网卡，旧租约还占着地址，新 MAC 拿不到原来那个 IP。这时候可以停服务、编辑租约文件删掉旧记录、再启动。但要注意：租约文件有格式要求，手动改容易破坏结构，改之前先备份。
更稳妥的做法是用dhcpd的管理方式处理，或者干脆等租约过期。我一般不建议手动改租约文件，除非是紧急情况。日常更推荐的做法是：静态绑定的设备永远走host块，不依赖动态租约，这样换网卡时改一下 MAC 就行，不用碰租约文件。
5. 那些文档里不写的排错链路
DHCP 出问题时，现象往往很模糊——"上不了网""拿不到地址""时好时坏"。真正有效的排错不是猜，而是按链路一层层缩小范围。
5.1 客户端拿不到地址：从广播能不能到达开始查
第一步不是看服务器配置，而是确认客户端的 DISCOVER 广播有没有到达服务器。在服务器上抓包tcpdump -i eth0 port 67 or port 68 -n，然后让客户端重新获取地址。如果抓不到 DISCOVER，问题在链路层：VLAN 不对、交换机端口隔离、广播抑制、网线问题。如果抓到了 DISCOVER 但服务器没回 OFFER，问题在服务器：地址池耗尽、配置没覆盖这个网段、服务没监听正确网卡。
这个顺序很重要。我见过有人一上来就改配置文件，改了半天发现是客户端插错了 VLAN。先确认报文通不通，再谈配置对不对。
5.2 地址池耗尽的识别与处理
地址池耗尽的典型现象是：部分客户端能拿到地址，新接入的拿不到，日志里出现 "no free leases"。用dhcpd的统计或者直接数租约文件里的活跃记录能确认。处理方式有几种：扩大range范围、缩短租期加快回收、清理失效租约、把不该占动态地址的设备改成静态绑定。
我遇到过一次池子耗尽，查下来是几十台测试设备长期在线占着地址，租期又设得长。后来把测试网段的租期改成 2 小时，并且给测试设备单独划了一个小池子，问题就解决了。这个经验说明：不同用途的设备最好分池管理，别混在一起。
5.3 IP 冲突的根因往往不在 DHCP
客户端报"IP 地址冲突"，很多人第一反应是 DHCP 配错了。但 DHCP 服务器分配地址前一般会做冲突检测（ping 一下确认没人用），真正冲突的根因往往是：有人手动配了静态 IP 且落在动态池范围内、静态绑定和动态池重叠、或者网络里有另一个 DHCP 服务器在发地址。
排查方法是：冲突发生时，在冲突的两台机器上看 MAC 和获取方式。如果一台是手动静态、一台是 DHCP，那就是静态地址规划问题。如果两台都是 DHCP 拿的，那要怀疑有多个 DHCP 服务器，用抓包看 OFFER 来源。我处理过一次双 DHCP 服务器冲突，原因是旧服务器没下线，新服务器上线后两边都在发地址，客户端随机选，表现就是时好时坏。
5.4 跨网段场景：中继配置是绕不开的一环
DHCP 广播不跨网段，跨网段服务必须配中继（relay）。中继设备把客户端的广播转成单播发给 DHCP 服务器，服务器根据giaddr字段判断客户端在哪个网段，从对应subnet块里分配地址。配置中继时最容易出的错是：中继指向的服务器地址不对、服务器上没有声明客户端所在网段、或者中间防火墙拦了 UDP 67。
跨网段排错时，抓包要看giaddr字段有没有正确设置。如果giaddr是 0.0.0.0，说明中继没生效，服务器不知道该从哪个池子分配，通常会拒绝或分配错误网段的地址。
6. 把服务做稳：几个提升可靠性的实操习惯
配置能跑通只是及格线，要让 DHCP 服务长期稳定，还得在细节上做功课。下面这些是我这些年攒下来的习惯，都是踩过坑之后总结的。
6.1 配置文件版本化与变更记录
dhcpd.conf是纯文本，天然适合版本管理。我习惯每次改动前先备份，文件名带日期，比如dhcpd.conf.20240115。改动后在文件头注释里写清楚改了什么、为什么改、谁改的。这个习惯在多人维护的环境里尤其重要，出问题时能快速回滚，也能知道某条规则是谁加的。
更进一步的做法是把配置文件放进版本控制，每次变更走提交记录。这样不仅能回滚，还能对比历史差异，排查"什么时候开始出问题"特别有用。
6.2 监控租约使用率，别等耗尽才发现
地址池使用率是个值得监控的指标。简单做法是定期统计租约文件里的活跃记录数，和池子大小对比，超过 80% 就预警。复杂一点可以写脚本解析租约文件，输出使用率趋势。我一般会在池子使用率到 70% 时就开始规划扩容或清理，留出缓冲。
监控的另一个价值是发现异常设备。如果某个 MAC 频繁获取地址、或者某类设备占用大量地址，监控数据能帮你定位。比如发现某网段地址消耗异常快，查下来是虚拟化环境里大量临时虚拟机在反复获取地址，这种情况就需要给虚拟化环境单独规划地址池。
6.3 静态绑定与动态池的边界要写死在注释里
前面提过动态池和静态绑定的地址重叠问题，根治办法是在配置文件里用注释明确标出边界。比如：
# ===== 静态保留区：192.168.10.2 - 192.168.10.99 ===== # 网关 .1，打印机 .10-.20，摄像头 .30-.50，预留 .51-.99 # ===== 动态池：192.168.10.100 - 192.168.10.200 ===== 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 subnet-mask 255.255.255.0; }这种注释不是形式主义，是给未来的自己和同事看的。地址规划一旦写清楚，后面加设备时就不会随手往池子里塞，冲突概率大幅下降。
6.4 服务高可用：至少想清楚单点故障怎么办
单台 DHCP 服务器挂了，整个网段的设备续租失败，租期到了就断网。小环境里这可能可以接受，但办公网里影响面很大。高可用方案有几种：跑两台服务器做地址池分割（各管一半地址，互不重叠）、或者用支持故障转移的配置做主备。地址池分割方案简单可靠，两台服务器配置各自的range，客户端随机选，一台挂了另一台还能服务。
做高可用时要注意：两台服务器的地址池绝对不能重叠，否则会出现同一地址被两台服务器分配的情况。另外，静态绑定要在两台服务器上都配，保证无论哪台响应，固定设备都能拿到正确地址。
7. 从"能跑"到"好用"：选项下发与场景化配置
DHCP 不只是发 IP，它还能下发各种选项，把网络配置集中管理。用好这些选项，能减少大量手动配置工作。
7.1 常用 option 清单与下发逻辑
除了网关和 DNS，常用的还有option domain-name（域名后缀）、option ntp-servers（时间服务器）、option broadcast-address（广播地址）、option netbios-name-servers（老式 Windows 环境用）。这些选项写在全局段或 subnet 段，按需覆盖。
下发逻辑是：客户端请求时，服务器把对应网段的选项打包进 OFFER/ACK。客户端收到后按需使用。要注意的是，不是所有客户端都认所有选项，比如某些精简系统可能忽略 NTP 选项。配置前最好确认目标客户端支持哪些选项，别配了不生效还以为是服务器问题。
7.2 按设备类型分池的实用写法
用class和subclass可以按条件分组，比如按 MAC 前缀区分设备厂商，给不同厂商的设备分配不同池子。这种写法在设备类型混杂的环境里很有用，比如把 IP 电话和电脑分开，给电话下发特定选项。
配置思路是先定义 class 匹配条件，再在 subnet 里用pool块给不同 class 分配不同 range。这种配置比单一 range 复杂，但表达能力强。我一般只在确实需要区分策略时才用，简单环境里没必要增加复杂度。
7.3 访客网络与内部网络隔离的配置差异
访客网络通常需要：短租期、独立 DNS（或限制性 DNS）、独立地址池、可能还要限制访问内部网段。这些都可以通过单独的 subnet 块实现。关键是访客网段和内部网段要在网络层隔离，DHCP 只负责发地址，隔离靠 VLAN 和防火墙策略。
配置访客网段时，租期设短（比如 1 到 2 小时），DNS 可以指向公共解析或专门的访客 DNS，网关指向访客网关。这样即使访客设备行为异常，影响范围也限制在访客网段内。
8. 收尾前再聊几句实在的
配 DHCP 这件事，技术门槛不高，但细节密度大。我见过太多"配置看起来没问题但就是不工作"的案例，最后根因往往是最不起眼的地方：一个漏掉的分号、一个抄错的 MAC、一个没指定的监听网卡、一个没配的中继。这些问题的共同点是——它们不会在配置文件语法检查里报错，只会在实际运行时暴露。
所以我的建议是：每次改完配置，别只看服务状态，一定找台客户端实测一遍完整流程，从获取地址到能上网。实测通过再收工，这个习惯能挡掉大部分低级问题。另外，地址规划这件事值得多花时间，前期规划清楚，后期维护成本会低很多。动态池和静态区的边界、租期长短、是否做高可用，这些决策在配置之前想明白，比配置之后再补救要省事得多。
最后分享一个我常用的检查清单，每次上线前过一遍：服务监听网卡对不对、subnet 声明和 range 是否匹配、网关和 DNS 是否属于目标网段、静态绑定 MAC 是否准确、租约文件路径是否可写、日志里有没有警告。这六项过完，基本不会出大问题。
