【踩坑】HyperV桥接模式下Ubuntu24.02虚拟机固定IP设置

背景

本人昨天已经在HyperV管理器上创建了一台Ubuntu24.02版本的虚拟机，为该虚拟机配置的是外部虚拟交换机（桥接模式），并且已经为该虚拟机配置好了SSH连接。

今天我使用自己的宿主机去连Ubuntu虚拟机的SSH，发现连不上了，从虚拟机进入发现的IP变了。所以我就开始为虚拟机设置固定IP，故事由此展开........

过程

前提：具备计网基础知识，下面可以选择复习（可选）

要想搞明白不同子网里的计算机是如何通信的，请复习网络的知识：

https://mp.weixin.qq.com/s/N8a-YcCoVmXNrDWjnaxuJg

思考：我在看完上文后，有一个疑问点作者没说清楚。疑问如下：

如果是A（192.168.0.1）向C（192.168.1.1）发送数据的话，到达路由器1后会通过检查路由表，比如：192.168.1.xxx 这个子网下的，都转发到 1 号端口，所以能直接送到交换机2。

但是如果换成A向E（192.168.2.1）发送数据的话，到达路由器1后会通过检查路由表发现不在任何一个子网范围，由于路由器1必须经过路由器2才能到达192.168.2.xxx的子网。请问在文中的步骤5中：

路由表中的下一跳的地址 192.168.100.5是如何来的？

为什么路由器1知道目标E在下一跳的地址192.168.100.5中呢？（如果有很多个下一跳）

上图是一个跨网段数据包转发（三层路由转发） 的全过程，"IP 地址在传输过程中保持不变（除非有 NAT），而 MAC 地址在每一跳都会改变"，这是网络通信中最核心、也是初学者最容易搞混的概念。

【解答】

这是一个非常深刻且直击网络核心的问题！你问到了点子上：路由器如何知道"看不见"的网络在哪里？

路由器 1 直连了 192.168.0.0/24、192.168.1.0/24 和 192.168.100.0/24（中间那根线），所以它天生知道这三个地方怎么走。

但是，192.168.2.0/24（目标 E 所在的网段）并不在路由器 1 的直连范围内，它对于路由器 1 来说是"盲区"。

路由器 1 之所以知道"要去 192.168.2.x，下一跳是 192.168.100.5"，只有三种可能的原因。 这就是路由表条目的来源：

1. 静态路由（Static Routing）：管理员手动告诉它的

这是最常见、最容易理解的方式。网络管理员（也就是你）登录到路由器 1 的后台，手动敲入了一条指令。

• 指令逻辑是这样的：

  "嘿，路由器 1，如果你收到任何要去 192.168.2.0/24 这个网段的数据包，请把它扔给 192.168.100.5（即路由器 2 的左侧接口）。"

• 在 Linux 或路由器上的命令长这样：

  ip route add 192.168.2.0/24 via 192.168.100.5

• 结果： 路由器 1 的路由表里就会生成你看到的那条规则。

2. 动态路由协议（Dynamic Routing）：路由器之间"聊出来的"

在大型网络中，管理员不可能手动配置每一条路。这时候会运行路由协议（如 OSPF , RIP , BGP）。

• 过程描述：

  1. 路由器 2 知道自己直连着 192.168.2.0/24。

  2. 路由器 2 通过中间的网线向 路由器 1 发送广播："大家好，我是路由器 2，我手里掌管着 192.168.2.0/24 这个网段，谁想去那里可以找我。"

  3. 路由器 1 收到这个消息后，自动在自己的路由表中添加一条记录："哦，要去 192.168.2.x 找路由器 2（192.168.100.5）就行了。"

3. 默认路由（Default Route）：不知道去哪的都往这扔

还有一种"偷懒"的情况。路由器 1 可能根本不知道 E 具体在哪里，但它配置了一条"默认路由"（0.0.0.0/0）。

• 指令逻辑：

  "不管目标 IP 是多少，只要是你（路由器 1）不认识的网段，统统扔给 192.168.100.5 处理。"

• 结果： 数据包也会被转发给路由器 2。

---

关键点解析：为什么下一跳必须是 192.168.100.5？

你可能会问，为什么下一跳地址填的是 192.168.100.5，而不是 192.168.100.4 或者别的？

这是因为"下一跳"必须是路由器 1 "直接能喊应"的人。

1. 路由器 1 和 路由器 2 通过中间那根蓝色的线连接，这根线也是一个局域网（子网 192.168.100.0/24）。

2. 在这根线上，路由器 1 的接口 IP 是 192.168.100.4（它自己）。

3. 路由器 2 的接口 IP 是 192.168.100.5（它的邻居）。

4. 所以，路由器 1 必须把包递给同一个网段里的邻居 192.168.100.5，它才能接力传下去。

总结

在步骤 5 中，路由器 1 之所以知道要把包给 192.168.100.5，是因为：路由表中存在一条明确的记录（Destination: 192.168.2.0/24 -> Next Hop: 192.168.100.5）。

这条记录不是天生的 ，而是你（管理员）配进去的 ，或者通过路由协议学来的。

一.首先，需要我们来了解一下HyperV虚拟机的几种常见的网络配置

我们先看第一种模式，也是hyper-v的默认模式 default switch，又称内部网络，在其他虚拟机中叫做NAT网络

典型家庭网络

我们先看一个典型的家庭网络，路由器作为网关连接互联网，并且为局域网设备分配局域网IP地址，比如我的电脑分配了192.168.31.1，两个手机分配了192.168.31.2，192.168.31.3的局域网地址。

Default switch/内部网络/NAT

好我们在宿主机上创建三个虚拟机，在hyper-v默认配置也就是内部网络下，可以看到三个虚拟机又组成了一个新的次级局域网，各自分配了三个IP 172.26.11.1，.2 .3 。这个次级局域网的网段是172开头的，与宿主机的主局域网IP规则是不一样的。此时宿主机充当了次级局域网的路由器。

在这种模式下 虚拟机之间是可以ping通，虚拟机跟宿主机也可以ping通，虚拟机也可以连接互联网，虚拟机可以ping通主局域网的其他设备，但是唯一不可以的是主局域网的其他设备不能ping通虚拟机。 道理也很简单，主局域网现在相当于是虚拟机外网了，外网设备是不能ping通局域网IP的。

专用网络

我们看第二种模式，专用网络 其他虚拟机称为Host only, 这种模式就更简单了，直接抹掉下面的所有内容，形成一个虚拟机的专用网络，只供虚拟机之间的连接，此种模式下切断了与宿主机的联系，当然也不能连接互联网。

外部网络/桥接

第三种模式是外部网络，其他虚拟机称为 bridge 或 桥接，这种模式下相当于把虚拟机也放到了主局域网中，享有与主局域网中其他设备同样的ip地址分配规则，此时虚拟机与宿主机的网络地位是对等的。所以在这个模式下所有设备都可以互相ping通了。

参考文档：

1.Hyper-V 虚拟机的两种外网连接方式（网桥式与共享式）

https://blog.csdn.net/qq_16051405/article/details/121122368

---

二.选择自己虚拟交换机模式下对应的固定IP配置方式

明白了外部网络/桥接 这种网络配置后，桥接的好处： 网络极其稳定，且局域网内的其他机器也能直接 SSH 连入你的虚拟机，方便你进行后续的集群测试。

接下来我们进行固定IP配置。

首先要先明白两点：

1、NAT网络（HyperV的默认网络/内部网络）、桥接模式（HyperV的外部网络）配置固定IP是不一样的，要先确定自己选的哪种虚拟交换机。

2、就算都是桥接模式，但在CentOS里配置固定ip和Ubuntu里配置固定ip操作还是不一样。

所以，本文针对的情况是**：HyperV桥接模式下的Ubuntu22.04虚拟机配置固定ip**

我又参考了以下文档：

1.Ubuntu22+设置静态IP

https://ken.io/note/ubuntu22-ip-static-configuration

2.Ubuntu桥接模式设置静态IP

https://blog.csdn.net/Xiaoyuan_he/article/details/144136952

于是我的Ubuntu的网卡配置文件/etc/netplan/50-cloud-init.yaml内容如下：

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:              # 请确保这里是你实际的网卡名称，如 eth0，用 ip addr 查看
      dhcp4: false     # 关闭 DHCP，使用静态 IP
      addresses:
        - 192.168.0.6/24  # 你的虚拟机 IP，保持在 0 网段
      routes:
        - to: default
          via: 192.168.0.1  # 关键！这是你 Windows 截图里的默认网关
      nameservers:
        addresses:
          - 223.5.5.5    # 阿里 DNS
          - 8.8.8.8      # 谷歌 DNS

注意：配置完网络后需要执行sudo netplan apply生效

# 确认网卡名称 （通常是 eth0，但也可能是 enp0s3 等。）

ip addr / ip a

# 验证

ping 192.168.0.1 # 先 ping 网关，通了说明局域网正常

ping 223.5.5.5 # 再 ping 公网 IP，通了说明能上网

在我查文档的时候发现，很多文档对于网关的配置会使用gateway4的语法格式。

注意： Ubuntu 24.04 的 Netplan 版本较高，推荐使用 routes 语法来指定网关，旧版的 gateway4 语法可能会被标记为过时 (deprecated)。

我配置完这个文件之后，很奇葩的事情发生了。。。。

我在执行conda命令下载东西时报错了，**报错信息:**Failed to resolve 'mirrors.tuna.tsinghua.edu.cn' ([Errno -3] Temporary failure in name resolution)")': /anaconda/pkgs/r/terms.json

这是DNS 解析故障， 原因是Ubuntu虚拟机解析不了mirrors.tuna.tsinghua.edu.cn 这个域名，翻译不成IP 地址。

1.我直接 ping 223.5.5.5 测试了网络连通性，确认是"完全没网"还是仅仅"DNS 坏了"。

(注：223.5.5.5 是阿里云的公共 DNS，在国内测试连通性比较准确)

如果 Ping IP 通了，说明我的网络物理链路是通的，只是虚拟机不知道去哪里问路（DNS配置缺失）。 解决方案： 手动配置 DNS就行了。

配置 DNS步骤

1.修改配置文件：/etc/resolv.conf

2.将里面的内容清空或注释掉，加入以下两行：

nameserver 223.5.5.5

nameserver 8.8.8.8

结果没ping通，（显示 Network is unreachable 或 100% packet loss） 说明虚拟机根本没连上网。

结论： 我的虚拟机根本没连上网，网卡可能没有获取到 IP，或者路由不通。这是 Hyper-V 虚拟交换机 的问题。

于是，我尝试了以下解决方案：

1.检查 IP 获取情况： 输入 ip addr。

• 如果 eth0 下面没有 inet 172.x.x.x 或 192.x.x.x 的地址，说明 DHCP 失败。

**检查路由表：**输入ip route show

• 正常情况： 第一行应该是 default via <网关IP> dev eth0。

• 异常情况： 如果没有 default 路由，或者网关 IP 和你的 IP 不在同一个网段，说明是静态 IP 冲突了。

2.尝试手动获取 IP：

sudo dhclient -v -r   # 释放 IP
sudo dhclient -v      # 重新获取 IP

看是否能获取到 IP。

前提： 确保你的 /etc/netplan/ 配置文件里写的是 dhcp4: true，而不是静态 IP。

3.重置虚拟网卡连接： 比如：Hyper-V 的 "虚拟交换机" 经常会在宿主机网络切换（比如你从 WiFi 换到网线，或者休眠唤醒）后失效。

• 操作： 在 Hyper-V 管理器中，把这个虚拟机关机 -> 在宿主机重启 Hyper-V 服务（或者直接重启电脑） -> 再开机。

• 或者： 在虚拟机设置里，把网络适配器先断开（改为"未连接"），应用，再重新选回应用。

结果：都不行！！！

• 1.网卡没有获取到 IP
• 2.尝试手动获取 IP也失败
• 3.重启 Hyper-V 服务也不行

Ping 223.5.5.5（阿里云的公共 DNS）不通，本来我以为这是一个简单的网络层故障（Layer 3 故障） 。以为这通常是 Hyper-V 的 (虚拟交换机) 在宿主机网络环境变化后（如重启、休眠、切换WiFi）出现的路由表失效或 NAT 故障。

重述一下，我的虚拟机是Ubuntu24.04版本的，使用的是HyperV桥接模式的虚拟交换机配置，

1. 宿主机（Windows）网络环境：

   • IP地址：192.168.0.4

   • 子网掩码：255.255.255.0

   • 默认网关：192.168.0.1

2. 故障现象：

   • 虚拟机 IP 也就是 192.168.0.6，但是 Destination Host Unreachable，这说明缺少网关配置 或者网关配置错误，导致虚拟机不知道如何把数据包发出去。

因为你使用的是桥接模式（External Switch） ，虚拟机的网络配置必须和宿主机在同一个网段 ，且指向同一个物理网关。

ping 192.168.0.1 # 先 ping 网关，通了说明局域网正常

ping 223.5.5.5 # 再 ping 公网 IP，通了说明能上网

结果：

ping 默认网关也没通，报Destination Host Unreachable （目标主机不可达），在配置了静态 IP 的情况下，通常意味着 二层网络（数据链路层）不通。也就是说，你的虚拟机发出的 ARP 请求（询问"谁是 192.168.0.1？"）根本没有得到回应。

核心问题排查：你在用 WiFi 吗？

请确认一下：你的宿主机（Windows 电脑）是通过 WiFi 连接路由器的吗？

• 如果是 WiFi ：Hyper-V 的"外部虚拟交换机（桥接模式）"在 WiFi 下通常是无法工作的。

  • 原因：WiFi 协议（802.11）通常只允许一个 MAC 地址（即你物理网卡的地址）通过验证。当你虚拟机生成一个新的 MAC 地址尝试通过 WiFi 发包时，路由器/AP 会直接丢弃这些包，因为它不认识这个 MAC。

• 如果是插网线：那可能是虚拟交换机选错了物理网卡。

解决方案：回退到"Default Switch"但修复 DNS

既然桥接在 WiFi 下走不通（或者配置极其复杂），而你最开始的问题只是"DNS 解析失败"。

作为运维人员，最稳健 的方案是：使用 Hyper-V 自带的 NAT 模式（Default Switch），但在 Netplan 中强制指定 DNS。 这样既能避开 WiFi 桥接的坑，又能解决解析问题。

请按以下步骤操作，5分钟内解决战斗：

第一步：改回 Hyper-V 设置

1. 关闭 虚拟机。

2. 在 Hyper-V 管理器 中，右键虚拟机 -> 设置。

3. 网络适配器 -> 将虚拟交换机改回 "Default Switch"。

4. 点击确定，启动 虚拟机。

第二步：修改 Netplan (强制 DHCP + 指定 DNS)

开机后，打开终端，再次编辑配置文件：/etc/netplan/50-cloud-init.yaml

将内容完全替换为以下内容（这是针对 NAT 模式的最佳配置）：

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: true           # 开启 DHCP，自动从 Hyper-V 获取 IP
      nameservers:          # 关键：强制覆盖 DNS，不使用 Hyper-V 提供的（经常坏的）DNS
        addresses:
          - 223.5.5.5       # 阿里 DNS
          - 8.8.8.8         # 谷歌 DNS

第三步：应用并验证

1.应用配置：sudo netplan apply

(注：如果报错，可能是缩进问题，YAML 必须用空格缩进)

2.验证网络三连：

• ip addr -> 确认是否拿到了 IP（通常是 172.x.x.x 或 192.168.x.x，不是你刚才设的 192.168.0.6 了）。

• ping 223.5.5.5 -> 测试外网 IP 连通性。

• ping baidu.com -> 测试 DNS 解析。

一顿操作下来，结果截图如下：

截图显示 eth0 网卡只有 IPv6 地址，没有 IPv4 地址 。 这意味着：你的 Netplan 配置虽然写了 dhcp4: true，但 Hyper-V 的 DHCP 服务（Default Switch）"死"了，它没有给你的虚拟机分配 IP。这是 Hyper-V 最著名的 Bug 之一，经常发生在宿主机休眠、重启或网络切换后。

方案一：手动"电击"虚拟网卡（最快尝试）

我们需要在 Hyper-V 层面强制重置连接，并在 Ubuntu 内部手动请求 IP。

1. 宿主机操作（Hyper-V）：

   • 保持虚拟机开机。

   • 打开 Hyper-V 管理器 -> 右键虚拟机 -> 设置。

   • 找到 网络适配器 -> 将"虚拟交换机"下拉改为 "未连接" -> 点击 应用。

   • 等待 2 秒。

   • 将"虚拟交换机"改回 "Default Switch" -> 点击 应用 -> 确定。

2. 虚拟机操作（Ubuntu 终端）： 输入以下命令，强制向 DHCP 服务器吼一声"给我个 IP"：

sudo dhclient -v eth0

• 如果成功： 会显示 bound to 172.x.x.x 或 192.168.x.x。

• 如果卡住不动： 说明 Default Switch 彻底坏了，请执行方案二。

方案二：构建"NAT 内部网络"（最稳健，运维推荐）

既然"Default Switch"不稳定，而"桥接模式"在 WiFi 下又不通，我们来搭建一个手动 NAT 网络 。这是最完美的解决方案，能永久解决你的网络问题。

第一步：创建内部交换机

1. 在 Hyper-V 管理器 右侧，点击 "虚拟交换机管理器"。

2. 选择 "新建虚拟网络交换机" -> 选择 "内部 (Internal)" -> 点击 "创建"。

   • 注意是"内部"，不是"外部"。

3. 名称填：NAT-Switch -> 点击 确定。

第二步：配置 Windows 共享网络 (ICS)

这一步是让这个内部交换机能通过你的 WiFi 上网。

1. 在 Windows 宿主机，按 Win + R，输入 ncpa.cpl 打开网络连接面板。

2. 找到你正在上网的网卡 （比如 Wi-Fi），右键 -> 属性。

3. 点击 "共享 (Sharing)" 选项卡。

4. 勾选 "允许其他网络用户通过此计算机的 Internet 连接来连接"。

5. 在"家庭网络连接"下拉框中，选择 vEthernet (NAT-Switch)。

   • (这是你刚才创建的那个内部交换机对应的虚拟网卡)

6. 点击确定。

   • 此时，Windows 会自动给 vEthernet (NAT-Switch) 分配 IP，通常是 192.168.137.1。请右键该网卡 -> 状态 -> 详细信息确认一下 IP。

第三步：把虚拟机接到这个新交换机

1. 右键 Ubuntu 虚拟机 -> 设置 -> 网络适配器。

2. 虚拟交换机选择你刚建的 NAT-Switch -> 确定。

第四步：配置 Ubuntu 静态 IP

因为 ICS 共享网络的网关通常固定是 192.168.137.1，我们在 Ubuntu 里写死它，这样最稳。

编辑 sudo nano /etc/netplan/50-cloud-init.yaml，填入以下内容（假设 Windows 给 vEthernet 分配的是 192.168.137.1）：

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: false
      addresses:
        - 192.168.137.10/24   # 给虚拟机设个固定IP
      routes:
        - to: default
          via: 192.168.137.1  # 指向 Windows 的内部网卡 IP
      nameservers:
        addresses:
          - 223.5.5.5
          - 8.8.8.8

应用并测试：

sudo netplan apply

ping 192.168.137.1 # 此时应该能通网关

ping baidu.com # 此时应该能上网

结果：

方案一尝试了，无效；

由于我还是想使用桥接虚拟交换机的方式，所以方案二没尝试，有需求的朋友可以试试。

我个人有效的解决方案：

由于我之前设置了检查点，我发现我回到ssh init检查点时Ubuntu虚拟机又恢复正常了，可以联网了。这是/etc/netplan/50-cloud-init.yaml原始的内容，

此时虚拟机的网络适配器的虚拟交换机任然是桥接模式设置的外部网络啊，为啥现在没问题了（现在并未设置虚拟机固定ip）

这说明之前的故障并非单纯是"网卡坏了"或者"桥接绝对不可用"，而是手动配置的静态IP (Static IP) 与 Hyper-V 的桥接机制之间产生了冲突。

现在的配置（dhcp4: true + 桥接模式）之所以能通，是因为机制完全不同。

我为你复盘一下为什么"现在好了"以及"之前为什么挂了"：

1. 为什么现在能通？(DHCP 的功劳)

你现在的 Netplan 配置是 dhcp4: true。

• 流程是这样的： 你的 Ubuntu 启动 -> 发出广播"谁能给我个 IP？" -> 这个包穿过 Hyper-V 桥接 -> 到达你的物理路由器（比如你公司的 WiFi 路由器）。

• 关键点： 路由器主动分配了一个 IP 给虚拟机，并将其记录在路由器的表中。

• 结果： 路由器"认识"这台虚拟机，路由路径是通畅的。虽然WiFi 桥接有 MAC 地址限制（WiFi 协议（802.11）通常只允许一个 MAC 地址（即你物理网卡的地址）通过验证），但现代 Windows 10/11 的 Hyper-V 网桥会进行一种"MAC 地址转换 (MAT)"，配合 DHCP 使用时通常能正常工作。

2. 之前为什么不通？(静态 IP 的陷阱)

之前我们尝试手动在配置文件里写死 192.168.0.6。

• 问题所在： 在 WiFi 桥接模式下，如果你在虚拟机里强行指定一个 IP，而没有通过 DHCP 握手：

  1. 路由器不知道你的存在： 路由器没分配过这个 IP，它的 ARP 表里可能没有 192.168.0.6 对应的 MAC 地址记录。

  2. MAC 地址过滤： WiFi 接入点通常只允许通过认证的那个物理网卡 MAC 发包。Hyper-V 需要欺骗路由器，把虚拟机的包伪装成物理机的。当你手动指定 IP 时，这种底层的"伪装机制"有时会失效，导致回包发不到虚拟机手里。

• 导致的现象： 你能 Ping 通自己，但 Ping 不通网关（Destination Host Unreachable），因为数据包出去了，但回不来。

3. "检查点 (Checkpoint)" 的作用

你说回到了 ssh init 检查点就好了，这也是关键。

• 网络栈重置： 在我们刚才的一通折腾中（改 DNS、改路由、改 IP），Ubuntu 内部的网络缓存（ARP 缓存、路由表）可能已经乱了。

• 驱动重置： 回滚检查点相当于把虚拟机的网卡驱动状态恢复到了"出厂设置"，消除了之前所有配置错误留下的"后遗症"。

---

这里的"运维启示"

作为运维人员，在 Hyper-V + WiFi 环境下，有一条黄金法则：

在 WiFi 桥接模式下，尽量使用 DHCP，不要在虚拟机内部强行写死静态 IP。

接下来的建议： 既然现在网络通了（dhcp4: true），且你是桥接模式，你的虚拟机现在就像局域网里的一台真实电脑。

1. 保持现状 ：不要再去改 /etc/netplan/ 里的文件了，目前的配置是最健康的。

2. 查看当前 IP ： 输入 ip addr，记下当前的 IP 地址（比如可能是 192.168.0.x）。

3. 如何固定 IP（进阶） ： 如果你担心重启后 IP 会变，导致 SSH 连不上，不要在 Ubuntu 里改。

   • 正确的做法是： 登录你的物理路由器后台，在 DHCP 设置里，把这个虚拟机的 MAC 地址和某个 IP 绑定（DHCP Reservation）。这才是最稳妥的固定 IP 方式。

之前没Ipv4地址的时候是这样的：

现在Ubuntu虚拟机的 IP 地址为：192.168.0.6（帮我解释一下这行信息：inet 192.168.0.6/24 metric 100 brd 192.168.0.255 scope global dynamic eth0）；为了防止虚拟机每次启动后ip都不一样，ssh连接不上，请帮我固定 Ubuntu虚拟机IP。

很高兴看到你的虚拟机网络已经恢复正常！这验证了我们之前的判断：在 Hyper-V 桥接（尤其是 WiFi 环境）下，使用 DHCP 是最稳定的选择。

针对你的两个问题，我来分别解答：

第一部分：解读 ip addr 的输出信息

这行信息描述了你网卡当前的 IPv4 配置状态：

inet 192.168.0.6/24 metric 100 brd 192.168.0.255 scope global dynamic eth0

• inet 192.168.0.6/24:

  • inet: 表示这是 IPv4 协议的地址。

  • 192.168.0.6: 这是你虚拟机当前的 IP 地址。

  • /24: 子网掩码的简写（CIDR），代表 255.255.255.0。这意味着 192.168.0.1 到 192.168.0.254 都在同一个局域网内。

• metric 100:

  • 路由跃点数（优先级）。数值越小优先级越高。系统有多个网卡时，会优先走 metric 值更小的网卡。100 是普通有线/虚拟网卡的默认标准值。

• brd 192.168.0.255:

  • 广播地址 (Broadcast)。如果虚拟机想向局域网内所有设备喊话，就会把数据包发到这个地址。

• scope global:

  • 表示这个 IP 地址是全局有效的，意味着它可以访问外部网络（如互联网），而不仅仅是由于本机内部通信。

• dynamic (关键):

  • 表示这个 IP 是动态获取 (DHCP) 的，而不是手动写死的。这证实了你的 Netplan 配置 dhcp4: true 正在生效。

• eth0:

  • 这是该配置所属的网卡接口名称。

---

第二部分：如何固定 IP（防止 SSH 连不上）

这里有一个巨大的陷阱，请务必注意！

你之前遇到的 Destination Host Unreachable 错误，正是因为在 Hyper-V 桥接（特别是宿主机用 WiFi）模式下，在 Ubuntu 内部强行修改 Netplan 为静态 IP 导致的。

为了避免重蹈覆辙（再次断网），我有上、中、下三策供你选择：

方案一（上策）：在路由器端绑定 IP（最推荐，最稳）

既然现在的 dhcp4: true 配置能通网，我们就保持它不变。我们去告诉路由器："永远给这个设备分配 192.168.0.6"。

1. 记录 MAC 地址：

   从你的截图中可以看到，eth0 的 link/ether 是 00:15:5d:8e:01:04。

2. 进入路由器后台：

   在 Windows 浏览器输入网关 IP 192.168.0.1（通常是这个），登录你的物理路由器。

3. 寻找 DHCP 静态分配功能：

   通常在"DHCP 服务器"、"静态地址分配"、"地址预约"或"LAN 设置"里。

4. 添加绑定：

   • MAC 地址填：00:15:5d:8e:01:04

   • IP 地址填：192.168.0.6

5. 重启虚拟机：

   以后无论你怎么重启，路由器都会根据 MAC 地址把这个 IP 留给你的虚拟机。

优点：Ubuntu 内部配置无需改动，网络极其稳定，绝对不会出现之前的 ARP/网关不通问题。

本人测试结果：浏览器无法访问 https://192.168.0.1/，连接失败！！！

---

方案二（中策）：改用 Netplan 静态 IP（有风险，仅限有线网络建议）

警告 ：如果你宿主机是用 WiFi 上网的，这个方法有 80% 概率会再次导致你之前遇到的 Destination Host Unreachable 问题。只有当你宿主机插着网线时，才建议尝试。

如果你一定要在 Ubuntu 内部写死 IP，请按以下格式修改 /etc/netplan/50-cloud-init.yaml：

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: false
      addresses:
        - 192.168.0.6/24
      routes:
        - to: default
          via: 192.168.0.1
      nameservers:
        addresses:
          - 223.5.5.5
          - 8.8.8.8

修改完后执行 sudo netplan apply。如果再次断网，请立即还原配置。

**个人记录：**我没敢再碰Netplan配置文件，怕再次挂掉，目前我虚拟机ip还是动态分配的，哈哈哈哈！！！！

---

方案三（备选）：仅为了 SSH 方便

如果你只是不想每次查 IP，而不是非要固定它，你可以：

1. 使用主机名连接：

   在 Windows 终端，尝试 ping wangminghaoserver.local 或者直接 ssh user@wangminghaoserver.local。

   (Ubuntu 默认会广播 mDNS 主机名，Windows 通常能直接解析，这样 IP 变了也能连上)

总结建议

鉴于你刚刚从静态 IP 的故障中恢复，强烈建议使用"方案一" 。保持 Ubuntu 现在的 dhcp4: true 配置，去路由器上做绑定。这是运维环境中最稳妥的做法。

扩展知识：

虚拟机网桥模式下Windows宿主机发生了什么？

我在控制面板的网络连接里手动删除了网卡适配器后发现网卡连同HyperV的适配器一起删除了，然后我又在HyperV里面重新新建了外部网络WAN（桥接模式）后，发现宿主机的适配器设置里的网卡和WAN又出现了，为什么会这样？

这是一个非常经典的 Hyper-V 网络机制问题。作为运维人员，理解这个机制对你排查虚拟化网络故障非常关键。

简单来说，你看到的现象是 Hyper-V 虚拟交换机（Virtual Switch）对物理网卡的"夺舍"与"重建"过程。

我可以用一个形象的比喻来解释，然后带你看一下底层的技术原理。

1. 形象的比喻：网卡变身"交换机端口"

• 没有 Hyper-V 时：

  你的物理网卡就像一根独享的水管，直接连到你的 Windows 系统。所有的水（数据）都直接流进系统里。

• 开启 Hyper-V 外部网络（桥接）后：

  Hyper-V 说："这根水管现在归我管了，我要把它改造成一个总进水阀（虚拟交换机）。"

  • 物理网卡：变成了"总进水阀"的进水口。它不再直接给 Windows 供水，而是专门负责从外面（路由器）抽水。

  • vEthernet (WAN) ：这是 Hyper-V 给你接的一根新水管（虚拟网卡），它从"总进水阀"里分流出一部分水给宿主机 Windows 用。

如果你把"总进水阀"拆了（删除适配器）：

这就是你之前的操作。你把这套复杂的管道系统拆了，Windows 可能会暂时找不到北，显示网卡消失或驱动重置。

当你重新建立外部网络 WAN 时：

Hyper-V 重新接管了硬件，它必须把两个东西都呈现给你：

1. 物理网卡：告诉你"硬件还在，但我已经占用了"。

2. vEthernet (WAN)：告诉你"这是给你用的新接口，你的 IP 应该设在这里"。

---

2. 底层技术原理：协议栈的绑定 (Binding)

为什么会出现"两个都出来"的情况？请按照以下步骤检查，你立马就懂了：

第一步：检查物理网卡的属性

1. 在"网络连接"面板中，找到你的物理网卡（不是 vEthernet 那个）。

2. 右键 -> 属性。

3. 请注意看列表里的勾选情况！

   • 你会发现 Internet 协议版本 4 (TCP/IPv4) 的勾 被取消了。

   • 你会发现唯独勾选了一个叫 Hyper-V Extensible Virtual Switch 的项目。

原理：

**当你创建外部交换机时，Hyper-V 实际上是劫持了物理网卡。**它把物理网卡原本承担的 TCP/IP 协议栈（发邮件、看网页）全部剥离，只保留一个功能：作为虚拟交换机的上行链路（Uplink）。

第二步：检查 vEthernet (WAN) 的属性

1. 找到那个新出来的 WAN (vEthernet) 适配器。

2. 右键 -> 属性。

3. 你会发现，这里的 Internet 协议版本 4 (TCP/IPv4) 是被勾选的。

原理：

为了不让你的宿主机断网，Hyper-V 生成了这个虚拟网卡。它连接到虚拟交换机的一个虚拟端口上。宿主机的上网流量，实际上是走的这条虚拟线路。（Windows的流量也是走的**vEthernet (WAN)**这个虚拟网卡）

3. 为什么删除时会一起消失？

当你手动删除适配器时，你实际上破坏了 Hyper-V 建立的 LBFO (Load Balancing/Failover) 绑定 或 桥接绑定。

• Windows 的网络堆栈检测到绑定关系破裂，或者驱动状态异常，可能会尝试卸载相关联的设备以保护系统稳定，或者因为驱动层面的依赖关系断裂，导致上层的虚拟适配器（依赖项）和底层的物理适配器（被依赖项）同时从逻辑视图中消失，等待重新扫描或重置。

总结与建议

这一现象是 完全正常 的。

作为运维人员，你需要记住的操作红线：

1. 配置 IP 时 ：永远去配置 vEthernet (WAN) 那个虚拟网卡的 IP，千万不要去手贱强行勾选物理网卡的 IPv4 并配置 IP。如果你这样做，物理网卡会同时承担"交换机上行口"和"普通网卡"两个角色，会导致严重的网络风暴或断网。

2. 物理网卡：在 Hyper-V 桥接模式下，物理网卡只是一个"没有任何感情的传输介质"，请忽略它的存在，不要动它的设置。

虚拟机网桥模式下，控制面板网络连接的变化

我的控制面板中网络连接截图：

截图1

截图2

截图3

截图4

为什么是这样？你从上面的截图中都能得到那些信息，请教会我相关知识点。

你的截图展示了一个非常标准的、基于 WiFi 网卡 创建的 Hyper-V 外部网络（桥接） 拓扑。

之所以你感到困惑，是因为 Hyper-V 为了让 WiFi（802.11协议）能承载虚拟机流量，在底层做了一层复杂的**"协议转换与桥接"**。我们一个一个来拆解。

---

1. 为什么 WLAN 显示"此适配器是网桥的一部分"？（图3）

现象：

你在 WLAN 属性里看到它被锁定了，无法配置 IP，提示它是网桥的一部分。

原理：

• 物理层的"被征用"：

  当你创建 Hyper-V 外部交换机并选择 WiFi 网卡时，Windows 剥夺了这块物理网卡（Qualcomm QCA9377）作为一个独立"上网设备"的权利。

• 角色转变：

  它现在不再直接服务于你的操作系统，而是降级为一根单纯的**"物理管道"**（或者叫上行链路 Uplink）。它的唯一任务就是把无线信号收进来，扔给上层的"网桥"处理。

• 含义：

  这句话的意思是："别动我，我现在归'网桥'管，我只负责收发底层的电波信号，不负责处理 IP 地址。"

---

2. 网桥属性里的勾选代表什么？（图2）

这是最核心的部分。你看到了一个名为 网桥 的设备，且只勾选了 WLAN 和几个奇怪的协议。

为什么只勾选了 WLAN？

• 通过勾选建立连接 ：这里的勾选意味着："谁是这个桥的物理出口？"。因为你选了 WLAN，所以数据包最终会通过 WLAN 发到你的物理路由器。

• 混合模式（Promiscuous Mode）：网桥会将 WLAN 网卡置于一种特殊模式，允许它接收发往其他 MAC 地址（比如你的虚拟机 MAC）的数据包，而不仅仅是发给它自己的。

为什么只勾选了这三个协议？（关键运维知识点）

注意看，Internet 协议版本 4 (TCP/IPv4) 是未勾选的！

• Microsoft MAC 桥：这是核心驱动，负责在二层（数据链路层）把 WiFi 数据帧（802.11）转换成以太网帧（802.3），让虚拟机能看懂。

• Hyper-V 可扩展的虚拟交换机：这是 Hyper-V 的逻辑核心。它把这个网桥变成了一个"虚拟交换机"，让虚拟机可以插网线进来。

• 作用总结：

  这个网桥工作在 OSI 模型的第二层（数据链路层）。 它像一个物理交换机一样，只负责根据 MAC 地址转发数据帧。交换机本身是不需要 IP 地址的，所以 TCP/IPv4 被去掉了。它不需要"上网"，它只是在"搬运"数据。

---

3. 为什么 vEthernet (WAN) 勾选了那么多项目？（图4）

现象：这个虚拟网卡勾选了 TCP/IPv4、文件共享客户端等所有常规选项。

原理：

• 宿主机的"救生艇"：

  既然物理 WLAN 网卡已经被"征用"去做桥接了（变成了管道），那你的 Windows 宿主机怎么上网呢？

• 虚拟网卡：

  Hyper-V 贴心地给宿主机创建了一个虚拟网卡（即 vEthernet (WAN)）。它就像一根网线，一头插在宿主机上，另一头插在刚才那个"网桥/交换机"的虚拟端口上。

• 回归正常：

  对于你的 Windows 系统来说，这个 vEthernet 才是它现在真正的"网卡"。所以它必须拥有完整的网络功能（TCP/IP 协议栈、DNS、NetBIOS 等），这样你才能看网页、聊微信。

---

总结：数据包的"奇幻漂流"

为了让你彻底明白，我们来模拟一个数据包从 Internet 飞到你的 宿主机 的过程。

拓扑图脑补：

互联网 <-> 物理路由器 <-> ((空气中的无线电波)) <-> 物理网卡(WLAN) <-> 网桥(Layer 2) <-> 虚拟交换机

⬇️ 分流

┌───────────────┴───────────────┐

⬇️ ⬇️

vEthernet (WAN) 虚拟机网卡 (eth0)

(宿主机 Windows) (Ubuntu VM)

图解说明：

1. 最上层（外部）：路由器发出 WiFi 信号。

2. 物理入口（WLAN） ：你的 Qualcomm 网卡接收信号。注意：此时它不拥有 IP，它只是一个"聋哑"的接收器，完全受控于网桥。

3. 转换层（MAC 网桥） ：这是关键。它把 WiFi 信号"翻译"成网线信号（以太网帧），并欺骗路由器，让路由器以为后面连着好几台设备。

4. 调度层（Hyper-V 交换机）：数据包到达这里后，交换机查看"目标 MAC 地址"：

   • 如果是发给 Windows 的，就扔给 vEthernet (WAN)。

   • 如果是发给 Ubuntu 的，就扔给 eth0。

5. 终端层：

   • vEthernet (WAN) ：拿着 192.168.0.4，让你的 Windows 上网。

   • eth0 ：拿着 192.168.0.6，让你的 Ubuntu 上网。

这就是为什么你在"网桥"里只能看到协议驱动，而在"vEthernet"里能看到 IP 设置的原因。这个架构非常精妙，实现了仅仅通过一张 WiFi 网卡，就让宿主机和虚拟机像两台独立的电脑一样并排连在路由器上。

从截图中提取的运维知识点（敲黑板）：

1. 物理网卡哑火（Promiscuous Mode）：

   在桥接模式下，永远不要去尝试给物理网卡（截图中的 WLAN）配置 IP。它只是一个通过数据的"介质"。

2. 管理口与业务口分离：

   • vEthernet (WAN) 相当于服务器的管理网口（宿主机用）。

   • 网桥 相当于交换机背板。

   • WLAN 相当于上行光模块/网口。

3. 排查思路：

   • 如果宿主机上不了网，检查 vEthernet (WAN) 的 TCP/IPv4 设置。

   • 如果虚拟机和宿主机都断网，但 WiFi 连接正常，检查 网桥 里的 Hyper-V 可扩展交换机 协议是否勾选。

   • 如果物理 WiFi 总是断开，可能是 Microsoft MAC 桥 驱动和无线网卡驱动兼容性不好（WiFi 桥接常见坑）。

接下来我们涉及一些网络中最底层、最核心的**"协议绑定（Protocol Binding）"**机制。

在 Windows 网络栈中，网卡不仅仅是硬件，它上面挂载了一层又一层的"驱动程序"和"协议"。你勾选或取消勾选，实际上是在决定谁有权处理流经这块网卡的数据。

---

第一部分：这些勾选的项目都代表什么？

我们要把这些项目分为两类来看："干活的（底层驱动）" 和 "享受服务的（上层协议）"。

1. 在"网桥"属性里勾选的项目（截图2 ）

这部分是数据链路层（Layer 2）的配置。注意看，这里的 TCP/IPv4 是未勾选的。

• ☑ Microsoft MAC 桥 (Microsoft MAC Bridge)

  • 作用：这是一个核心驱动。它的作用是把不同的物理介质（比如 WiFi 的 802.11 协议和有线的 Ethernet 802.3 协议）"粘"在一起。

  • 为什么在 WiFi 下必须有它：因为 WiFi 网卡的数据帧格式和虚拟机的以太网帧格式不一样，而且 WiFi 接入点（AP）通常只认一个 MAC 地址。这个"桥"负责在中间做欺骗和转换，让虚拟机能通过 WiFi 上网。

• ☑ Hyper-V 可扩展的虚拟交换机 (Hyper-V Extensible Virtual Switch)

  • 作用：这是 Hyper-V 的灵魂。勾选它，意味着告诉系统："把这个网桥产生的所有流量，全部接管给 Hyper-V 的虚拟交换机程序处理。"

  • 地位 ：它是流量的总调度官。它决定数据包是发给虚拟机，还是发给宿主机。

• ☑ Microsoft LLDP 协议驱动程序

  • 作用：LLDP (Link Layer Discovery Protocol) 是一种工业标准的链路发现协议。

  • 应用场景：它允许你的电脑向连接的物理交换机（如果是企业级网络）广播："我是谁，我连在你的哪个端口"。在家里用处不大，但 Windows 默认开启，用于网络拓扑发现。

2. 在"vEthernet (WAN)"属性里勾选的项目（截图 4）

这部分是网络层（Layer 3）及以上的配置。这里是给宿主机 Windows 用的。

• ☑ Internet 协议版本 4 (TCP/IPv4)

  • 作用：赋予网卡 IP 地址，让它能上网。

  • 为什么这里要勾选 ：因为 vEthernet 是宿主机的"逻辑网卡"。只有勾选了这个，你的 Windows 才能获得 192.168.0.4 这个 IP。

• ☑ Microsoft 网络客户端 / 文件和打印机共享

  • 作用：让你能访问局域网共享文件夹（SMB协议）。

---

第二部分：为什么配置是这样的？（核心逻辑）

你可能会问：为什么网桥里不勾选 IPv4，而要到 vEthernet 里勾选？

• 网桥（物理层面的聚合） ：它就像一段水管 或电线。水管本身不需要喝水（不需要 IP），它的任务是让水流过。如果给网桥配了 IP，会导致路由混乱。

• vEthernet（逻辑层面的终端） ：它就像接在水管上的水龙头。水龙头需要出水给用户用（宿主机），所以它需要 IP 地址。

移除虚拟交换机WAN后再新建，导致Ubuntu虚拟机无法上网

为什么我每次删掉网桥后，重新再在HyperV的虚拟交换机里面创建WAN外部网络后，进入Ubuntu虚拟机就发现上不了网了呢，查看ip发现不见了，ip addr -> 发现没拿到了 IP ，为什么会这样？请给出解决方案。

这是一个非常符合逻辑但也很令人抓狂的现象。简单来说，是因为你**"拆了路（删网桥），又修了路（建网桥），但车（虚拟机）还在原地傻等，而且路标（ARP缓存）也乱了"。**

我来为你深度剖析这背后的技术原因，并给出无需重启虚拟机的"无痛"恢复方案。

---

一、 核心原因分析：为什么 IP 没了？

当你删除并重建 Hyper-V 外部网络时，发生了两件致命的事情：

1. 物理链路"热插拔"导致 DHCP 超时

• 动作：你删除网桥时，相当于把插在 Ubuntu 上的**"虚拟网线"拔掉了**。

• 后果 ：Ubuntu 的 DHCP 客户端（systemd-networkd）检测到链路断开，会尝试重连。但因为你重建网桥需要时间（比如几十秒），这个时间超过了 DHCP 的快速重试窗口。Ubuntu 就会认为"没网了，算了"，于是放弃请求 IP，进入休眠/等待状态。当你路修好了，Ubuntu 并不知道，它还在等一个"物理连接已恢复"的信号。

2. 路由器的 ARP 缓存失效（最关键的原因）

• 动作 ：你重建了网桥。虽然名字还叫 WAN，但 Hyper-V 可能会为这个新网桥生成一个新的虚拟 MAC 地址（在宿主机端）。

• 后果：

  • 你的物理路由器（网关 192.168.0.1）的缓存里，可能还记着**"旧网桥"**的 MAC 地址信息。

  • 当 Ubuntu 试图发包时，数据包经过新网桥出去，路由器一看："咦？这个 MAC 地址我不认识/跟我小本本上记的不一样"，为了安全（防止 ARP 欺骗），路由器可能会丢弃这些包，或者拒绝分配 IP。

---

二、 解决方案

你不需要每次都去重启虚拟机，用以下方法可以快速唤醒网络。

方法一：在 Ubuntu 内部"软重启"网络（最快，推荐）

既然 Ubuntu 放弃了治疗，我们就手动打它一巴掌，让它重新找 DHCP 服务器要 IP。

1. 打开 Ubuntu 终端。

2. 输入以下命令强制重新应用 Netplan 配置：

   sudo netplan apply

   这行命令会触发 systemd-networkd 重新加载，相当于"拔掉网线再插上"，它会立即发起新的 DHCP Discovery 请求。

3. 如果不奏效，尝试强制刷新 DHCP 客户端（如果安装了 dhclient）：

   sudo dhclient -r eth0  # 释放（如果有的话）
   sudo dhclient -v eth0  # 强制获取

方法二：在 Hyper-V 侧"硬开关"网卡（如果方法一无效）

有时候是 Hyper-V 的虚拟端口卡死了，需要在宿主机侧操作。

1. 打开 Hyper-V 管理器。

2. 右键虚拟机 -> 设置 -> 网络适配器。

3. 将"虚拟交换机"改为 "未连接" -> 点击 应用。

4. 等待 2 秒（让 Ubuntu 彻底感知到断网）。

5. 再改回 "WAN (你的外部网络)" -> 点击 应用 -> 确定。

   • 这一步相当于物理层面的"拔网线 -> 插网线"，绝对能触发 Ubuntu 的 DHCP 请求。

方法三：重启大法（最彻底）

如果你修改了宿主机的网络拓扑（比如删除了网桥这种大动作），重启虚拟机其实是最稳妥的运维习惯。因为这能确保所有底层的 ARP 表、路由表和驱动状态都通过初始化流程回归正常。

本人测试：

其实这三套方法我们之前出问题的时候就尝试过了，反正对本人的虚拟机都无效。这回因删除网桥出问题，经过本人尝试方法一、方法二、方法三均无效。

---

三、 运维建议

请尽量避免频繁删除/重建 Hyper-V 的虚拟交换机。

• 原因：虚拟交换机（vSwitch）是深度绑定在 Windows 内核网络栈里的。频繁拆装容易导致 Windows 的注册表残留（Ghost Network Adapters），最后可能会导致你宿主机本身断网蓝屏。

• 正确姿势：一旦创建好了 WAN 外部网络，就留着它。如果你想换 WiFi 环境，只需让宿主机连上新 WiFi，Hyper-V 的桥接会自动跟随宿主机的新网络（只要它是 DHCP 模式）。

以上方法一、方法二、方法三均无效，请更深入的分析原因，并给出其他尝试方案。

既然常规的"软硬重启"都无效，这说明问题出在 Hyper-V 与 WiFi 网卡之间的 MAC 地址转换（MAC Address Translation, MAT）机制失效了。

深度分析：为什么"路通了，车却动不了"？

在 WiFi 桥接模式下，Hyper-V 必须进行一种非常复杂的"欺骗"操作：

1. WiFi 的物理限制：WiFi 接入点（AP/路由器）通常只允许与它握手认证的那个 MAC 地址（你的物理网卡）发送数据。它会丢弃所有源 MAC 地址不匹配的数据包。

2. Hyper-V 的 MAT 机制 ：当你虚拟机（MAC: 00:15:5d...）发包时，Hyper-V 的网桥必须把包里的"源 MAC"偷偷改成物理网卡的 MAC，再发出去。等路由器回包时，它又要反向改回来，把包塞给虚拟机。

核心原因 ：当你删除并重建网桥后，这个 MAT 映射表或底层的驱动绑定状态卡死了。数据包能出去（可能），但回来的 DHCP Offer 包因为 MAC 地址对不上，被物理网卡或者网桥驱动直接丢弃了，根本没进到虚拟机里。

进阶解决方案（按成功率排序）

请依次尝试以下方案，这些方案涉及更底层的 Hyper-V 配置。

方案一：开启"启用 MAC 地址欺骗" (Enable MAC Address Spoofing)

这是一个隐藏开关，虽然主要用于嵌套虚拟化，但在 WiFi 桥接故障中，它往往能强制网桥放行"非本机 MAC"的流量。

1. 关闭 虚拟机。

2. 打开 Hyper-V 管理器 -> 右键虚拟机 -> 设置。

3. 展开 网络适配器 左侧的小加号 +，点击 高级功能 (Advanced Features)。

4. 在右侧找到 MAC 地址欺骗 (MAC Address Spoofing) 栏。

5. 勾选 "启用 MAC 地址欺骗 (Enable MAC address spoofing)"。

6. 点击 应用 -> 确定。

7. 开机，检查 ip addr。

方案二：强制更换虚拟网卡 MAC 地址 (刷新 ARP 缓存)

既然现在的 MAC 地址可能被路由器或网桥"拉黑"了，我们直接给虚拟机换个新身份证。

1. 关闭 虚拟机。

2. Hyper-V 管理器 -> 右键虚拟机 -> 设置。

3. 点击 网络适配器 -> 右侧展开 高级功能。

4. 在 MAC 地址 栏：

   • 当前应该是"动态 (Dynamic)"。

   • 改为选择 "静态 (Static)"。

   • 修改最后两两位数字（例如把 06 改成 11）。

5. 点击 应用 -> 确定。

6. 开机。这会强制路由器和网桥将你视为一台全新的设备，重新发起 DHCP 握手。

方案三：重置"Microsoft MAC 桥"驱动绑定 (运维级手术)

如果上述都不行，说明是 Windows 宿主机的网桥驱动卡死（Zombie State）。我们需要手动重置协议绑定。（注意：此操作可能会导致宿主机短暂断网 10 秒）

1. 在宿主机，打开 控制面板 -> 网络和 Internet -> 网络连接。

2. 找到你的 物理 WiFi 网卡 (WLAN) -> 右键 -> 属性。

3. 取消勾选 "Hyper-V 可扩展的虚拟交换机"。

4. 点击 确定。（此时你的网桥连接会断开）。

5. 再次右键 物理 WiFi 网卡 (WLAN) -> 属性。

6. 重新勾选 "Hyper-V 可扩展的虚拟交换机"。

7. 点击 确定。

8. 回到虚拟机内部（如果没关机），执行 sudo dhclient -v eth0 尝试获取 IP。

方案四：放弃 WiFi 桥接，改用"Default Switch + 端口转发" (最稳妥的退路)

如果以上所有方法都试过了，依然无法获取 IP，说明你的 物理网卡驱动 (Qualcomm QCA9377) 对 Windows 11/Hyper-V 的混杂模式支持极差（这在旧款 Qualcomm 网卡上非常常见）。继续死磕桥接可能会浪费你大量时间。

作为运维人员，目标是解决问题。建议改回 NAT 模式，并通过端口转发实现外部访问。

1. 改回 Default Switch：虚拟机设置里切回默认交换机。

2. 固定 IP (NAT内) ：按照我之前给你的 192.168.137.x (ICS) 或让它自动获取。

3. 配置端口转发（如果你需要外部 SSH 连入）：

   在 Windows 管理员 PowerShell 执行：

   # 将宿主机的 2222 端口转发到 虚拟机的 22 端口
   netsh interface portproxy add v4tov4 listenport=2222 listenaddress=0.0.0.0 connectport=22 connectaddress=<虚拟机当前的IP>

   以后你 SSH 连接 宿主机IP:2222 就能进虚拟机了。

建议优先尝试"方案一"和"方案二"，通常能解决 90% 的重建后无网问题。

本人测试：

• 方案一和方案二我都尝试了，还是无效。
• 方案三我没尝试，感兴趣朋友可以试试。
• 方案四是让我放弃 WiFi 桥接，改用Default Switch模式，我不想换，我就想使用虚拟机桥接模式，所以没尝试。

我个人有效的解决方案：

还是老办法，直接回到ssh init检查点，发现Ubuntu虚拟机一切都恢复了正常，这说明还是Ubuntu虚拟机这边的问题。

故事结尾：

开始因为我的Ubuntu虚拟机连不上网了（HyperV虚拟机桥接模式），但是我的Windows宿主机正常上网，我尝试了一系列的办法.....分析了一系列的可能的原因.....也学到了很多的网络配置的知识点....但是这些花里胡哨的方案，最终并没有有效解决问题。

最终还是通过HyperV的Ubuntu虚拟机返回之前检查点，之后解决了该问题。

特此记录！！！！

参考文档：

1.虚拟机的网络设置，NAT|Brigde|桥接|内部网络|外部网络|专用网络是什么？

https://www.bilibili.com/opus/871836583958937622

2.你管这破玩意叫网络

https://mp.weixin.qq.com/s/N8a-YcCoVmXNrDWjnaxuJg