登录虚拟机后网络不通，先别急着重装系统，绝大多数问题出在虚拟网卡状态、IP地址配置和网络服务这三个环节上。
vmware虚拟机登录后网络不通的常见原因
想象一下,你把物理机的网线拔了，电脑自然就上不了网，虚拟机也是这个道理，只不过它的“网线”是虚拟出来的，登录黑乎乎的终端界面，首先得搞清楚，虚拟机的网卡到底有没有“插好线”。
虚拟网卡处于未激活状态
很多Linux发行版为了省电或者出于安全考虑,默认不会把网卡设置为开机自启，你登录进去看到eth0或者ens33，但它的状态是DOWN，这就是最典型的“假死”状态，用ip addr命令看一下，如果网络接口下面没有inet这个IP地址，多半就是网卡没被拉起来。
IP地址配置与虚拟网络编辑器不匹配
VMware Workstation这类工具，默认有三种网络模式：NAT、桥接和仅主机，如果你在虚拟机里手动配了IP，但没跟虚拟网络编辑器里的网段对齐，那就像是把网线插到了错误的交换机端口上，怎么折腾都是白搭，行业共识认为，约莫一半的虚拟机网络故障，都源于这个底层配置的不一致性。
NetworkManager与network服务冲突
在CentOS或Rocky Linux这类系统上，NetworkManager和传统的network服务偶尔会“打架”，一个尝试用DHCP获取地址，一个坚持用静态配置，结果就是路由表混乱，表现为能ping通网关但上不了外网，这种问题隐蔽性很强，不看服务状态基本发现不了。
linux虚拟机网络连接失败怎么解决
排查的核心思路是从内到外,先看自己，再看邻居，最后才看门卫，照下面这个顺序来，能省下不少冤枉时间。
第一步：确认网卡和IP状态
登录系统后,先敲这个命令看看网卡叫什么名字，状态如何：
ip addr show
如果看到类似state UP的字样，说明网卡是活的，如果显示state DOWN，执行：
sudo ip link set ens33 up
这里ens33要替换成你实际看到的网卡名，让网卡通过DHCP获取地址：
sudo dhclient ens33
多数情况下，执行完这两步，虚拟机就能拿到一个内网IP了，之后再使用ping命令测试，比如ping 网关地址。
第二步：检查路由和DNS配置
光有IP还不够,你得告诉虚拟机怎么走到外网去，查看当前路由表：
ip route
输出里应该有一条default via 192.168.x.x的记录，如果只有/24这样的条目，却没有默认网关，那虚拟机就只知道怎么在局域网里串门，不知道怎么出门，这时候需要手动补上，以NAT模式为例，网关通常是以.2结尾的：
sudo ip route add default via 192.168.44.2
DNS的问题往往更隐蔽,能用ping 114.114.114.114但打不开网址，那就是DNS没配好，编辑/etc/resolv.conf，写入nameserver 223.5.5.5即可。解析速度和稳定性都算靠谱，作为临时测试完全够用。
第三步：重启网络服务
如果上述文件都没问题,那就是服务在闹脾气，在CentOS 7及以下版本，依次执行：
sudo systemctl restart network
在CentOS 8+或Rocky Linux中，更推荐用NetworkManager的命令：
sudo nmcli networking off sudo nmcli networking on
这一步会让所有网络接口重新走一遍初始化流程,相当一部分疑难杂症都能被这个“重启大法”解决。
第四步：核查虚拟网络编辑器设置
如果虚拟机内部折腾了一百遍还是不行,请把目光转回Windows宿主机，打开VMware的“编辑”菜单，进入“虚拟网络编辑器”。
- 确认
VMnet8（NAT模式）的子网IP与你虚拟机内配置的静态IP在同一网段。 - 检查“NAT设置”里的网关IP是否与虚拟机里的
gateway一致。 - 看看“DHCP设置”分配的地址范围是否包含了虚拟机的IP。
这里有个小技巧：如果你设置的是静态IP，最好关闭DHCP分配，把168.x.1到168.x.128的地址全留给静态设备，避免冲突。
不同虚拟化平台的网络调试差异
虽然都是“虚拟机”，但VMware、VirtualBox和KVM背后的网络实现机制各有不同，调测思路也要微调。
VMware Workstation的NAT模式
NAT模式是绝大多数用户的首选,因为它不占用物理网络段，不容易惹麻烦，VMware在背后做了一次“网络地址转换”，虚拟机发出去的包，到了宿主机这一层，会被重新伪装成物理机发出的包，这意味着，宿主机能上网，NAT模式下的虚拟机往往也能上网，即使Wi-Fi环境限制多，通常也能顺利连上。
| 对比项 | NAT模式 | 桥接模式 |
|---|---|---|
| 外网访问 | 依赖宿主机转发 | 独立获取局域网IP |
| IP冲突风险 | 低 | 高 |
| 宿主机防火墙影响 | 小 | 大 |
| 适合场景 | 单机学习、内网穿透 | 需要外面设备直接访问虚拟机 |
VirtualBox的Host-only网络
VirtualBox的“仅主机”模式，字面意思就是只能和宿主机通信，如果你在VirtualBox里选择了“Host-only”，又在虚拟机里设置了自动获取IP，很容易得到一个169.254开头的APIPA地址，这个地址是没法用来上网的，需手动在VirtualBox全局设定里找到“Host-only Networks”，记住那个网卡的IP，比如168.56.1，然后在虚拟机里配置成同一网段的静态地址。
KVM/QEMU环境的常见细节
KVM的虚拟网络通常由libvirt管理，如果你用virt-manager创建的虚拟机无法上网，先在宿主机上检查虚拟网桥：
brctl show virbr0
如果看到virbr0接口上没有IP地址，执行：
sudo virsh net-start default sudo virsh net-autostart default
很多KVM新手容易忽略这一层，以为装好虚拟机就算完事，结果虚拟网桥根本没启动。
防火墙与安全组策略的影响
有时候IP、路由全都正确，数据包就是出不去，那就要怀疑是防火墙在从中作梗了。
iptables与firewalld的排查要点
Linux防火墙分为iptables（旧）和firewalld（新）两代，排查时，先看看服务状态：
sudo systemctl status firewalld
如果服务在运行,可以临时关闭它来测试：
sudo systemctl stop firewalld
如果关闭防火墙后网络立刻恢复,那就说明规则里把流量拦死了。没必要一怒之下关闭防火墙，多数情况下是因为你没有放行对应端口，比如要放行SSH，就执行：
sudo firewall-cmd --permanent --add-service=ssh sudo firewall-cmd --reload
云服务器上的“安全组”逻辑也类似，酷番云、简米云的控制台里，安全组规则就像一个防盗门，即使操作系统里的防火墙全关了，安全组不放行，外网依然无法访问，许多场景下，用户折腾了半天的虚拟机网络问题，根源在云控制台的安全组没配流入规则。
登录虚拟机后网络修复的终极清单
排查来排查去,其实就那么几个坑，我把高频故障点和对应的快速修复合集整理成了一张表，建议截图保存。
| 故障现象 | 排查位置 | 快速修复命令/操作 |
|---|---|---|
| 网卡显示DOWN | 网卡状态 | sudo ip link set ens33 up |
| 没有IP地址 | DHCP服务 | sudo dhclient ens33 |
| 能ping通IP，但域名解析失败 | DNS配置 | 修改/etc/resolv.conf |
| 能ping通网关，但上不了外网 | 默认路由 | sudo ip route add default via 网关IP |
| 所有配置正确，仍无法通信 | 管理程序网络设置 | 重启VMware的虚拟网络编辑器 |
还有两个场景经常碰到,一是克隆虚拟机后网卡无法启动，这多半是克隆把UUID也复制了一份，导致冲突，解决方法是编辑/etc/default/grub，加上net.ifnames=0 biosdevname=0，然后重新生成grub配置，二是虚拟机里MTU值不对，如果内网有特殊网络设备，不妨把MTU值从1500改到1400试试看。
Q&A：登录虚拟机后的网络排查快问快答
virt-manager创建的虚拟机连不上网怎么排查？
先确保宿主机virbr0网桥处于激活状态并分配了IP，然后在虚拟机内部核对网卡是否处于连接状态，通过virsh domiflist查看虚拟机的网络接口是否映射到了default网络，若映射正常，再进入虚拟机用ip route查看默认路由，若缺失则手动添加指向168.122.1的默认网关。
云服务器登录虚拟机后网卡不显示IP是什么原因？
这种场景通常发生在OpenStack或KVM云平台上,多半原因是虚拟机内部的cloud-init未能正确执行，导致网卡没有触发DHCP请求，登录虚拟机，清空/etc/udev/rules.d/70-persistent-net.rules文件后重启网络服务，或者直接重启虚拟机，让systemd重新生成网络接口配置，若依然没有地址，可在VNC控制台里手动执行dhclient确认网络底层链路是否通畅。
重置虚拟网络设置会影响里面已有的数据吗？
不会,虚拟网络设置只涉及网卡如何连接到物理网络，与虚拟机硬盘上的数据是两套独立体系，即使是把VMware的NAT网络直接删除重建，也不会删掉虚拟机里的任何文件，只会导致短时断网，重建网络后，确保虚拟机的网络模式重新选对即可恢复连接，若网卡设备的MAC地址被调整过，虚拟机内部可能需重新激活一次网卡连接。