脑袋被门夹得好痛如果你在VMware里装好Ubuntu，兴冲冲打开终端准备开始折腾，结果输入 ip addr 一看，ens33下面光秃秃的，只有 state DOWN 或者压根没显示 inet 字段，第一反应基本都是：网卡废了？还是系统坏了？这个问题在VMware + Ubuntu的组合里出现频率极高，几乎每个玩虚拟化的人都至少撞见过一次。
先说结论：ens33没有IP，绝大多数情况不是网卡硬件坏了，也不是Ubuntu系统装坏了，而是虚拟网络链路里某个环节没就位。 这个“某个环节”可能发生在VMware宿主机侧的虚拟网络服务、虚拟机的网卡连接状态、虚拟机内部的网络管理后端、DHCP客户端进程这几个层面中的任意一个。麻烦之处在于，这几个环节是串联的，任何一个掉链子，最终表现都一模一样——ens33上没有任何IPv4地址。
这篇文章会把这个问题从头到尾拆一遍：先讲清IP是怎么一步步分配到ens33上的，再给你一条从宿主机到虚拟机内部的完整排查路径，最后给出六个可以直接照抄的解决办法，以及后续怎么配置才能让这个坑不再反复出现。适合VMware Workstation Pro用户、Ubuntu 18.04及以上版本的系统管理员，以及所有被虚拟网卡折磨过的运维和开发者。
1. 从ens33这个名字说起：IP分配到底走了一条什么链路
1.1 ens33不是随便叫的，它代表了虚拟机的第二块PCI网卡
在老的Linux系统里，网卡叫 eth0、eth1，这是内核按探测顺序命名的。但从systemd和udev的预测性命名规则（Predictable Network Interface Names）普及之后，网卡名开始反映硬件物理位置。ens33 这个名字拆开看：en 表示以太网，s 表示热插拔PCIe插槽，33 是PCI总线上的槽位号。
在VMware Workstation里，这个33对应的就是虚拟机主板上虚拟PCI设备的一个槽位号。这也是为什么你在“虚拟机设置 → 网络适配器”里移除一块网卡再加一块新的，重启后网卡名可能变成 ens34、ens37 之类的——因为新设备挂到的PCI槽位变了，udev的名字自然跟着变。
了解这个命名规则有什么用？很重要。很多“ens33没有IP”的问题，底层其实是“网卡设备节点变了”或者“udev规则里还在按老名字绑定配置”，导致Netplan配置里的 ens33 对不上实际存在的网卡名。后面聊解决办法时会专门展开。
1.2 从VMware到ens33的完整IP分配链路
一个正常工作的Ubuntu虚拟机，要拿到IP，需要整条链路全部通畅：
code复制VMware虚拟网络服务（NAT/DHCP）
↓
虚拟机网络适配器（已连接、模式正确）
↓
Guest OS内核识别网卡驱动（vmxnet3/e1000等）
↓
udev按PCI槽位命名（ens33）
↓
网络管理后端接管（Netplan/systemd-networkd 或 NetworkManager）
↓
DHCP客户端发起广播请求
↓
VMware内置DHCP服务响应，下发IP
这条链路上任何一环出问题，最终都表现为 ip addr 里 inet 字段为空。但注意，不同环节出问题，修复方式差异极大：如果宿主机DHCP服务没起来，你在虚拟机里把网络配置翻个底朝天也没用；如果Netplan配置写的接口名和实际接口不对应，你重启十次网络服务也没用。
1.3 VMware + Ubuntu为什么是“重灾区”
相比之下，CentOS/RHEL系的NetworkManager体系相对稳定，Windows Guest基本无感，Ubuntu却特别容易出这个问题，原因是它搞了个双层抽象：Netplan负责在 yaml 配置文件里描述网络拓扑，然后选择后端渲染成systemd-networkd的配置或NetworkManager的配置。抽象层越多，出问题的组合就越多，比如：
- Netplan配置里
dhcp4: false却没有任何address字段 - Netplan的renderer是networkd，但实际接管网卡的却是NetworkManager，两边互相踩
- 系统升级或快照回滚后，Netplan配置和当前实际网卡名不同步
- VMware挂起/恢复后，DHCP租约过期但客户端没有重新续约
这些情况我都实际遇到过，下面逐个给解决方案。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 有序排查：从宿主机服务到虚拟机内部的完整检查清单
2.1 宿主机侧：VMware的两个网络服务常被低估
很多人习惯一上来就进虚拟机改配置，但我的经验是第一步先在宿主机确认两个Windows服务是否正常运行。VMware Workstation安装后，会在Windows服务里注册以下两个关键服务：
| 服务名 | 显示名称 | 作用 |
|---|---|---|
| VMware NAT Service | VMware NAT Service | 负责NAT模式的IP转发、子网通信 |
| VMware DHCP Service | VMware DHCP Service | 负责给NAT/仅主机模式的虚拟机动态分配IP |
在Windows里按 Win + R 输入 services.msc，找到这两个服务，确认状态是“正在运行”，启动类型是“自动”。如果其中任何一个停了，虚拟机的NAT网络绝对起不来，表现就是ens33没有IP，甚至可能连 link up 都做不到。如果服务处于停止状态，直接右键启动，再回到虚拟机看一眼，很多时候问题当场就解决了。
另外一个常见的坑：VMware的虚拟网络服务被安全软件或“系统优化”工具禁用。 有些管家类软件会把VMware的服务识别成不常用服务，默认改成“手动”甚至“禁用”，下次开机虚拟机网络就挂了。排查时顺便看一眼启动类型，别让它在后台埋雷。
2.2 虚拟机内部第一波命令：快速定位故障层
在确认宿主机服务正常后，进入虚拟机，按下面这个顺序依次执行命令，每一条都有明确的判断意义。
bash复制# 1. 查看网卡链路状态和IP
ip addr show ens33
如果显示 state DOWN，说明网卡链路层都没起来，先执行：
bash复制sudo ip link set ens33 up
再执行 ip addr show ens33。如果 state UNKNOWN 或 UP 但依然没有 inet，说明链路层OK，问题在网络层。
bash复制# 2. 看路由表
ip route show
有IP的前提下看默认路由是否存在，如果没有默认路由，下一步检查DHCP和网关配置。
bash复制# 3. 检查网络管理服务的运行状态
systemctl status systemd-networkd
systemctl status NetworkManager
这一步非常关键。Ubuntu里这两个服务可能同时存在，但同一块网卡只能由其中一方管理。如果两个服务都在争抢，或者相反，都没有真正接管ens33，那DHCP客户端根本不会启动。
bash复制# 4. 尝试手动获取DHCP地址
sudo dhclient ens33 -v
执行后观察输出，如果能拿到 DHCPACK 且 ip addr 里出现IP，说明DHCP链路本身是通的，问题在自动启动环节；如果卡住或报错，说明DHCP服务端或虚拟网络链路有问题。
2.3 进阶排查：看日志和DHCP过程
如果上面的命令都没定位出问题，就要看日志了。我常用的几个日志检查点：
bash复制# 内核日志里有没有网卡驱动报错
dmesg | grep -i ens33
dmesg | grep -i vmxnet
# DHCP客户端相关日志
journalctl -u systemd-networkd | tail -50
journalctl -u NetworkManager | tail -50
# 查看有没有DHCP租约文件生成
sudo cat /var/lib/dhcp/dhclient.ens33.leases 2>/dev/null
dmesg 里如果出现 bar: can't reserve、failed to enable 之类的关键字，大概率是VMware Tools驱动或内核模块的问题；如果 journalctl 里出现 No DHCPOFFERS received，说明DHCP请求发出去但没人响应，问题指向宿主机侧的DHCP服务或虚拟网络隔离配置；如果出现 Carrier is off，说明虚拟网线没插上，去VMware里检查网卡连接状态。
还有一类情况值得单独提醒：检查虚拟机的“网络适配器”是否勾选了“已连接”和“启动时连接”。 有些时候，VMware的快照或模板在传输过程中把这两个选项取消了，或者你自己在调设备时手动拔掉了“网线”，虚拟机内部看链路就是断的。在虚拟机设置里把这两个勾选补上，等于重新插拔了一次虚拟网线，很多莫名其妙的问题就好了。
3. 六种实打实的解决办法，总有一款能救回来
3.1 方案一：手动拉起DHCP，先治标再治本
这是速度最快、操作最简单的手段，适合你正在赶工、没时间深究原因的紧急场景：
bash复制sudo pkill dhclient
sudo rm -f /var/lib/dhcp/dhclient.ens33.leases
sudo dhclient ens33 -v
先杀掉可能存在的旧DHCP客户端进程，删掉可能已损坏或过期的租约文件，再重新发起。这样做的本质是强制ens33重新走一遍DHCP流程。如果执行完能看到 DHCPACK，ip addr 里出现 inet 192.168.x.x/24，网络就恢复了。
但这个方案只解决眼前问题，重启虚拟机后大概率还会复发。 所以在网络恢复后，必须继续往下排查，搞清楚为什么DHCP客户端没有自动跑起来。千万别觉得“好了就万事大吉”，过两天开机又得折腾一轮。
3.2 方案二：修复Netplan配置，这是Ubuntu网络的总开关
Ubuntu 18.04开始，默认用Netplan管理网络，配置文件在 /etc/netplan/ 目录下，一般是 00-installer-config.yaml 或 01-network-manager-all.yaml。先打开看内容：
bash复制sudo cat /etc/netplan/*.yaml
常见的问题配置长这样：
yaml复制network:
version: 2
ethernets:
ens33:
dhcp4: false
dhcp4 写成了 false，但没有配置任何静态IP，这种配置下发后网卡当然不会有地址。把它改成：
yaml复制network:
version: 2
ethernets:
ens33:
dhcp4: true
然后执行：
bash复制sudo netplan apply
netplan apply 会重新渲染并应用网络配置。注意，如果你是通过SSH远程连接的虚拟机，执行这个命令时网络会瞬断一下，然后恢复，这是正常现象。
如果 netplan apply 报错，先用 sudo netplan try 做一次带超时的预演，它会在十秒内等你确认，超时自动回滚，避免把网络彻底改挂：
bash复制sudo netplan try
3.3 方案三：用NetworkManager接管网卡，避开双管理后端打架
Ubuntu桌面版默认用NetworkManager，Ubuntu Server默认用systemd-networkd，但很多人会手动安装桌面环境或者折腾过网络管理包，导致两个后端同时存在。Netplan里的 renderer 字段决定最终用谁：
yaml复制network:
version: 2
renderer: NetworkManager
ethernets:
ens33:
dhcp4: true
如果这里写的是 networkd，但你的图形界面里用的是nm-connection-editor，两边就可能互相覆盖。我在排查中见过最典型的现象：ip addr 没有IP，但 nmcli device status 显示ens33是 unmanaged（不受管）。
这种情况处理起来分两步。先确认NetworkManager是否安装并启用：
bash复制sudo apt update
sudo apt install network-manager -y
sudo systemctl enable NetworkManager
sudo systemctl start NetworkManager
再把ens33设为受管状态：
bash复制sudo nmcli device set ens33 managed yes
sudo nmcli device reapply ens33
sudo nmcli device connect ens33
nmcli device reapply 会尝试按当前connection配置重新应用；nmcli device connect 则是强制让NetworkManager接管这块网卡的连接。这两条命令执行完，nmcli device status 里ens33的状态应该变成 connected。
如果这里发现NetworkManager的connection里根本没有ens33的记录，可以手动建一条：
bash复制sudo nmcli connection add type ethernet con-name "ens33-static" ifname ens33 ipv4.method auto autoconnect yes
sudo nmcli connection up "ens33-static"
autoconnect yes 表示开机自动连接，比在 /etc/network/interfaces 里写配置对Ubuntu 18.04+更友好。
3.4 方案四：从VMware虚拟网络编辑器重建DHCP/NAT，对付看不到摸不着的虚拟网络部件
如果虚拟机内所有配置看起来都正常，服务也都在跑，但就是收不到DHCP响应，问题很可能出在VMware一侧的虚拟DHCP服务上。打开菜单栏“编辑 → 虚拟网络编辑器”，重点关注VMnet8（NAT模式对应的虚拟交换机）。
在里面检查三件事：
- VMnet8的DHCP设置是否开启了。选中VMnet8，点击“DHCP设置”，确认“启用DHCP服务器”已勾选，记录一下起始和结束IP地址段，比如
192.168.8.128 ~ 192.168.8.254。 - NAT网关地址是否和虚拟机内配置的网关一致。点击“NAT设置”，默认网关通常是
192.168.8.2，这个地址就是虚拟机内ip route看到的default via。 - 如果配置看起来很乱，或者怀疑被其他软件改过，直接点“恢复默认设置”，VMware会把VMnet1、VMnet8等网络全部重建，但重建后NAT和DHCP的IP段可能会变，虚拟机里的静态配置需要同步调整。
改完配置后，务必先关闭虚拟机（不是挂起），再执行恢复默认设置或应用变更。为什么？因为VMware在虚拟机运行状态下对虚拟网络的修改，有些不会立即生效，只有停止运行时调整才最干净。
3.5 方案五：移除并重新添加网卡，这是对付“改名”和“漂移”的终极手段
前面说过，udev的预测性命名和PCI槽位绑定。如果虚拟机在克隆、快照回滚、硬件调整后，网卡名从 ens33 变到了 ens34，而Netplan配置里还在写 ens33，那就完全对不上。这种时候，与其在配置文件里反复改名字，不如直接在VMware里把网卡“拔掉”再重新插一块。
具体操作：
- 关闭虚拟机。
- 右键虚拟机 → 设置 → 网络适配器。
- 选中当前网络适配器，先“移除”。
- 点击“添加” → “网络适配器”，重新添加一块，网络连接方式选择NAT。
- 确认勾选“启动时连接”，点击确定，开机。
这种操作的本质是给网卡换了一个新的PCI槽位和新的MAC地址（默认VMware会重新生成MAC），udev会按新硬件重新命名。开机后，你用 ip addr 看一下新的接口名（可能是ens34、ens36等），然后同步修改Netplan配置文件里的接口名即可。
注意：如果新网卡名变了，旧名字对应的Netplan配置就不会生效。改完配置后执行 sudo netplan apply，检查是否拿到了IP。
3.6 方案六：直接配静态IP，一劳永逸但要注意网关和DNS
如果上面的动态分配方案都被你折腾了一遍，或者这个虚拟机就是当服务器用的，强烈建议直接配静态IP，彻底摆脱DHCP依赖。修改Netplan配置：
yaml复制network:
version: 2
renderer: networkd
ethernets:
ens33:
dhcp4: no
addresses:
- 192.168.8.200/24
routes:
- to: default
via: 192.168.8.2
nameservers:
addresses:
- 8.8.8.8
- 114.114.114.114
# 可选：DHCP4为no后，MTU一般默认1500，VMware下不用改
注意这里 addresses 里的IP必须落在VMnet8 DHCP地址池的同一子网内，且不能和DHCP自动分配段冲突。routes 里的网关必须是VMware NAT设置的默认网关，一般是 192.168.x.2，具体值以你在虚拟网络编辑器里NAT设置看到的为准。
配好后：
bash复制sudo netplan apply
验证：
bash复制ip addr show ens33
ip route show
ping -c 3 8.8.8.8
还有一个细节容易忽略：静态IP配好后，DNS掩码和网关都要配齐全，否则能ping通网关但解析不了域名。 建议最少配两个DNS，避免单个DNS故障导致域名解析全挂。
4. 从原理层面理解ens33为什么这么容易“蒸发”
4.1 预测性命名规则：虚拟机的PCI设备变动比物理机更频繁
在纯物理机上，网卡焊在主板上，PCI槽位相对固定，所以 ens33 这个名字通常很稳定。但在VMware里，虚拟机的硬件配置是“可插拔”的，你可以随时添加、移除、修改网络适配器，每一次改动都可能改变PCI槽位分配。这就决定了虚拟机的网卡名天然比物理机更容易漂移。
如果你做过这几种操作之一，网卡名改变的概率非常高：克隆虚拟机、从模板部署、在vCenter里迁移、手动调整设备顺序、添加新的PCI设备（比如USB控制器）。而一旦名字变了，旧配置文件里的 ens33 就只剩空壳。所以，排查时如果发现 ip addr 里根本没有ens33，而是出现了ens34、ens35之类的陌生名字，先别急着找问题——网卡已经改名了，把配置文件同步一下才是正道。
4.2 Netplan + systemd-networkd 与 NetworkManager 的“双后端纠葛”
Ubuntu网络管理架构的特殊性在于，Netplan本身不直接管理网络，它只是配置翻译器。它读取 /etc/netplan/*.yaml，然后根据 renderer 字段生成底层的systemd-networkd或NetworkManager配置。
这个设计的初衷是统一不同桌面/服务器环境下的网络配置入口，但也带来了一个副作用：一旦renderer和实际接管后端的进程不一致，就会出现“配置写了但没生效”的诡异现象。比如：
renderer: networkd，但systemd-networkd服务没启用- Netplan配置里写了ens33，但实际NetworkManager已经接管了ens33且被设为unmanaged
- 手动改过
/etc/NetworkManager/system-connections/下的连接文件，和Netplan配置相互覆盖
我的建议是：在Ubuntu虚拟机里别同时折腾两套网络管理工具。 桌面版就统一用NetworkManager，Server版就统一用systemd-networkd，用Netplan做唯一入口。除非你非常清楚自己在干什么，否则不要手动去改networkd或NetworkManager那层生成的配置文件。
4.3 VMware NAT模式下的DHCP过程：为什么恢复快照或挂起后IP会消失
VMware Workstation的NAT模式结构并不复杂，但很多人不熟悉它的“微服务式”架构。VMnet8是NAT模式的虚拟交换机，宿主机上运行着一个独立的NAT服务进程和一个DHCP服务进程。当虚拟机内的DHCP客户端广播请求时，虚拟交换机会把这个广播转发给VMware DHCP Service进程，进程分配IP后再通过vmnet8网段发回给虚拟机。
这整套机制在VMware正常运行时是稳定可靠的，但有两个场景容易出问题：
场景一：Windows睡眠/休眠后唤醒。 宿主机休眠时，VMware的服务进程也可能被挂起，虚拟机的DHCP租约可能到期或半失效。唤醒后如果虚拟机的DHCP客户端没有主动重新发起请求，而宿主机DHCP服务进程还没有完全恢复监听，就会出现一段时间内ens33拿不到IP。
场景二：虚拟机挂起后恢复。 VMmare的“挂起”本质是把虚拟机内存冻结，网络连接也一并冻结。恢复时，虚拟机的网络堆栈重新激活，但DHCP租约时间在“冻结”期间已经流失了一部分，如果租约刚好过期，就会触发重新获取流程。正常来讲，重新获取是自动的，但偶尔会因为时序问题失败。
遇到这种情况，最快的方法就是方案一里的 sudo dhclient ens33 -v 强制续期。如果想尽量避免，建议在“虚拟机设置 → 选项”里，把“电源管理”相关选项设置为“从不”或“允许连接到已挂起的虚拟机”，减少这种频率。
5. 配置固化与避坑指南：让这个坑彻底不再出现
5.1 静态IP配置的完整示例与开机自启检查
如果你决定长期用静态IP，除了写Netplan配置，还要顺手确认两件事：
- 确认netplan配置文件的权限。 Netplan对权限敏感，文件权限必须是600或644，属主root:root，否则
netplan apply会拒绝加载。
bash复制sudo chmod 600 /etc/netplan/*.yaml
sudo chown root:root /etc/netplan/*.yaml
- 确认systemd-networkd开机自启。 如果你用的是networkd渲染，执行：
bash复制sudo systemctl enable systemd-networkd
sudo systemctl start systemd-networkd
如果是NetworkManager渲染，确认：
bash复制sudo systemctl enable NetworkManager
- 重启虚拟机做一次完全验证。 配置完静态IP后，重启一下虚拟机，看看开机后网络是否自动恢复。这一步非常关键，很多配置看似生效，但重启后又回到没IP的状态，说明某个服务没起来或配置顺序有问题。
5.2 克隆虚拟机之后，这步必做
VMware里克隆虚拟机是高频操作，但很多人克隆完就开机，结果发现网卡没有IP，或者网络根本不通。原因是克隆后的新虚拟机保留了源虚拟机的MAC地址和网卡配置，新系统里的udev或Netplan配置还在按旧硬件绑定。
克隆开机后，建议执行以下收尾操作：
bash复制# 删除可能存在的旧网络接口绑定规则
sudo rm -f /etc/udev/rules.d/70-persistent-net.rules
# 重启systemd-udevd触发重新枚举
sudo systemctl restart systemd-udevd
# 查看新的网卡名
ip addr
然后再按新网卡名修改Netplan配置。如果VMware里克隆时选择了“重新生成MAC地址”，那MAC本身已经变了，问题会少一些；如果没选，就手动在虚拟机设置里点击“高级 → MAC 地址 → 生成”更新一次。
5.3 我踩过最阴的坑：VMware Tools驱动版本与内核不匹配
最后分享一个平时不容易注意到的坑。早期我给Ubuntu虚拟机装老版本的VMware Tools（比如VMware自带的老旧 open-vm-tools 包），后来Ubuntu升级内核后，vmxnet3模块编译或加载失败，eth0/ens33 直接消失或状态异常。现象非常迷惑：ip addr 里没有ens33，lspci 却显示网卡设备存在，dmesg里报 Failed to load vmxnet3。
排查思路是：
bash复制# 确认网卡在PCI总线上是否可见
lspci | grep -i ethernet
# 检查内核模块是否加载
lsmod | grep vmxnet
# 查看具体报错
dmesg | grep -i vmxnet
如果发现模块加载失败，先升级内核，再重装 open-vm-tools：
bash复制sudo apt update
sudo apt install open-vm-tools open-vm-tools-desktop -y
sudo reboot
现在的VMware Workstation对 open-vm-tools 的支持已经很成熟，不建议再安装那种老式的 VMwareTools-*.tar.gz，除非你用的VMware版本和内核都特别老。开源版工具能更好地跟上Ubuntu内核更新节奏。
6. 排障心法：把“没有IP”当做一个入口而非终点
整篇文章看下来你会发现，ens33没有IP这个现象，其实是一个“症状”，它背后可能是十个不同层次的病因。如果一上来就猛改配置文件，反而容易把问题搞复杂。经过这么多次踩坑，我现在的排障顺序已经固定成一条流水线：先在宿主机查VMware服务 → 再进虚拟机看网卡链路状态和驱动 → 看Netplan配置和网络管理后端 → 手动触发DHCP → 实在不行看Dmesg和Journal日志 → 最后才考虑重建网卡或改静态IP。
按这个顺序走，绝大多数问题能在前两步解决。真正顽固的场景，大多是网卡名漂移和双后端冲突，这两类问题靠“移除网卡重新添加”和“统一渲染后端”就能根治。
顺带说一个很实用的小技巧：改任何网络配置之前，先在VMware里拍个快照。 这样哪怕你把网络配置改到彻底失联，也能一键回滚到正常状态，省去重装系统的痛苦。操作方式是虚拟机开着也能拍快照，拍完再动手改配置，任何一步想反悔都能无损恢复。
以上这套流程，在VMware Workstation 15/16/17配合Ubuntu 18.04、20.04、22.04上都验证过，遇到同类问题基本都能套用。如果你用的是ESXi或vSphere，底层逻辑类似，只是虚拟交换机和端口组的位置不一样，排查思路可以平移。