虚拟机路由不通，九成是网卡模式或网关配置的问题，先查这两处，再用一条命令验证，基本就能定位。
为什么你的虚拟机和主机像是住在两个星球
很多朋友第一次配虚拟机网络时,都会遇到一个尴尬场景：宿主机能上网，虚拟机里却一片漆黑，ping 网关不通，ping 主机也毫无回应，这种 虚拟机主机路由不通 的问题，源于虚拟交换机对数据包的“翻译”方式和你预期的不一样，虚拟机里的网卡本质上是软件模拟出来的，它发出的 ARP 请求和 IP 数据包，必须经过虚拟交换机才能转发到物理网卡，如果虚拟交换机的端口类型和你的使用场景不匹配，数据包就会被卡在虚拟网络内部。
NAT 模式下默认网关“不认人”
NAT 模式（VMware 的 VMnet8 或 VirtualBox 的 NAT）是新手最常用的模式，这种模式下，虚拟机通过宿主机的一个虚拟网卡（如 VMnet8）共享 IP 地址上网，虚拟机内部的默认网关必须指向 VMnet8 的 IP（通常是 192.168.x.1 或 10.0.2.2），而不是你家里路由器的 192.168.1.1，如果你手滑配错了网关，所有去往外部网络的包都会被丢进黑洞。
桥接模式下物理交换机“不认账”
桥接模式（Bridge）会让虚拟机直接接入物理局域网，它应该和宿主机在同一网段，这时候如果宿主机用的是 DHCP 自动获取 IP，而虚拟机里却填了一个静态 IP，且这个 IP 已被其他设备占用，那么物理交换机就会把虚拟机的数据包直接丢弃，还有一种情况是无线网卡环境，很多 USB 无线网卡驱动不支持混合模式（Promiscuous Mode），桥接后虚拟机的包根本发不出去。
防火墙把 ICMP 协议当作“入侵者”
虚拟机和宿主机都装了第三方安全软件时,它们自带的防火墙驱动会拦截 ICMP 回显请求，很多时候你 ping 不通，但用 telnet 或远程桌面却能连上，这就是典型的 防火墙拦截 ping 请求 而非路由故障。
虚拟机路由不通怎么排查？三步定位法
与其瞎猜,不如按顺序检查三个位置，这套排查逻辑适用于 VMware Workstation、VirtualBox 以及 Hyper-V 三种主流平台。
第一步：检查虚拟网卡与虚拟交换机连接
打开虚拟机设置,确认网卡类型是 Intel PRO/1000 MT 桌面版 或 Realtek RTL8139，而不是“VMware Paravirtual”这类高性能虚拟专有网卡，有些精简版系统镜像没有集成虚拟网卡驱动，会导致网络适配器处于“未识别的网络”状态。
然后在宿主机上运行 ipconfig（Windows）或 ifconfig（Linux/macOS），找到虚拟网卡对应的 IP 地址：
- VMware NAT 模式下，宿主机上的 VMnet8 网卡 IP 就是虚拟机的默认网关
- VirtualBox NAT 模式下，默认网关固定为
0.2.2，虚拟机自身 IP 为0.2.15 - Hyper-V 默认交换机（Default Switch）网关常为
17.x.1这类动态地址
第二步：在虚拟机内测试网络连通性
进入虚拟机桌面,打开终端（Linux）或命令提示符（Windows），执行以下三条命令：
ipconfig或ip addr：查看虚拟机当前 IP 地址、子网掩码、网关ping <虚拟网关IP>：ping 192.168.137.1（Windows 自带共享热点的网关地址）tracert或traceroute外部地址：如tracert baidu.com
如果第一步的 IP 地址是 169.254.x.x（Windows）或 0.0.0.0（Linux），说明虚拟机没有从 DHCP 服务器获取到地址，这时候手动指定 IP 和网关后，再去 ping 网关。
具体操作路径（以 VMware 为例）：编辑 → 虚拟网络编辑器 → 选择 VMnet8 → 查看子网 IP 设置为 168.xxx.0，NAT 设置里看网关 IP 是否为 168.xxx.2，在虚拟机里把 IPv4 地址配成 168.xxx.100，网关指向 168.xxx.2，DNS 保持默认。
第三步：临时关闭防火墙验证
这个动作是为了快速缩小问题范围，在虚拟机内，用管理员身份执行：
- Ubuntu/Deepin：
sudo ufw disable - CentOS/RHEL：
sudo systemctl stop firewalld - Windows Server：
netsh advfirewall set allprofiles state off
然后在宿主机上 ping 虚拟机的 IP，如果通了，说明路由没有问题，只是防火墙驱动拦截了 ICMP 流量。记住测试完后重新开启防火墙，并添加明确的入站规则，不要长期裸奔。
虚拟机桥接模式无法上网？对应场景处理
桥接模式是最容易出状况的,因为它的配置完全依赖物理网络环境，下面是三种常见场景的解决方案。
办公室有线网络，交换机做了端口绑定
很多公司网管会做 MAC 地址与交换机端口绑定，如果你的虚拟机使用桥接模式，物理交换机只认宿主机网卡的 MAC，虚拟机的数据帧源 MAC 地址在交换机看来是“陌生设备”，直接丢包。
处理办法：给虚拟机网卡设置一个同网络段内的空闲 IP，并把虚拟机的 MAC 地址改成和宿主机网卡相同（不推荐，容易引起 IP 冲突），更稳妥的办法是向网管申请一个额外的绑定关系，或者在宿主机上做 NAT 转发而不是直接桥接。
家庭无线网络，路由器开启了 AP 隔离
为了安全,很多家用路由器默认开启“AP 隔离”（又叫客户端隔离），这个功能会让同一 Wi-Fi 下的设备互相无法访问，虚拟机桥接到的无线网络同样受影响。
检查与解决：登录路由器管理后台（如 192.168.1.1），找到 无线设置 → 主机隔离 或 客户端隔离 选项，将其关闭，若路由器不支持该选项，那只能改用 NAT 模式。
虚拟机桥接后能上网但 ping 不通宿主机
这属于“单向可达”问题，先看宿主机防火墙是否开启了“文件和打印机共享（回显请求 - ICMPv4-In）”规则，Windows 系统默认关闭此规则，需要手动开启：控制面板 → Windows Defender 防火墙 → 高级设置 → 入站规则 → 找到“回显请求”规则并启用。
行业共识认为，桥接模式下虚拟机的 DNS 最好与宿主机一致，避免内网域名解析异常导致的连通性假象。
表：三大网卡模式的适用场景比较
| 模式 | 能否访问外网 | 与宿主机互通 | 与局域网其他设备互通 | 适合场景 |
|---|---|---|---|---|
| NAT | 可以 | 可以（需关防火墙） | 单向（不可被访问） | 本机开发和测试 |
| 桥接 | 可以 | 可以 | 可以（像一台独立设备） | 模拟真实服务器 |
| 仅主机 | 不可以 | 可以 | 不可以 | 隔离验证环境 |
另一类常见故障：虚拟机和主机连通了但没法上网
路由通,说明默认网关可达，但“上不了网”还差最后一段DNS 解析和 NAT 转发规则。
DNS 配置错误是隐形杀手
Linux 虚拟机里 /etc/resolv.conf 文件中写了一个已经失效的 DNS 服务器（比如内网某个已下线机器的 IP），ping github.com 会提示“无法解析域名”，但直接 ping 公网 IP 却通，建议把 DNS 临时设为公共 DNS：
echo "nameserver 223.5.5.5" > /etc/resolv.conf
这里用的是阿里 DNS，国内访问速度快。用 IP 通而域名不通的，十有八九是 DNS 问题，先换 DNS 再排查其他。
NAT 服务未启动的排查
以 VMware 为例，Windows 宿主机上需要三个服务运行：VMware NAT Service、VMware DHCP Service、VMware Authorization Service，按 Win + R 输入 services.msc，找到这三个服务，确保启动类型为“自动”，运行状态为“正在运行”，NAT 服务停了，虚拟机的网关会整个消失，表现为 ping 网关 根本无法解析出 ARP 响应。
排查宿主机上的 IP 转发开关
在 Linux 宿主机上使用 KVM 或 QEMU，还需要打开内核 IP 转发：
sysctl net.ipv4.ip_forward=1 echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
不打开这个开关,虚拟机发往外部网络的包到了宿主机这一层就被丢掉了，转发没有出口，路由表成了摆设。
从路由不通到彻底联网：一次踩坑全记录
这里模拟一个真实的修复过程,环境：VMware Workstation 17，虚拟机是 CentOS Stream 9，宿主机 Windows 11。
现象：虚拟机 IP 为 192.168.137.128（VMnet8 网段），网关 192.168.137.1，ping 网关超时。
排查过程：
- 在宿主机上 ping 192.168.137.128，不通。
- 查看虚拟网络编辑器,发现 VMnet8 的子网 IP 是
168.238.0，而虚拟机里的 IP 是 192.168.137.x，两个网段完全对不上。 - 在虚拟网络编辑器里把 VMnet8 的子网 IP 改为
168.137.0，同时修改 NAT 设置里的网关为168.137.1。 - 重启虚拟机网络服务：
systemctl restart network。 - ping 网关，通。
当时用户的情况，就是典型的“IP 段与虚拟网卡子网不一致”，这类问题大多因为之前手动改过 VMnet8 的网段，而虚拟机里仍然沿用旧的 IP 配置，建议每次修改虚拟网络编辑器后，在虚拟机里重新启用一次网络适配器，确保 DHCP 重新分配地址。
业内专家指出，超过半数的虚拟机网络故障都出现在虚拟交换机配置与虚拟机的网卡参数不一致上，虚拟网络编辑器是排查起点，而非在虚拟机内部反复检查网卡 IP，先用宿主机 ipconfig 确认虚拟网卡的真实 IP 段，再去调整虚拟机内的地址，顺序不能颠倒。
虚拟机和宿主机互相 ping 不通时如何补充验证
路由配置全部正确,防火墙也放行了，但依然不通，可以尝试下面两个偏方。
检查网卡是否开启了巨型帧
某些虚拟机默认的 MTU（最大传输单元）是 1500，但宿主机物理网卡被设置成了 9000（巨型帧），当虚拟机的数据包要经过宿主机转发时，宿主机网卡无法处理过大的包，直接丢弃，把两端 MTU 都改为默认值 1500，问题立解。
关闭宿主机上的网络共享冲突
Windows 宿主机开了“移动热点”或“Internet 连接共享”后，会强制把 VMnet8 网卡的 IP 改为 168.137.1，并且占用 DHCP 服务，这会直接覆盖你在虚拟网络编辑器里设置的自定义网段，如果你不想用 192.168.137.x 这个网段，需先关闭移动热点，改回自定义子网，再重新配置虚拟机的静态 IP。
Q&A：关于虚拟机主机路由的常见疑问
为什么我改了虚拟机 IP 后，重启系统又变回原来的地址？
这是因为虚拟机的网卡配置默认使用 DHCP 动态获取，Linux 中如果你编辑的是 /etc/network/interfaces 或 NetworkManager 的配置文件但没生效，也可能是 DHCP 客户端服务（如 dhclient）覆盖了你的静态配置，正确做法是先关掉 DHCP 服务：sudo systemctl stop dhclient 并禁用该服务，再配置静态 IP，在 Windows 虚拟机里，需要到“网络连接”中把 IPv4 属性改为“使用下面的 IP 地址”，填好 IP、掩码和网关后，点“确定”再禁用启用一次网卡。
同一台虚拟机，在 NAT 模式下能通，切到桥接模式就必须重新设置网卡吗？
是的。 NAT 和桥接模式下，虚拟机的 IP 和网关处于不同网段，NAT 模式走虚拟网卡，桥接模式直接向物理网卡发数据，虚拟机内不会自动感知切换，系统会保留旧网络的 IP 分配，切换到桥接模式后，你需要把虚拟机 IP 改为与宿主机同一网段，网关指向路由器地址，在 VMware 里切换网卡模式后，建议在虚拟机内执行 dhclient 重新获取 IP（或重启网络服务），若获取不到则手动配置。
宿主机能 ping 通虚拟机，但虚拟机 ping 不回宿主机，这是为什么？
基本是路径回来的方向被丢弃,虚拟机的出站数据包能到达宿主机，但宿主机回的包在虚拟机里找不到对应的“连接状态记录”，Linux 虚拟机默认开启了 rp_filter（反向路径过滤），它要求数据包进入的接口必须与源地址的回程路由匹配，若网关配置有两个默认路由或目标地址不在该接口范围内，内核会直接丢弃回包，可临时执行 sysctl -w net.ipv4.conf.all.rp_filter=0 测试，若有效则在 /etc/sysctl.conf 中持久化配置，若不想动内核参数，换一个 IP 段重新配置虚拟机和宿主机虚拟网卡也能绕开此类问题。