VMware桥接模式：虚拟机网卡获取到169.254.x.x (APIPA) 的排查与修复

最近在折腾本地Debian测试环境，给虚拟机添加了第二块网卡并配置为桥接模式，期望它能直接从上级路由器拿到局域网IP和IPv6。结果配置完成后，发现网络根本不通。

故障现象

在VMware设置中，将新增的网卡（网络适配器 2）改成了桥接模式（Bridged）。登录Debian终端执行 ip a 查看网络状态，发现 ens33 (NAT网卡) 正常，但新增的 ens37 网卡却拿到了一段非常诡异的IP地址：169.254.70.46。并且，登录物理路由器后台，完全看不到这台新设备的上线记录。

核心原理分析

看到 169.254.x.x 这个网段，搞网络的同学应该立刻就能反应过来——这是 APIPA (Automatic Private IP Addressing，自动私有IP地址)。

底层逻辑是这样的：
当操作系统（这里是Debian）的网卡接口启动并配置为DHCP模式时，它会在局域网内疯狂发送 DHCP Discover 广播包，大喊“谁来给我分配一个IP？”。如果等待超时后，依然没有任何 DHCP 服务器（比如你的路由器）回应 DHCP Offer，操作系统为了保证最基础的本地链路连通性，就会基于 RFC 3927 标准，给自己随机分配一个 169.254.0.0/16 网段的备用地址。

既然局域网里有路由器，为什么虚拟机广播不出去？
问题出在 VMware 的虚拟网络编辑器上。默认情况下，VMware 的 VMnet0（桥接网络）配置是 Automatic（自动）。

“自动”听起来很智能，但实际上是个坑。现代开发者的宿主机（Windows）上通常挂满各种网卡：除了真实的物理网卡，还有大量的虚拟网卡（比如VPN客户端、ZeroTier、Tailscale、甚至拔掉网线的以太网口）。VMware 的自动桥接逻辑很容易“瞎了眼”，把虚拟机的流量桥接到一个根本没连接路由器的死网卡上，导致 DHCP 广播包直接进了黑洞。

解决方式：抛弃自动，手动绑死

明确了流量进了黑洞，解决思路就是强制指定桥接出口。

1. 确认物理宿主机的真实出网网卡

首先在Windows宿主机上，打开“网络连接”面板（或运行 ncpa.cpl），看一眼到底是谁在负责真正的物理通信。从截图中可以看到，有很多虚拟网卡和未连接的适配器。找到你当前真正联网的那块物理网卡名称。

2. 修改虚拟网络编辑器

打开 VMware，点击菜单栏的 编辑 -> 虚拟网络编辑器。

注意：如果界面上的选项是灰色的，必须先点击右下角的 Change Settings (更改设置) 获取管理员权限。

选中 VMnet0，将下方的桥接模式从自动改为具体的物理网卡：

• Bridged to: Automatic (桥接至：自动分配 -> 引发本次故障的默认配置)
• 修改为 -> Bridged to: [你的真实物理网卡名称] (桥接至：指定网卡 -> 强制将流量从该真实物理通道打出)

保存并应用。

3. 在虚拟机中重新请求DHCP

回到 Debian 虚拟机的终端（无需重启机器），手动释放旧的无效IP，并重新发起DHCP请求：

# Release current lease (手动释放当前无效的 169.254 地址租约)
dhclient -r ens37

# Obtain new lease (触发网卡重新向真实的路由器申请 DHCP 地址)
dhclient ens37

最后，再次执行网络状态检查命令：

ip a show ens37

可以看到，ens37 已经成功获取到了 192.168.0.102 这个标准的内网IP，同时也能顺理成章地拿到公网 IPv6 地址。路由器后台也正常出现了这台设备的在线记录。

总结

在涉及虚拟机桥接网络的场景中，永远不要信任 Hypervisor 的“自动选择”逻辑。手动将桥接网络与宿主机的真实物理网卡进行硬绑定，是排查 169.254 APIPA 疑难杂症的第一准则。