虚拟机开了DHCP却上不了网，核心问题往往不在DHCP本身，而在虚拟机网络模式、物理机防火墙或IP地址冲突这三处。
虚拟机开DHCP后无法上网怎么办？先看清网络模式
虚拟机里的DHCP和我们平时说的“路由器自动分配IP”并不是一回事，虚拟机能不能拿到IP、拿到了能不能上网，取决于虚拟网卡挂在哪种网络模式下，绝大多数“开DHCP后上不了网”的情况，都是模式没选对，或者模式对了但配套服务没跟上。
NAT模式下，重点检查虚拟网卡和DHCP服务状态
用VMware Workstation或VirtualBox的默认配置创建虚拟机时，网络模式通常是NAT，这个模式下，虚拟机通过物理机的IP地址访问外部网络，DHCP地址由虚拟网卡对应的NAT服务分配，而不是物理路由器。
- 打开Windows服务管理（Win+R输入
services.msc），检查VMware NAT Service是否处于“运行”状态，这个服务被禁用或意外停止，是NAT模式上不了网的高频原因。 - 打开VMware的“虚拟网络编辑器”，确认VMnet8（NAT模式的虚拟网卡）的DHCP设置没有被手动关掉，子网IP段和掩码要保持默认，比如默认子网是
168.x.0，DHCP分配的起始地址池就在这个子网范围内。 - 虚拟机的网卡设置里,确认“网络连接”选的是NAT模式，有时候系统克隆或迁移后，虚拟网卡会意外变成“仅主机模式”，这种模式只能和物理机互通，上不了外网。
桥接模式下，DHCP地址由谁分配要看物理环境
桥接模式会让虚拟机像一台独立的电脑一样接入局域网,DHCP地址由物理网络里的路由器或交换机分配，这个模式下出问题，原因通常在物理网络侧。
- 物理路由器开启了IP/MAC绑定，但虚拟机是新建的，绑定列表里没有它的MAC地址，导致DHCP服务拒绝分配IP。
- 虚拟机所在的物理WiFi网络开启了“AP隔离”功能，这个功能会让同一WiFi下的设备互相隔离，虚拟机即使拿到IP也访问不了外网，很多办公室或公共WiFi会有这个限制。
- 物理网卡是无线网卡时,桥接模式经常不稳定，部分无线网卡驱动对桥接支持不完整，VMware会提示“无法将网络连接桥接到无线网卡”，这时换成NAT模式更省事，行业共识认为，无线网络环境下的桥接兼容性问题始终比有线环境高一个量级。
IP冲突怎么解决？从排查冲突源到静态IP规划
DHCP分配地址后仍然无法上网,先检查是不是IP冲突，IP冲突的典型表现是虚拟机刚开机能上网，过几分钟掉线，或者频繁弹出“检测到IP地址冲突”的提示，这种情况在DHCP模式下意外地常见，因为有些设备会绕过DHCP服务器手动指定IP，把DHCP池里的地址占了。
快速定位冲突源的命令
Windows虚拟机里打开命令提示符,Linux虚拟机打开终端，按下面步骤操作，多数情况下几分钟内能定位到冲突设备。
- 运行
ipconfig /all查看当前IPv4地址和子网掩码，在Linux系统下使用ip addr命令，效果相同。 - 在虚拟机里持续ping这个IP地址,Windows用
ping -t 192.168.x.x，Linux用ping 192.168.x.x，正常情况下，ping自己的IP不会收到回复，如果出现“来自192.168.x.x的回复”或者“Request timed out”交替出现，说明局域网里有另一台设备占用了相同IP。 - 运行
arp -a查看该IP对应的MAC地址，记录下这个MAC，再登录物理路由器的管理后台，在“DHCP客户端列表”里对比设备MAC，MAC地址不一致，就说明有设备没走DHCP、手动填了同一个IP。
从动态分配改成静态IP，要避开DHCP地址池
定位到冲突设备后,治本的办法是把虚拟机改成静态IP，同时避开DHCP自动分配的范围。
- 登录路由器后台,找到“DHCP服务器”设置，查看地址池的起始和结束地址，多数家用路由的池子是从
168.1.100到168.1.200。 - 手动给虚拟机分配的IP建议放在池子范围之外,比如
168.1.50，这样路由器不会把这个IP再分配给其他设备，从根源上避免冲突。 - 如果虚拟机必须留在DHCP池范围内,那就去路由器后台给虚拟机做“保留地址”或“静态DHCP”绑定，把虚拟机的MAC地址和固定IP绑定后，DHCP会优先分配这个IP，不会和其他设备撞车。
VMware网络编辑器里的DHCP池也要检查
物理路由器改完了,别忘了VMware自己还有一套虚拟DHCP，如果虚拟机用NAT模式，虚拟网卡的DHCP池由VMware分配，和物理路由器的池子互不干扰。
- 在VMware“虚拟网络编辑器”里选中VMnet8，点击“DHCP设置”，确认起始IP和结束IP在虚拟子网范围内，比如
168.44.100到168.44.200。 - 如果虚拟机的IP落在物理局域网段（比如
168.1.x），同时物理路由器也分配了相同网段的IP，就会跨网络产生冲突，这种跨段冲突排查难度较大，建议直接重建虚拟网络，把VMnet8恢复到默认设置。
虚拟机DHCP分配正确但上不了网，网关和DNS最常被忽略
IP不冲突、DHCP也正常分配了地址，虚拟机还是上不了网，这时候把注意力转到网关和DNS，这两个配置项出错，症状和IP冲突高度相似，都表现为“能拿到IP但打不开网页”。
网关不通的典型表现
DHCP分配的网关地址必须是虚拟子网内的有效地址,NAT模式下，网关默认是虚拟网卡的子网IP末尾标为“1”的地址，比如168.44.1。
- 在虚拟机里运行
ipconfig，看“默认网关”这一栏，如果网关为空或显示0.0.0，说明DHCP没有下发网关信息，网络请求根本发不出去。 - 手动测试网关连通性：
ping 192.168.44.1，通，说明到物理机的虚拟链路正常；不通，检查物理机防火墙是否拦截了虚拟网卡的数据包，VMware通常在安装时向Windows防火墙注册了放行规则，但部分安全软件会单独拦截虚拟网卡流量。
DNS配置错误的迷惑行为
网关通了、IP也正常，网页就是打不开，但用IP地址能访问网站，问题出在DNS解析，DHCP服务器通常会下发一个DNS地址，但如果这个地址填了路由器的错误IP，或者路由器本身没有正常转发DNS请求，虚拟机就会出现“能聊天、刷不了网页”的奇葩故障。
- 在虚拟机里运行
nslookup www.baidu.com，如果返回“DNS request timed out”，说明DNS服务器不可达。 - 手动把VMware NAT模式下的DNS改为知名公共DNS：
5.5.5（阿里DNS）或29.29.29（腾讯DNSPod），在虚拟机网卡的IPv4属性里，把“自动获得DNS服务器地址”改成“使用下面的DNS服务器地址”，填上公共DNS后重试。
业内专家指出,DHCP机制本身是一个“先租后离”的协议，虚拟机在休眠、挂起、恢复快照等操作后会尝试续租或重新获取地址，客户端状态异常时更容易踩中上述问题链条。
核心排查顺序和日常规避手段
碰到虚拟机DHCP无法上网或IP冲突,不用一遍遍重启路由器，按下面这个顺序排查，效率要高得多。
- 第一步：打开虚拟网络编辑器，确认网络模式是NAT且DHCP服务启用，这是虚拟机自己的“局域网环境”。
- 第二步：检查物理机的防火墙和安全软件，放行VMware相关服务和虚拟网卡流量。
- 第三步：查看虚拟机内网卡是否拿到IP、网关、DNS，三要素缺哪个补哪个。
- 第四步：排查IP冲突源，
arp -a结合路由器后台对比MAC地址。 - 第五步：将虚拟机的关键业务网口改成静态IP，放在DHCP地址池之外，一步到位省心。
日常运维中,给虚拟机做快照或克隆时，建议先关闭网卡再操作，避免因为系统内置的网卡标识变化而触发新的IP分配问题，给虚拟机命名或备注时标记用途和IP分配方式，方便后续排查。
虚拟机DHCP无法上网和IP冲突排查常见问题
Q：虚拟机开机就提示IP冲突，怎么快速定位是哪台设备占用了IP？
A：在虚拟机内打开命令提示符，运行arp -a查看冲突IP对应的MAC地址，然后登录路由器管理后台，在“终端管理”或“DHCP客户端列表”中搜索这个MAC，如果能匹配到设备，就是该设备手动指定了和虚拟机相同的IP，如果路由器列表里没有该MAC，排查局域网内其他交换机、无线AP下的联网设备，例如网络打印机、智能家居网关，这类设备最容易手动占用IP。
Q：DHCP池里的IP地址，手动分配给虚拟机使用，以后会不会和自动分配的设备冲突？
A：大多数情况下会有冲突风险，只要该IP在DHCP地址池范围内，路由器就不会识别它已被手动占用，后续很可能把它自动分配给其他新接入的设备，正确做法是优先给虚拟机分配地址池外的IP，如果网络规模小、设备数量固定，也可以在路由器后台将虚拟机MAC绑定为该IP并保留在池内，路由器会跳过这个地址不再分配给别人。
Q：虚拟机用桥接模式经常掉线，和IP冲突有关系吗？
A：有直接关系，桥接模式下虚拟机直接暴露在物理局域网中，物理路由器会把它当成一台普通终端，如果路由器设置了IP/MAC绑定，而虚拟机的MAC不在白名单内，就会发生“获取到IP后随即被断开”的现象，表现和IP冲突非常相似，建议在路由器后台将虚拟机的MAC地址加入绑定列表，或者放弃桥接、改用NAT模式，NAT模式下虚拟机不占用物理局域网IP资源，反而更加稳定。