虚拟机测试DHCP获取不到IP，十有八九是虚拟网卡没真正桥接到宿主物理网卡，或者虚拟机系统内的网卡没有正确启用，排查时按“虚拟网络配置 → 系统网卡状态 → DHCP客户端 → 防火墙 → 服务端地址池”的顺序来，几分钟就能定位问题。
绝大多数虚拟化平台（如VMware Workstation、VirtualBox、Proxmox VE）默认使用NAT或仅主机模式，这两种模式下虚拟机的DHCP请求由虚拟网段内的内置DHCP服务响应，而非你物理局域网里的路由器，如果你在测试环境里搭建了独立的DHCP服务器，却把虚拟机放进了NAT网络,那它永远拿不到你想要的地址。
先看虚拟网络适配器：桥接模式是首要排查点
场景描述：你在一台物理服务器上装了VMware ESXi，里面跑了一台Ubuntu虚拟机测试DHCP中继，结果虚拟机启动后一直显示“正在连接网络”，ip a命令只有127.0.0.1，这时候先别碰虚拟机系统,直接回物理机上看虚拟交换机的配置。
桥接模式与NAT模式对DHCP的影响差异
| 网络模式 | DHCP请求发送目标 | 能否被测试的DHCP服务器感知 | 适用场景 |
|---|---|---|---|
| 桥接模式 | 物理局域网广播域 | 能，与实体机无异 | 模拟真实客户机 |
| NAT模式 | 虚拟NAT网段的私有网段 | 不能，由宿主机内置服务响应 | 仅需上网 |
| 仅主机模式 | 虚拟私有网段 | 不能，无路由转发 | 隔离测试 |
如果你在VMware Workstation里做实验，且物理机是通过Wi-Fi上网，桥接模式经常会有兼容性问题，行业共识认为，Wi-Fi桥接时虚拟机构造的数据帧无法被某些无线AP正确处理，导致DHCP的Discover报文根本出不去，这时候可以换一个思路：把虚拟机的物理网络连接改为“自定义”并指定到已桥接到有线网卡的VMnet,或者直接改用NAT模式加端口转发来测试。
检查虚拟机网卡是否真的“连接”了
在虚拟机设置里，有一个常被忽略的选项叫“设备状态”启动时连接，如果不勾选，网卡在系统内根本不存在，更别说DHCP了，VMware网卡类型里，E1000和VMXNET3对DHCP的支持有细微差异，VMXNET3是半虚拟化驱动，性能好，但如果虚拟机系统缺少对应驱动，你可能连网卡设备都看不到，此时把网卡临时换成E1000，获取IP后尽快安装VMXNET3驱动,也是常见的操作路径。
虚拟机系统内部：网卡没启动才是最常见的障眼法
场景描述：你的CentOS虚拟机从模板克隆出来，开机后ip addr显示网卡状态为DOWN，DHCP客户端也启动了，但就是拿不到IP，很多新手会去查DHCP服务端,实际上问题在系统内部。
Linux虚拟机网卡启停与DHCP客户端状态
多数Linux发行版默认使用NetworkManager或systemd-networkd管理网络，克隆虚拟机或者从快照恢复正常时，网卡的MAC地址变了，但配置文件里还引用着旧MAC，系统会自动把网卡命名为eth1或ens224，而原来的ifcfg-eth0文件压根没被加载,这种情况下DHCP客户端根本没有运行在活动网卡上。
排查步骤很直接：
- 执行
ip link show，看网卡状态是否为UP、是否有LOWER_UP标志 - 执行
ethtool eth0，确认物理链路已连接 - 查看配置文件目录
/etc/sysconfig/network-scripts/，核对设备名与MAC匹配 - 运行
systemctl restart NetworkManager或者dhclient ens33手动发起一次请求
这里有一个重要细节：DHCP客户端本身也可能出现问题，比如/etc/NetworkManager/NetworkManager.conf里设置了[main] dhcp=internal，内部实现和dhclient的行为略有差异，偶尔会忽略DHCP Offer中的某些选项，导致拿不到完整的租约信息，更换dhcp客户端类型，或者查看/var/log/messages里是否有dhclient的报错日志,都能快速定位。
Windows虚拟机系统网卡排查
Windows虚拟机拿不到IP时，先看“网络和共享中心 → 更改适配器设置”里的网卡是否被禁用，Windows Server系统里，如果启用了“网络访问: 不允许存储网络身份验证的密码和凭据”这个安全策略，DHCP过程中涉及的网络访问保护功能会异常，导致地址被拒绝，Hyper-V的虚拟机在设置“高级功能”里的“MAC地址欺骗”为关闭状态时，如果DHCP服务器和虚拟机不在同一物理VLAN，请求会被丢弃，此时启用MAC地址欺骗，或者改用静态MAC地址绑定,能解决大部分路由交换环境下的问题。
VMware虚拟机无法获取IP地址时的防火墙排查
很多人在服务端能看到DHCP Discover和Offer，但虚拟机Client就是不发Request，或者发了Request服务端没反应，这种情况很大概率是虚拟机的软件防火墙拦截了DHCP数据包。
dhcp在udp 67和68端口工作，DHCP客户端在获取IP之前，会用0.0.0.0作为源地址发送广播，部分Linux发行版的firewalld规则假设所有入站数据包都必须有合法源IP，这就把DHCP Offer拦在了门外,处理办法是临时禁用防火墙做对照测试：
- 执行
systemctl stop firewalld，然后再执行dhclient -r后重新发起请求 - Proxmox VE里的虚拟机如果启用了云init，检查是否被注入了自定义的防火墙规则
- VMware Tools中有一个“时间同步”选项，如果开启且宿主时钟偏差过大，可能导致Kerberos认证失败，间接影响某些类型的DHCP租约更新，但这在纯DHCP环境中较少见
服务端侧：DHCP地址池和租约冲突是隐形杀手
如果客户端、网卡、防火墙都查过了没问题,那就得把视线转回DHCP服务器本身。
地址池耗尽与租约残留
近年来，虚拟化测试环境里经常出现地址池耗尽的问题，原因是大量从快照恢复的虚拟机带着旧租约回到网络，而DHCP服务器还没等到租约到期，就认为地址已被占用，尤其在测试环境多次重置虚拟机状态时，租约文件里残留了大量无效记录，运行dhcpd -6 -d -f在前台调试模式观察，或者在配置文件里把default-lease-time缩短到600秒,这类问题能明显缓解。
多DHCP服务器冲突
虚拟化测试环境里很容易同时存在多个DHCP服务，比如Windows宿主机启用了Internet连接共享，Linux宿主机又跑着一个dnsmasq，虚拟网络内部还有嵌入式DHCP，多个响应源会让客户端无从选择,排查时用tcpdump抓包最直接：
tcpdump -i br0 port 67 or port 68 -n
观察Discovery广播之后有多少个Offer响应，如果数量超过一个，逐个停掉多余的DHCP服务，保留你真正要测试的那一台，同类问题也出现在虚拟机测试DHCP中继时，中继代理会把请求转发到多个IP地址，导致服务端收到重复的Relay消息,处理逻辑混乱后不响应。
核心排查路径速查表
| 排查序号 | 检查对象 | 核心操作 | 预期正常结果 |
|---|---|---|---|
| 1 | 虚拟机网卡连接状态 | 确认“启动时连接”已勾选 | 开机后网卡存在 |
| 2 | 网络模式 | 桥接到正确物理网卡或虚拟交换机 | 能收到物理网络广播 |
| 3 | 系统网卡配置 | ip link set up | 状态为UP |
| 4 | DHCP客户端 | 手动执行dhclient | 看到DHCPACK |
| 5 | 防火墙 | systemctl stop firewalld | 允许UDP 67/68 |
| 6 | 服务端租约 | 查看租约文件、地址池容量 | 有可用IP |
虚拟机DHCP获取不到IP怎么解决？常见问答
虚拟机从NAT模式改成桥接模式后，反而获取不到IP了，是什么原因？
这通常是因为物理网络里没有可用的DHCP服务，或者物理网络开启了DHCP Snooping，DHCP Snooping会信任物理接口，但不信任虚拟机网卡发出的请求，物理机上的防火墙软件也可能阻断虚拟网卡转发过来的广播包，建议先检查物理网络的DHCP服务器是否正常，再关闭物理交换机端口的DHCP Snooping功能,或者为虚拟网卡配置静态IP测试连通性。
虚拟机测试DHCP时获取的IP和物理机在同一网段，但无法访问外网，怎么办？
当虚拟机已经拿到IP却不同外网，通常是路由层面出了问题，检查发现网关地址错误率较高，或者在Windows Server的“路由和远程访问”服务里未将虚拟网卡所在的网络接口绑定为该服务的内部接口，如果DHCP服务端明确下发了网关地址，却没有在下发时把链路本地路由填好，也会出现这类现象，解决方法是直接在虚拟机内执行ip route add default via 网关IP,同时确认物理路由器的回程路由指向了正确的虚机网卡所在网段。
dhclient -r之后重新启动，依然拿不到之前的IP地址，租约释放失败怎么办？
租约释放失败多发生在DHCP服务端的租约文件被锁定或权限不正确时，查看服务端日志，如果提示“no free leases”，说明地址池已满，进入备份目录清理过期租约，或者手动调整地址池范围来重置租约状态，再重启dhcpd服务就能恢复,这是虚拟化测试环境中最常见也最容易解决的地址分配异常。