虚拟机的网络到底通不通，根源不在虚拟机本身，而在虚拟网卡接入了哪条“链路”，以及宿主机和路由器是否认这条链路。很多人在配置虚拟机网络时，第一反应是去虚拟机里改IP，但真正决定成败的，是你在虚拟化平台里给网卡选择的“模式”桥接、NAT、仅主机，或者更进阶的PCIe直通与SR-IOV，搞懂这条链路怎么走，绝大多数网络故障都能自己排查清楚。
虚拟网卡三大模式：桥接、NAT、仅主机各自扮演什么角色
在动手改配置之前,先明确一件事：虚拟网卡不是一张独立的物理硬件，它是虚拟化层用软件“画”出来的一扇门，门后面连的是哪条路，决定了虚拟机的数据包怎么走。
桥接模式：让虚拟机在局域网里“隐身”成一台真机
桥接模式的工作原理,是在宿主机和物理交换机之间架了一座虚拟的“桥”，虚拟机的网卡直接挂在这座桥上，和宿主机物理网卡处于同一广播域里，行业共识认为，这是最接近物理机上网体验的模式。
在这种模式下,虚拟机需要自己配置一个和宿主机同网段的IP地址，网关指向你家里的路由器或公司的三层交换机，路由器不认识“虚拟机”这个概念，它只看到这个IP地址在局域网里发来了ARP请求，于是很自然地把它当成一台普通PC来对待，这意味着：
- 局域网内的其他设备可以直接访问虚拟机,比如用SSH远程连接，或者访问虚拟机里的Web服务
- 虚拟机上网不需要经过宿主机转发,性能损耗最低
- 如果虚拟机跑的是软路由、NAS这类需要对外提供服务的系统，桥接是最省事的方案
这里有一个新手容易踩的坑：桥接模式需要虚拟机的IP和宿主机IP在同一个网段，但它们的IP地址绝对不能一样，一旦重复，宿主机和虚拟机就会在局域网里“打架”（ARP冲突），导致两台机器轮流掉线，业内专家指出，排障时先拔掉虚拟机网卡，看宿主机网络是否恢复，是验证冲突最快的方法。
NAT模式：宿主机默默充当“内网出口”
NAT模式解决的是“虚拟机只要上网，但不想被局域网发现”的场景，VMware Workstation和VirtualBox里默认的NAT模式，实际上构建了一个非常隐蔽的“小内网”：虚拟化软件内置了一个虚拟路由器（比如VMnet8），它会给虚拟机分配一个类似168.137.x（VMware）或0.2.x（VirtualBox）的私有IP，然后通过宿主机物理网卡将数据包源地址改写后转发出去。
你可以把宿主机想象成网咖的门卫,虚拟机是里面的包间客人，客人想上网，得把请求递给门卫，门卫用自己的身份证（物理网卡IP）帮你开台电脑上网，回来再把结果拿给你，这个过程最关键的特点是：
- 宿主机是虚拟机的“出口网关”，虚拟机对外发出的所有请求，在目标服务器眼里都来自宿主机
- 局域网内其他设备无法主动访问虚拟机,因为虚拟机的IP地址是虚拟内网地址，路由器根本没有去往
0.2.x网段的路由 - 虚拟机可以上网、能访问互联网，但不能被外部设备直接访问
NAT模式最适合“我自己调试用”的场景，比如你在Windows上用VMware跑了一台Linux服务器练手，只需要它上网装包，不需要局域网里其他电脑连进来，用NAT最省心。
仅主机模式：彻底与世隔绝的封闭实验室
仅主机模式创建一个只有宿主机和该模式虚拟机才能识别的虚拟网络（如VMnet1），它不提供任何出站路由，虚拟机里配置的IP即使和局域网同网段，也访问不了外部网络，因为虚拟网卡背后的物理链路根本没接通。
这个模式的价值在于：一是做恶意软件分析时隔离样本，防止内网横向扩散；二是模拟纯离线环境测试依赖关系；三是搭建设备间两两通信的“隔音房”，避免局域网噪音干扰。
一句话概括三种模式的差异,可以看下面这个表格：
| 模式 | 虚拟机的IP来源 | 能否被局域网访问 | 是否需宿主机转发 | 典型用途 |
|---|---|---|---|---|
| 桥接 | 与宿主机同一网段 | 能 | 否 | 软路由、NAS、对外服务 |
| NAT | 虚拟网卡专用网段 | 否 | 是 | 日常练手、安全上网 |
| 仅主机 | 虚拟网卡专用网段 | 否（仅宿主机可访问） | 是（仅限宿主机） | 恶意样本分析、隔离调试 |
虚拟机网卡直通到底有什么用？为什么路由性能差时优先考虑它
前面说到的三种模式,都是让虚拟化层“代理”网络数据，如果虚拟机里跑的是依赖高吞吐或低延迟的应用（比如软件路由器OpenWrt、旁路由、网络抓包分析工具），这种代理模式就显得力不从心了，数据包经过的层数越多，延迟越高，CPU占用也越高，而且宿主机网卡的中断请求会争抢CPU时间片，导致虚拟机的网络延迟不稳定。
这时就该考虑虚拟网卡直通（PCIe Passthrough），直通的含义比较直接：把宿主机上的一个物理网卡端口，通过虚拟化管理程序（比如Proxmox VE、ESXi）直接“切”给某一台虚拟机独占使用，虚拟机里的配置说明显示，它看到的是一张完整的Intel I210或Realtek 8111实体网卡，而非虚拟化的e1000或virtio设备。
- 极限性能提升：测试环境下，直通网卡的线速转发能力接近物理机，消除了虚拟化层协议转换的损耗
- 独占性代价：这个物理网卡只能给这一台虚拟机用，宿主机自己都不能再通过这个网口上网
- 连接方式变化：如果这台虚拟机还想访问局域网，你需要把另一条物理网线插到这块直通网卡上，或者把宿主机的物理网卡做端口汇聚（bonding），再以虚拟交换机的方式分配给其他虚拟机
具体到路由场景,直通网卡最适合“软路由”虚拟机，比如用虚拟机跑一个OpenWrt来当主路由或旁路由，直通之后，WAN口和LAN口完全不受宿主机网络栈影响，拨号、PPPoE、QoS都能发挥物理网卡应有的水平，网络抓包时，直通网卡也能捕获到未经虚拟化层剥离VLAN标签的原始帧，同一台虚拟机内的抓包结果更真实，不过要注意，直通配置完成后，宿主机的管理网络不要依赖这块网卡，否则一旦直通，管理界面可能掉线（除非你有带外管理或第二个物理网口）。
如果想要更细粒度的性能调度,SR-IOV是中间路线，它不像直通那样整卡独占，而是把一个物理网卡虚拟成多个独立功能的VF（虚拟功能），每个VF可以单独分给一台虚拟机，性能远优于普通虚拟网卡，而且能在一台宿主机上同时给多台虚拟机提供高吞吐能力，适合网卡数量少、虚拟机多、且每台都有网络性能要求的场景，比如同时跑多台数据库或视频转码虚拟机。
为什么虚拟机网卡桥接模式设置后，宿主机反而访问不了虚拟机了？
这是运维中高频出现的问答化长尾场景,问题描述往往是：按照上面桥接模式的步骤设置妥当后，虚拟机能上网，但宿主机访问不了虚拟机的Web页面，甚至局域网里其他电脑也ping不通它。
排查思路很重要,这类问题十有八九出在“链路通了，防火墙挡了”或“IP没选对网卡”这两处。
第一层排查：看虚拟机网卡是否真的桥接到了正确的物理网卡上。 如果你宿主机同时插着有线网卡和无线网卡，而虚拟机桥接时选了有线网卡，但实际网络走的是Wi-Fi，数据包就发不出去了，在VMware里检查“虚拟机设置 -> 网络适配器 -> 自定义特定虚拟网络”，确认选择的是当前有网的桥接网络（比如VMnet0对应有线网卡），在变更网卡模式后，建议虚拟机里执行一次完整的网络重置：在CentOS/RHEL下重启NetworkManager或重启network服务，Ubuntu下执行sudo netplan apply，桥接模式下不可能通过DHCP自动获取到和宿主机一致的同网段IP，必须靠人工配置或在路由器里给这个新增网卡的MAC地址分配固定IP。
第二层排查：宿主机和虚拟机之间的“反向”链路是否畅通。 虚拟机里先临时关闭防火墙（Ubuntu命令sudo ufw disable，CentOS命令sudo systemctl stop firewalld），再让宿主机ping虚拟机的IP，如果通了，说明是防火墙规则挡了入站流量，如果ping不通，在虚拟机里用ip addr确认IP分配是否成功，用ip route看默认路由网关是否指向了路由器（需要确认虚拟机网卡配置的网关和宿主机物理网卡配置的网关完全一致），桥接模式下，你的虚拟机网关必须和宿主机物理网卡的网关一致很多人在这里会顺手把网关填成宿主机的IP地址，这是错误理解，网关应该填路由器/三层交换机的地址。
第三层排查：宿主机侧的虚拟交换机端口隔离设置。 在某些安全策略较严格的虚拟化平台（如VMware ESXi的标准交换机），如果启用了“端口组安全策略”里的“MAC地址欺骗”阻止，虚拟机发出的数据包会被已连接的上游交换机丢弃，桥接模式下虚拟网卡默认使用了宿主机物理网卡的MAC地址进行通信，如果平台禁止了这个行为，同样会导致网络不通，遇到这种情况，检查物理网卡的“混杂模式”和“MAC地址更改”策略是否设为接受。
虚拟机多网卡同时上内外网时，怎么保证路由不“打架”？
实际生产环境里,一台虚拟机同时配置两张网卡的情况非常多：一张接内网（公司OA、数据库），一张接外网（互联网、云服务），但如果两张网卡都设置了默认网关，系统就会犯难“你让我发给192.168.200.5的数据包，走哪条路由？”答案通常是走优先级最高的那条路由，另一条默认网关和它对应的网络就形同虚设，行业内把这种多网卡/IP路由冲突称为“多路由表拉扯”，处理不当会导致内部服务间歇性无法访问，异步流量来回路径不一致，甚至被安全设备判定为网络攻击。
解决办法：使用策略路由（Policy Routing），强制按源地址或源接口选择路由。 具体到Linux虚拟机（以Ubuntu 22.04为例），思路分两步。
先给两张网卡分别打标签（table编号），编辑/etc/iproute2/rt_tables文件，在文件末尾追加如：
200 inner
201 outer这与你去配置路由规则时的策略表描述一致,然后在网卡配置文件（Netplan的/etc/netplan/.yaml或/etc/network/interfaces）里，为内网网卡添加一条策略路由：所有源IP属于内网网卡的包，都走内网网关，执行类似命令：
ip rule add from 192.168.1.100 table inner
ip route add default via 192.168.1.1 dev eth0 table inner另一张外网网卡设置类似,只是把源IP替换为外网IP，网关换成路由器/运营商的网关，做完后，用ip rule show和ip route show table inner确认为已生效，测试时在虚拟机里先ping内网网关（确保走内网），再用curl访问外网网站（确保走外网），两条链路同时工作，互不干扰。
Windows虚拟机下的处理逻辑其实一样,在“网络连接”里设置两张网卡，然后打开cmd，使用route add -p 10.0.0.0 mask 255.0.0.0 10.0.0.1 metric 10手动添加一条永久的内网静态路由，外网流量则继续由默认网关交给路由器，关键点是：内网网卡的“自动跃点”设置为比外网卡低，或手动给内网静态路由一个更小的metric值，这样做完之后，业务系统访问内网走内网线，访问公网走外网线，不用改任何应用配置。
实战案例：一台Proxmox VE宿主机上的虚拟机网卡配置路径
纸上谈兵结束,我们以目前很多运维人员正在用的Proxmox VE（基于Debian的虚拟化平台）走一遍完整流程，场景：宿主机有一个物理网卡enp3s0，通过DHCP获取到168.1.10的IP，需要创建一台CentOS虚拟机，让它也能上网且被局域网直接访问。
第一步,创建虚拟机时，在“网络”选项卡选择“桥接”模型，并指定桥接名称为vmbr0，Proxmox默认安装时会自动创建一个名为vmbr0的Linux网桥，并把物理网卡enp3s0作为桥接端口挂进去，这就是桥接模式的核心载体你在虚拟机里看到的是虚拟网卡（如virtio或e1000），但在宿主机上，它实际是连接在vmbr0这座虚拟交换机上的。
第二步,配置虚拟机的IP，在CentOS里执行nmcli connection modify ens18 ipv4.addresses 192.168.1.20/24，网关指定为168.1.1（你家里/机房里路由器的IP），保存并激活连接：nmcli connection up ens18。
第三步,宿主机和局域网内其他PC分别ping虚拟机，如果ping不通，回到宿主机执行bridge link，查看虚拟机的vnet接口是否处于“UP”状态，如果显示state DOWN，说明虚拟机内部网卡还没有被正确激活，需要回到虚拟机系统里检查网卡配置文件或驱动加载情况，若“桥接接口没有转发数据包”，检查宿主机的vmbr0是否绑定了物理网卡的IP，有时物理网卡单独保留IP会导致路由指向异常，需要将IP绑定到vmbr0上，而不是enp3s0。
如果上述步骤全部无误,但虚拟机仍无法访问互联网，重点检查物理路由器是否开启了“DHCP snooping”或“端口安全”策略，桥接到无线网卡时尤其容易出现绑定问题（无线网卡在桥接模式下常因驱动/协议原因拒绝接受未知源MAC的数据包），这也是为什么多数专业级虚拟化部署都要求使用有线网卡。“配置环回”是一切链路诊断的起点虚拟机的lo接口ping不通任何东西，但确认它UP意味着IP协议栈本身没崩。
整个流程走下来你会发现：虚拟机网卡路由的核心思维，不是去虚拟机内部猜，而是先画一张从虚拟机到外部网络的“链路图”，然后逐跳检查，先把模式选对（桥接/NAT/仅主机），再确认网关指对，最后核查防火墙和安全策略，只要这三步思路清晰，绝大多数网络问题都能在十分钟内定位到根因。
Q&A
-
问：虚拟机里
ping不通外网，但宿主机能正常上网，问题出在哪？
答：优先确认网卡模式是否为NAT（虚拟机网关是否指向虚拟网卡的默认网关如0.2.2），或者桥接模式下虚拟机的IP和网关是否与宿主机在同一网段，其次检查虚拟机自身默认路由是否存在，执行ip route查看是否能找到default via条款，若仍不通，在宿主机上停用本机防火墙，排除其拦截转发流量，注意，IPv6链路故障也与路由表有关，检查是否有合法的IPv6默认路由。 -
问：如何选择虚拟机网卡直通还是SR-IOV？
答：取决于你对性能和灵活性的取舍，如果只需要一台虚拟机独占物理网卡的性能，且该网卡不用于宿主机管理，直通是首选，配置简单直接，如果有多台虚拟机都需要高速转发，且宿主机只有少数万兆网卡，SR-IOV能同时虚拟出多个VF分配出去，但需要网卡芯片支持（多数Intel X710、Mellanox ConnectX系列可以），也要在BIOS里开启VT-d和SR-IOV功能，行业共识认为，大多数云主机和边缘网关场景中，SR-IOV的无状态卸载能力在混合负载环境下表现更稳定。