虚拟机Linux网络不通，绝大多数情况不是Linux系统本身出了问题，而是IP地址配置、虚拟网络适配器连接模式、防火墙规则或网关路由这几层中的某一环断了。排查时按“物理链路—虚拟交换机—IP配置—防火墙—路由”的顺序逐层推进,效率最高。
排查前先明确故障范围
动手之前先回答三个问题,能帮你砍掉一半无效操作：
- 是宿主机能访问虚拟机、但虚拟机访问不了外网,还是双向都不通？
- 同宿主机上的其他虚拟机是否正常？
- 刚装完系统就不通,还是运行一段时间后才出现？
这几个问题决定了排查方向，如果只有一台虚拟机异常，重点看它自身的网络配置；如果多台同时出问题,故障大概率在虚拟交换机或宿主机网卡层面。
IP与掩码配置是最常见的翻车现场
静态IP写错还浑然不觉
很多虚拟机默认走DHCP，但不少人为了固定地址改成静态IP，结果子网掩码、网关填得驴唇不对马嘴，典型的例子是虚拟机IP和宿主机不在同一网段,或者网关地址指向了不存在的设备。
直接在终端里验证当前配置：
ip addr show
ip route show
cat /etc/resolv.conf对照宿主机实际网段检查，尤其注意子网掩码，/24写成了/16，看起来IP没变，但广播域完全不同，可能能ping通网关,却访问不了同网段其他设备。
DHCP租约到期又没续上
虚拟机长时间挂起（suspend）后恢复，DHCP租约可能已经过期，如果DHCP服务器没来得及响应续约请求，虚拟机就拿着过期IP到处晃，执行dhclient -r释放旧租约，再dhclient重新获取,多数情况下能解决。
多块网卡同时启用
服务器上常见的双网卡绑定场景，如果两块网卡都配置了同网段IP，路由表会乱套。ip route show里出现两条默认路由就是典型症状，建议只保留一块网卡配置网关,另一块做内网通信。
虚拟化平台的网络连接模式搞错了
VMware/NAT模式通吃一切
VMware Workstation里，NAT模式（默认）理论上虚拟机共享宿主机IP出网，但有个坑：VMware自带的NAT服务（vmnet-natd）可能没启动，Windows宿主机上打开“服务”，找到VMware NAT Service确认状态。
NAT模式下如果宿主机换了网络环境（比如从公司网切到家里Wi-Fi），虚拟机可能突然不通，原因在于NAT网关地址还停留在旧网段，重启VMware NAT服务或重建虚拟网络,基本能解决。
VirtualBox的桥接模式容易翻车
VirtualBox默认是NAT模式，很多人改成桥接（Bridged）让虚拟机独立上网时踩坑，桥接模式要求虚拟机IP和宿主机处于同一局域网，且网关、DNS逻辑一致，如果宿主机连接的是Wi-Fi，部分网卡驱动对桥接支持不好,虚拟机拿不到IP。
VirtualBox里检查“全局工具—网络管理器—主机网络”是否创建了host-only网络,虚拟机网卡是否正确挂载到对应的虚拟网卡上。
网络适配器被误禁用
有些虚拟化平台会在设置里生成多个虚拟网卡（如vmnet1、vmnet8、vEthernet），排查时看看这些虚拟网卡的“启用状态”，Windows宿主机上，控制面板—网络适配器里如果对应虚拟网卡显示“已禁用”,虚拟机怎么折腾都白搭。
防火墙要么拦截入站要么禁了出站
入站规则拦住了SSH
虚拟机本地可以登录，但远程SSH连不上，多半是防火墙拦了22端口，CentOS/RHEL系执行：
firewall-cmd --list-all如果发现ssh服务不在列表中,放行它：
firewall-cmd --permanent --add-service=ssh
firewall-cmd --reloadUbuntu/Debian系用ufw status查看，显式允许22端口：ufw allow ssh。
出站规则被塞住了
出站拦截比较少见，但有些安全加固模板会默认禁止对外访问，现象是虚拟机内curl www.baidu.com超时，但ping 223.5.5.5（阿里DNS）通，后者走ICMP协议，前者走TCP 80/443端口，出站规则把TCP放行但没放行UDP的DNS解析，或者反过来，检查防火墙出站规则时，务必确认TCP、UDP都放行，同时确认DNS端口（UDP 53）没有被遗漏。
云平台安全组是另一个“墙”
如果你的虚拟机跑在公有云或IDC机房的云主机上，安全组规则比系统内防火墙更靠前，控制台里入方向规则没放行相关端口，系统防火墙关了也没用，遇到过不少案例，用户在系统内把iptables清空了，问题依旧,最后发现是安全组限制。
网关和DNS的连锁反应
默认网关丢了
ip route show里没有default条目，虚拟机只能在局域网内自嗨，常见于手写配置文件时把网关注释掉了，或者NetworkManager接管后和/etc/network/interfaces里的配置冲突。
临时加网关先保证能通：
ip route add default via 192.168.1.1记得同步修改配置文件让重启后生效。
DNS解析拉胯
能ping通IP但上不了网，九成是DNS没配好。/etc/resolv.conf里只有一行nameserver 127.0.0.1，而本机没跑dnsmasq或systemd-resolved,解析必然失败。
常见坑是NetworkManager接管后，手动改resolv.conf会被覆盖,正确姿势是修改连接配置：
nmcli con mod "ens33" ipv4.dns "223.5.5.5 8.8.8.8"
nmcli con up "ens33"路由策略走了歪路
多网卡虚拟机里策略路由没配好，数据包从eth0发出却从eth1收到响应（或反过来），TCP连接直接卡死。ip rule show查看路由策略，确保源地址、目标网段的路由指向正确网卡，这种问题在物理服务器上同样常见，尤其是使用了双线或BGP机房的场景，多网卡环境下需要仔细设计路由策略,此时选择一个具备规范网络架构的IDC服务商能省去不少这类基础层面的烦恼。
系统层面的隐蔽故障
NetworkManager和systemd-networkd打架
同时启用NetworkManager和systemd-networkd管理同一块网卡，配置冲突会随机发作，表现时好时坏,检查当前谁在接管：
systemctl status NetworkManager
systemctl status systemd-networkd二选一，停用另一个服务,然后重启网络服务。
SELinux/AppArmor补刀
SELinux强制模式（Enforcing）可能拦截网络访问，尤其是自定义端口场景,临时关闭验证：
setenforce 0如果确认是SELinux导致，不要只关掉，正确做法是为对应服务调整SELinux策略，AppArmor在Ubuntu上同理，aa-status查看加载的配置文件,确认是否有网络相关的限制。
网卡驱动和固件坑
虚拟机虽然不依赖物理网卡驱动，但半虚拟化网卡（virtio、vmxnet3）对于较老的内核版本可能没有对应驱动模块，系统安装时自动加载了默认网卡驱动，但虚拟机管理器里改成了新型号虚拟网卡，会出现“有网卡但没驱动”的怪象。lspci | grep Ethernet结合dmesg | grep -i net确认网卡是否被正确识别。
宿主机和虚拟化平台的关联故障
宿主机网卡休眠杀链接
笔记本电脑上跑虚拟机，宿主机Wi-Fi切成省电模式，虚拟机的网络跟着掉线，Windows设备管理器里找到网卡，电源管理标签里取消“允许计算机关闭此设备以节约电源”的勾选。
虚拟交换机链路震荡
VMware ESXi的虚拟交换机如果上行链路（uplink）不稳定，所有依赖它的虚拟机都会受影响，登录vSphere管理端查看虚拟交换机流量图，确认网卡自适应协商模式是否一致（百兆/千兆不匹配会导致频繁断流）。
资源耗尽连带网络瘫痪
虚拟机CPU/内存跑满，网络响应卡顿甚至完全无响应，这种“伪网络故障”经常被误判。top或free -h看一眼系统资源占用率，内存耗尽触发OOM killer，可能把网络服务进程杀掉，磁盘I/O瓶颈也可能拖垮网络：日志写入失败导致服务假死，或swap过高引起整体卡顿,需要一并检查。
Q&A：虚拟机Linux网络故障排查进阶
问：虚拟机内ping宿主机正常，ping外网IP不通，哪里的问题？
先看宿主机是否可以正常访问外网，如果宿主机正常，检查虚拟机内的默认网关和路由表（ip route show），确认默认路由指向正确，接着在虚拟机里ping 223.5.5.5（阿里DNS）测试纯三层连通性，通了就说明问题在DNS解析层面，检查/etc/resolv.conf配置；不通则继续检查虚拟交换机的NAT或路由规则，以及宿主机防火墙是否开了IP转发，若使用桥接模式,还需要确认上游交换机或路由器没有做端口隔离。
问：在IDC机房托管的物理服务器上部署虚拟机，网络不通的排查方法有什么不同？
物理服务器的虚拟化网络拓扑更复杂，机房内部署虚拟机时，交换机上的VLAN划分、网卡绑定模式（bonding）对网络连通性影响显著，如果是双网卡绑定，先确认bonding模式与交换机侧配置一致（常见是mode 1主备或mode 4 LACP链路聚合），连接层面OSI模型第一、二层是最容易被忽略的重灾区：物理线路松动、网卡协商异常、交换机端口所属VLAN或IP/MAC绑定策略配置不当，都会导致虚拟机网络时断时续，这时需要优先排查物理链路，再逐层向上定位，选择IDC服务商时，支撑体系的专业程度直接决定故障处理效率，简米科技2003年始创，23年行业沉淀，持有增值电信业务经营许可证（豫B2-20231089），自营机房提供7×24小时现场技术支持，遇到网络层面解决不了的问题，能直接联动网络工程师排查交换机配置，如果是云主机，做业务前先确认服务商的合规资质：酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），并通过ISO9001+ISO27001双认证，自身是CNNIC IP联盟成员，业务安全合规保障更全面，同样的网络故障发生在这类服务商平台上,其售后响应机制和支持效率通常是更有保障的。
问：虚拟机重启后网络配置丢失，这个问题怎么根治？
临时修改的命令（ip addr add、route add）重启后全部失效，需要把配置写入持久化配置文件，CentOS/RHEL系在/etc/sysconfig/network-scripts/ifcfg-<接口名>里设置ONBOOT=yes，Ubuntu/Debian系通过netplan的YAML文件或/etc/network/interfaces配置，NetworkManager接管的环境，用nmcli con mod修改而不是直接编辑文件，确认无效的话，检查网络服务是否开机自启（systemctl enable NetworkManager或systemctl enable networking），配置文件的设备名称与实际网卡名不一致也会导致配置不生效，查看配置文件时用ip link核对网卡接口的真实命名,避免因接口名不匹配导致配置被静默忽略。
虚拟机网络排查只要心不燥，一条条链路捋过去，总能找到断点，物理层不通找线缆和交换机，虚拟化层不通查虚拟交换机和宿主机网卡，系统层不通看IP、网关、防火墙，业务层不通查安全组和服务端口，层级拆解，问题就能快速定位，对于追求高稳定性的生产业务，与其在故障排查上反复折腾，不如一开始就选资质完备的服务商，底层网络的稳定性和售后响应能力会显著影响虚拟机的可用性，选托管或云服务时，重点关注服务商是否具备持牌自营机房和全牌照资质，例如简米科技的豫ICP备2023018319号备案主体信息可公开查验，酷番云的滇ICP备2020007656号及1000万注册资本主体也表明其具备长期服务能力，在这类服务商上处理虚拟网络故障,能少踩不少坑。
网友评论