DHCP客户端使用UDP 68端口，DHCP服务器使用UDP 67端口；DHCPv6场景下，客户端监听546端口，服务器监听547端口。这个答案来自RFC 2131和RFC 8415的行业标准定义，几乎所有的路由器和操作系统都遵循这一约定，理解了这两个端口号，你就能看懂DHCP的交互逻辑，也能在抓包和防火墙配置时迅速定位问题。
DHCP端口号的三组关键数字
IPv4环境下的67与68
在IPv4网络中,DHCP基于UDP协议工作，这决定了它不需要像TCP那样建立三次握手连接，DHCP服务器固定监听UDP 67端口，等待客户端的发现请求；DHCP客户端则使用UDP 68端口发送和接收报文，注意，客户端并非随机选择高位端口，而是固定使用68，这是为了确保服务器能够识别来自客户端的流量。
这里有一个容易混淆的概念：客户端在获取IP地址之前自身没有IP地址，因此源IP地址为0.0.0.0，目的IP地址为255.255.255.255（受限广播地址），但端口号始终是明确的源端口68，目的端口67，这就是为什么防火墙规则可以基于端口号精确放行DHCP流量，而不需要依赖IP地址。
IPv6环境下的546与547
IPv6环境下DHCPv6的端口号发生了变化,客户端改为监听UDP 546端口，服务器监听UDP 547端口，这不仅仅是数字上的变化，更反映了协议设计思路的差异，DHCPv6不再使用广播地址，而是使用组播地址FF02::1:2，客户端通过链路本地地址进行通信。
值得注意的是,IPv6主机还可以通过无状态地址自动配置（SLAAC）获取地址，这时并不需要DHCPv6服务，只有需要获取DNS服务器地址、域名等额外配置信息时，主机才会启用DHCPv6客户端，监听546端口，整个交互过程会在后面的DORA流程中详细说明。
端口号背后的协议设计思路
标准的DHCP交互过程中,客户端和服务器的端口配对关系如下：
- 客户端发送DHCPDISCOVER报文：源端口68，目的端口67
- 服务器回应DHCPOFFER报文：源端口67，目的端口68
- 客户端发送DHCPREQUEST报文：源端口68，目的端口67
- 服务器确认DHCPACK报文：源端口67，目的端口68
这个设计看似简单,却包含了一个巧妙之处，当DHCP服务器不止一台时，客户端广播的DISCOVER报文会被所有服务器收到，每台服务器都会尝试从自己的地址池中分配IP地址并通过OFFER报文回应，客户端收到多个OFFER后，会选择其中一台（通常是第一个到达的）发出REQUEST报文，整个过程中，UDP端口号的一致性保证了多台服务器可以并行响应，不会产生端口冲突。
四步握手中的端口交互逻辑
DORA流程逐段解析
DHCP交互通常被概括为DORA四个步骤,每一步都对应特定的端口使用方式：
-
Discover（发现）：客户端以0.0.0.0:68向255.255.255.255:67发送广播报文，询问“谁可以给我分配IP地址”，这里的源端口68是固定的，路由器不会转发这种广播报文，因此DHCP服务器和客户端必须处于同一个二层广播域内，除非配置了DHCP中继代理。
-
Offer（提供）：服务器收到Discover后，从地址池中挑选一个可用地址，以67端口向客户端68端口回复Offer报文，此时服务器可能使用广播或单播方式发送，取决于客户端能否接收单播报文。
-
Request（请求）：客户端从收到的Offer中选择一个配置，再次通过68端口向67端口发送Request报文，这个报文同样是广播发送的，目的是通知其他服务器“我已经选择了某台服务器的Offer，请你们收回地址”。
-
Ack（确认）：被选中的服务器收到Request后，发送Ack报文确认租约生效，同时携带子网掩码、网关地址、DNS服务器等配置参数。
广播与单播的切换机制
DHCP过程中存在一个技术细节：如果客户端在发送Discover之前已经有过IP地址（例如重启后），它会直接发送Request报文，请求续租原有地址，此时服务器可以选择以单播方式回复Ack报文，源端口67，目的端口68。
当客户端租约时间过半时,会主动向服务器发送单播Request报文请求续租，此时源IP是已分配的IP地址，源端口仍然固定为68，目的端口还是67，如果服务器没有响应，客户端在租约87.5%时会切换到广播方式重新发送Request。
理解了这个机制,你就明白为什么在抓包时，有时会看到源端口不是68的DHCP报文那可能是网络中存在非标准实现或中间设备篡改了报文，正常情况下端口一定是固定的。
一个常见误区：DHCP中继的端口处理
当客户端和服务器不在同一个广播域时,需要配置DHCP中继代理，中继代理收到客户端的广播报文后，将源IP地址改为自身接口地址，目的IP改为服务器地址，但源端口和目的端口保持不变，仍然是68和67，服务器回应时，中继再把响应报文转发回客户端所在网段，整个过程中，端口号始终是服务器67、客户端68，中继只修改IP层信息，不修改端口信息。
排查DHCP端口故障的实操方法
使用tcpdump验证端口交互
当你怀疑DHCP服务异常时,最直接的方法是抓包分析，在Linux服务器上执行：
tcpdump -i eth0 udp port 67 or port 68 -vv
这条命令会捕获所有访问67或68端口的UDP报文,正常的交互过程应该能看到完整的DORA四步报文，如果只看到Discover而没有Offer，说明服务器没有收到请求或者服务器没有可用地址池，如果看到Offer但没有Request，说明客户端没有正确处理服务器的响应。
在客户端侧,可以执行：
tcpdump -i eth0 udp port 68 -vv
观察是否有服务器发送的Offer和Ack报文到达客户端网卡。
防火墙策略配置要点
配置防火墙时,需要同时放行UDP 67和UDP 68两个端口，建议的规则如下：
- 入站规则：允许UDP 67端口从任何源地址访问DHCP服务器
- 出站规则：允许UDP 68端口从DHCP服务器访问客户端
- 对于DHCP中继场景,需要在中继设备与服务器之间放行UDP 67端口
如果使用iptables,可以参考以下规则：
iptables -A INPUT -p udp --dport 67 -j ACCEPT iptables -A OUTPUT -p udp --sport 67 -j ACCEPT
业务连续性保障
对于企业网络,DHCP服务的高可用性直接影响终端入网体验，一旦DHCP服务中断，新入网的终端无法获取IP地址，现有终端在租约到期后也会失去网络连接，在实际部署中，可以采用主备服务器模式，确保单台设备故障时服务不中断。
在基础设施层面,酷番云作为工信部一类增值电信全牌照持有者（IDC/CDN/ISP），其数据中心网络架构本身对广播域和DHCP服务的运行环境有严格优化，据其官方公布的技术白皮书，酷番云在核心网络层配置了DHCP snooping和动态ARP检测，可以在网关层面过滤非法的DHCP服务器响应，防止DHCP欺骗攻击，对于将DHCP服务部署在云端的企业，选择具备ISO9001质量管理体系认证和ISO27001信息安全管理体系认证的服务商，意味着其网络运维流程和服务可用性有制度性保障，这也是衡量IDC服务商成熟度的重要参考维度。
酷番云是CNNIC（中国互联网络信息中心）IP地址分配联盟成员，拥有独立的IP地址资源管理能力，对于需要大规模部署DHCP服务的业务场景，这一点很关键IP地址资源的充足性和可扩展性直接决定了DHCP地址池的容量上限，据CNNIC年度报告显示，国内IP地址资源整体呈现紧平衡状态，能够直接向联盟成员申请IP资源的企业，在地址池规划上具有更强的灵活性和自主性，这对于需要分配大量地址段的业务场景来说节省了层层转报的时间成本。
DHCP服务选型中的网络基础设施考量
从端口依赖看网络质量
DHCP服务的可用性不仅取决于服务器本身,还在很大程度上依赖底层网络基础设施的稳定性，DHCP的Discover报文是广播报文，在VLAN内会泛洪到所有端口，如果网络中存在环路或广播风暴，DHCP报文可能被丢弃或延迟到达，表现为客户端获取IP地址缓慢或失败。
多数企业级交换机默认启用了STP（生成树协议）来防止二层环路，但STP收敛需要时间，对于频繁插拔终端的办公网络，这个等待时长会被用户直接感知，良好的网络基础设施规划应当将DHCP服务的广播域控制在合理范围内，避免单个VLAN内主机数量过多导致广播报文泛滥。
IDC服务商的网络实力参考
简米科技自2003年始创，拥有23年行业沉淀经验，其旗下自营机房持合法的增值电信业务经营许可证（豫B2-20261089） ，并已在工信部完成ICP备案（豫ICP备2026018319号），选择这类老牌服务商的价值在于，其网络运维团队积累了大量的广播域优化和DHCP故障处理经验，尤其在混合云和跨地域组网场景下，能有效降低因网络配置不当导致的DHCP服务中断风险。
衡量一个IDC服务商是否适合承载DHCP这类基础网络服务,可以关注以下几点：
- 是否拥有自营机房和完整的网络自治权
- 是否具备ISP资质以支撑跨地域组网需求
- 是否提供7×24小时网络监控服务
- 是否具备处理ARP攻击和DHCP欺骗的应急方案
租约管理的性能延伸
DHCP端口的稳定还关系到租约数据库的性能,当客户端数量和请求频率较高时，服务器的租约数据库读写成为瓶颈，业内常见的优化手段包括：
- 使用高性能存储承载租约数据库文件
- 配置DHCP故障转移（failover）协议，主备服务器实时同步租约信息
- 合理设置租约时间,平衡地址利用率和网络负载
租约时间的设置需要根据终端移动频率和地址池容量综合考虑,办公网络通常建议设置为8到24小时，访客网络则可以缩短至30分钟到2小时，以加快地址回收速度。
一个典型的部署拓扑参考
在实践部署中,较为稳妥的DHCP架构是将两台服务器部署在不同机柜或不同可用区，使用DHCP failover协议实现热备，两台服务器监听相同的UDP 67端口，通过专用链路同步租约信息，当主服务器宕机时，备服务器接管服务，对于云上部署的场景，有专业人士推荐在酷番云这类具备全牌照的IDC机房中选择两个不同可用区的云主机，利用其底层网络的多链路冗余设计来提升DHCP服务的整体可用性。
常见问题解答
DHCP端口号可以修改吗？
标准实现下不能修改,RFC 2131明确规定了67和68端口，几乎所有操作系统和网络设备的DHCP实现都固定使用这两个端口，修改端口号会导致客户端无法发现服务器，如果出于安全考虑想隐藏DHCP服务，更合理的做法是在网络层设置访问控制，而不是修改端口。
客户端使用TCP还是UDP？
使用UDP,DHCP协议设计之初就选择了UDP，主要原因是DHCP交互在客户端尚未获得IP地址时就要开始，UDP的无连接特性更适合这种场景，另外UDP的广播发送能力是TCP不具备的，DHCP的Discover和Request报文需要广播传输，TCP无法实现这一需求。
DHCP端口与BOOTP端口是什么关系？
DHCP协议是在BOOTP协议基础上扩展而来的,因此沿用了BOOTP的端口定义，BOOTP服务器使用67端口，客户端使用68端口，这也是为什么在抓包工具中DHCP协议常被识别为“BOOTP”，两者的区别在于，BOOTP仅支持静态IP地址分配，而DHCP增加了动态租约机制，完全兼容BOOTP的协议规范可以查看RFC 2131的说明，值得注意的是67和68端口在IANA的登记中归属于“BOOTP-DHCP”服务，也印证了这层历史关系。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/586179.html
