1. 先把 NAT 模式这条链路的真实结构搞清楚Ubuntu 24.04 虚拟机网络连不上绝大多数人第一反应是虚拟机里网卡没配好然后一头扎进 netplan 里反复改改到怀疑人生。我踩过太多这种坑之后发现一个规律NAT 模式下的断网故障点分布在整个链路上虚拟机内部只是其中一环而且往往是最不容易出问题的那一环。Ubuntu 24.04、NAT 模式、虚拟机网络这几个词摆在一起真正难的不是配置本身是搞清楚哪一段断了。NAT 模式的本质是在宿主机上跑了一个软件路由器和一个小型 DHCP/DNS 服务虚拟机发出的包先交给这个软件路由器由它做地址转换后借用宿主机的物理网卡出去。回来的时候再按连接记录反向还原。这个模型意味着宿主机上的虚拟网卡必须是启用状态、后台的服务进程必须活着、虚拟子网不能和宿主机所在的真实网段撞车、虚拟机必须能拿到同一网段的地址、DNS 请求必须能被正确转发。任何一环断掉表现都是上不了网但修法完全不同。这篇内容适合三类人刚在本地搭好 Ubuntu 24.04 做开发环境、第一次遇到 NAT 连不上网的新手已经会改 netplan 但总在改了没用、重启又坏之间反复横跳的中间用户以及需要给团队写一份可复用的环境排查手册的人。我会按真实排查顺序把五种最常见的故障逐条拆开每一种都给出判断依据、修复动作和背后的原因参数怎么算、配置为什么这么写都会讲明白。文中的命令可以直接复制路径和网段按你自己环境里的实际情况替换。2. 排查前的五分钟准备把玄学变成可验证的证据2.1 分层自检清单从上往下捋一遍虚拟机网络排查最忌讳乱试。我的习惯是固定按宿主机服务 → 宿主机虚拟网卡 → 虚拟子网配置 → 虚拟机网卡识别 → IP 与网关 → DNS这个顺序走每层只问一个问题这一层的地基在不在。先说结论式的判断方法你照着敲几条命令基本三分钟就能定位到断在哪一层。先看虚拟机里网卡有没有被系统认出来ip -br link ip -br addr ip routeip -br link输出里如果只有lo说明虚拟网卡压根没被识别问题在虚拟化层或者驱动层跟你改 netplan 一点关系都没有。如果能看到ens33、ens160之类的名字但状态是DOWN那是链路没起来。如果有地址、有默认路由那虚拟机内部基本是好的问题在宿主机或者上游。再看这三个命令的输出我一般会拿张纸记下来检查项命令期望结果网卡是否识别ip -br link出现 ens33 或 ens160状态 UP是否拿到地址ip -br addr有 192.168.x.x/24 或 10.0.2.15/24默认网关是否存在ip route有default via 192.168.x.2之类的行网关是否可达ping -c 3 网关IP通外网 IP 是否可达ping -c 3 223.5.5.5通域名是否可解析getent hosts archive.ubuntu.com返回 IP这张表的价值在于它把上不了网这个模糊描述切成了六个可以独立回答的是非题。网关通、外网 IP 不通说明 NAT 转换没生效外网 IP 通、域名解析不出来那就是纯粹的 DNS 问题网关都不通直接去看宿主机虚拟网卡和虚拟网络编辑器。很多人的时间浪费在外网不通就去改 DNS这种错位操作上。2.2 先确认宿主机侧的地基再动虚拟机在动手改任何配置文件之前我强烈建议先在宿主机上确认三件事虚拟网卡是否启用、后台服务是否运行、虚拟子网是什么。这三个信息决定了后面所有配置的取值。Windows 宿主机上Win R输入ncpa.cpl打开网络连接面板找到名字类似VMware Network Adapter VMnet8的那块网卡。它必须是已启用状态禁用状态下虚拟机和宿主机之间的软件路由器链路就是断的虚拟机里怎么配都没用。这块网卡的 IP 通常就是 NAT 子网的网关地址比如192.168.142.1而虚拟机侧的网关往往是192.168.142.2这两个不要搞混。接着按Win R输入services.msc找两个服务VMware DHCP Service和VMware NAT Service。这两个必须处于正在运行且启动类型为自动。我遇到过不止一次某个安全软件清理后台进程时把它们设成了手动重启后虚拟机就再也上不了网而虚拟机内部一切正常。打开虚拟网络编辑器在虚拟机软件的编辑菜单里需要管理员权限选中 NAT 模式那一行点NAT 设置能看到网关地址点DHCP 设置能看到地址池范围。把这两组信息记下来后面配静态 IP 的时候要用。提示虚拟网络编辑器的改动需要点应用才生效而且有概率触发一次虚拟网络的重新加载正在运行的虚拟机会短暂断网操作前最好先把虚拟机挂起或者关掉。Linux 宿主机上则是另一套东西用ip addr看有没有vmnet8接口用systemctl status查对应的服务单元NAT 转发依赖内核的转发开关和iptables/nftables的伪装规则sysctl net.ipv4.ip_forward必须返回 1。这块内容展开会很长本文主要以 Windows 宿主机为主线因为这是绝大多数人的实际场景。3. 问题一虚拟网卡被禁用或后台服务没启动3.1 症状特征虚拟机内有地址但网关完全不通这是最高频的一类也是最容易被误判的一类。典型表现是虚拟机里ip addr能看到192.168.x.128/24这样的地址看起来一切正常但ping 192.168.x.2直接 100% 丢包或者返回Destination Host Unreachable。这时候很多人会去怀疑防火墙、怀疑 ip_forward、怀疑内核模块其实九成以上是宿主机侧那块虚拟网卡被禁用了或者 DHCP/NAT 服务挂了。判断方法很简单在宿主机上ping虚拟机的 IP。如果宿主机 ping 不通虚拟机而虚拟机自己也 ping 不通宿主机上的 VMnet8 地址那基本可以确定是虚拟链路层断开。再去看网络连接面板里那块网卡的图标是不是灰色的已禁用服务列表里那两个服务是不是停了答案立刻就出来了。还有一种变体网卡是启用的但被设成了公用网络配置文件Windows 防火墙对公用网络默认策略更严格会拦掉入站的 ICMP 和一些转发流量。这时候表现为虚拟机 ping 宿主机通、宿主机 ping 虚拟机不通或者反过来。把 VMnet8 这块网卡的防火墙配置文件切成专用通常就能解决但我一般建议更干脆的做法在防火墙的入站规则里直接放行 VMnet8 这块网卡的全部流量因为它是纯内部的虚拟链路不涉及对外的暴露面。3.2 修复动作与背后的原因修复顺序我建议这样走。先启用网卡网络连接面板里右键 VMnet8 → 启用等十秒钟让系统重新加载驱动和 DHCP。再启动服务services.msc里把VMware DHCP Service和VMware NAT Service都启动并把启动类型改成自动。最后在虚拟机里重新触发一次 DHCP 请求sudo dhclient -r ens33 # 释放旧租约 sudo dhclient -v ens33 # 重新获取-v 会打印完整过程-v参数很关键它会实时打印 DHCP 的四次握手过程。如果看到DHCPDISCOVER发出去之后一直没有DHCPOFFER回来说明请求根本没到 DHCP 服务问题在链路层如果收到了 OFFER 但后续 REQUEST/ACK 失败那可能是地址池耗尽或者租约冲突。这个输出比任何日志都直观。为什么禁用网卡会导致这么彻底的不通因为 NAT 模式的软件路由器是绑定在这块虚拟网卡上的网卡一禁用相当于把路由器的一个物理端口拔了。虚拟机和宿主机之间的二层通路断了DHCP 请求自然发不出去NAT 转换也无从谈起。这不是配置错了是线路断了所以改 netplan 一万遍也没用。注意有些优化类工具会把VMware NAT Service判定为不常用后台服务并禁用它装完系统或者做完整理之后建议顺手确认一下这两个服务的状态这是我见过最隐蔽的复发原因。4. 问题二虚拟子网和宿主机真实网段撞车4.1 怎么判断是网段冲突而不是配置错误如果你在公司网络或者某些特殊的路由环境下用虚拟机这个坑几乎是必踩的。表现很有迷惑性虚拟机拿到地址了网关也 ping 得通但就是上不了外网ping 223.5.5.5全部超时traceroute出去第一跳之后就没了。或者更诡异能上网但访问公司内网的某个服务时流量跑到了虚拟机内部而不是走真实网络。原因不复杂。NAT 模式默认的子网经常是192.168.142.0/24这类而很多企业内网、家用路由器的网段也是192.168.1.0/24、192.168.0.0/24甚至有些环境直接用192.168.142.x。一旦 NAT 子网和宿主机所在的物理网段重叠宿主机的路由表就会出现两条指向同一网段但出口不同的路由谁优先级高谁说话结果是流量走错地方NAT 转换自然失败。判断方法在宿主机上执行ipconfigWindows或ip routeLinux看物理网卡的网段是什么再去虚拟网络编辑器里看 VMnet8 的子网是什么。如果前三段相同或者两个网段能互相包含那就是冲突了。还有一个更直接的验证方法在宿主机上ping虚拟机的 IP如果 ping 不通而虚拟机自己ping自己的网关也不通同时宿主机物理网段又和虚拟子网撞了基本可以确诊。4.2 改子网的完整操作与参数计算改法是在虚拟网络编辑器里选中 NAT 那一行点更改设置需要管理员权限把子网 IP 改成一个不冲突的段比如192.168.188.0子网掩码255.255.255.0。虚拟机会自动把网关设成.2把 DHCP 池设成.128到.254。这里有几个参数值得算一下不然容易踩第二个坑。掩码255.255.255.0对应/24可用地址是.1到.254。虚拟网络编辑器默认的分配约定是.1给宿主机侧的 VMnet8 网卡.2给 NAT 网关.3到.127一般留给静态地址手工使用.128到.254给 DHCP 动态分配。所以你如果打算给虚拟机配静态 IP最好落在.10到.100这个区间既避开了网关和宿主机网卡也避开了 DHCP 池不会出现地址被抢的情况。改完子网之后虚拟机的旧地址会失效需要重新拿一次地址。这时候我一般会顺手做一次完整复位sudo ip addr flush dev ens33 sudo dhclient -r ens33 sudo dhclient -v ens33 ip -br addr ip route如果虚拟机里还残留着旧网段的路由比如default via 192.168.142.2新的 DHCP 拿到的地址和网关会和旧路由打架表现为能 ping 通新网关但上不了网。ip route的输出里如果出现两条 default 路由用sudo ip route del default via 旧网关删掉多余的那条或者干脆重启虚拟机让网络栈重新初始化。提示改完子网后如果你之前给虚拟机配过静态 IPnetplan 或者 NetworkManager 里的旧配置不会自动跟着变。要么同步改成新网段要么切回 DHCP别指望它自己适应。这是很多人改完子网还是不通的真正原因。5. 问题三Ubuntu 24.04 的网络管理栈踩坑5.1 24.04 桌面版和服务器版的管理方式不一样这个问题在 24.04 上格外突出因为同一个版本号下桌面版和服务器版的网络管理栈是不同的。桌面版默认用 NetworkManagernetplan 里的 renderer 一般写着NetworkManager配置文件通常是/etc/netplan/01-network-manager-all.yaml这种服务器版默认用systemd-networkd配置文件往往由 cloud-init 生成路径是/etc/netplan/50-cloud-init.yaml。区别在哪如果你照着网上某篇老教程去改50-cloud-init.yaml但你的系统是桌面版、实际生效的是 NetworkManager那改了等于没改netplan apply之后看着没报错重启又回到原样。反过来服务器版你去用nmcli命令配那也是白费力气因为 NetworkManager 根本没在跑。先确认自己在哪个栈上ls /etc/netplan/ cat /etc/netplan/*.yaml systemctl is-active NetworkManager systemd-networkd systemd-resolved如果NetworkManager是 active、systemd-networkd是 inactive那就走 NetworkManager 那条路。如果反过来就走 networkd。两个都 active 的情况也有通常是桌面版装了服务器组件这种时候以 netplan 里写的 renderer 为准不一致就会出现命令生效了但配置被覆盖的诡异现象。5.2 三种典型写错方式和一份可抄的配置第一种错法是 YAML 缩进。netplan 的配置文件用的是 YAML缩进只能用空格不能用 Tab而且层级必须严格对齐。多一个空格少一个空格都会导致解析失败。好在netplan有内置的检查命令sudo netplan generate # 只做语法和语义校验不应用 sudo netplan try # 应用并给 120 秒确认窗口超时自动回滚 sudo netplan apply # 直接应用我强烈推荐用netplan try而不是直接apply尤其是远程连着的机器。它会先应用配置然后等你在终端里按回车确认120 秒内不确认就自动回滚到之前的配置。这在改网络配置时等于一个免费的安全网改错了不会把自己锁在外面。第二种错法是gateway4这个字段。24.04 里它已经被标记为废弃虽然有些情况下还能用但会打印警告而且在某些版本上直接不生效。正确的写法是用routes配默认路由。第三种错法是把dhcp4: true和静态addresses同时写在一个接口下两者冲突实际行为取决于版本很容易出现地址有了但网关没有的半残状态。一份 DHCP 场景下可以直接抄的配置长这样文件名建议/etc/netplan/01-netcfg.yamlnetwork: version: 2 renderer: NetworkManager ethernets: ens33: dhcp4: true dhcp4-overrides: use-dns: true use-routes: true optional: trueoptional: true这个字段值得单独说一句。它表示这块网卡没起来也不阻塞开机流程对于虚拟机环境很有用避免因为网络初始化慢导致开机卡在等待网络那一步。dhcp4-overrides里的use-dns和use-routes是告诉系统接受 DHCP 服务器下发的 DNS 和路由默认就是 true但有些精简镜像会关掉显式写一遍更保险。静态 IP 的版本则是network: version: 2 renderer: NetworkManager ethernets: ens33: dhcp4: false addresses: - 192.168.188.50/24 routes: - to: default via: 192.168.188.2 metric: 100 nameservers: addresses: [223.5.5.5, 119.29.29.29] optional: true写完sudo chmod 600 /etc/netplan/01-netcfg.yaml权限不对 netplan 会拒绝读取这是很多人漏掉的一步。然后sudo netplan try确认没问题再回车。注意如果系统是服务器版且用了 cloud-init它会在每次启动时重新生成/etc/netplan/50-cloud-init.yaml把你的手动修改覆盖掉。解决办法是新建一个编号更小的文件比如01-netcfg.yaml或者在/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg里写一行network: {config: disabled}把 cloud-init 的网络配置彻底关掉二选一即可。5.3 网卡名字对不上是个隐形杀手Ubuntu 24.04 用的是可预测网卡命名名字可能是ens33、ens160、enp0s3、enp3s0取决于虚拟化平台和固件。如果你从别处抄了一份配置里面写的是ens33而你实际的网卡叫ens160netplan 不会报错只会默默忽略这个不存在的接口结果就是配置应用成功了但网络一点变化都没有。确认名字的方法就一条ip -br link看第二列。改配置之前先把这个名字抄下来再往 YAML 里填。这个低级错误我见过太多次而且它特别难自查因为整个过程没有任何报错提示。6. 问题四DHCP 拿不到地址或者拿到了但网关是错的6.1 租约冲突与地址池耗尽DHCP 相关的问题有两类典型表现。一类是ip -br addr里只有127.0.0.1网卡状态是 UP 但没有 IPv4 地址反复重启也不见好转。另一类是有地址但地址是169.254.x.x开头的这是链路本地地址意思是我发了 DHCP 请求但没人理我系统自己给自己分了个临时地址。第一类情况先看 DHCP 服务。宿主机上服务停了、地址池改小了、或者虚拟网络编辑器里的 DHCP 被取消勾选了启用都会导致这个结果。第二类情况除了服务没起还有一个隐蔽原因地址池耗尽。默认池是.128到.254127 个地址听起来很多但如果你的虚拟机做过大量克隆、每个克隆都占一个租约池子是会满的。这时候把租约时间改短或者在虚拟网络编辑器里点恢复默认设置重置一下通常就好了。还有一个特别容易被忽略的点虚拟机克隆。克隆出来的虚拟机如果保留了原来的 MAC 地址两台机器会抢同一个 DHCP 租约表现为有时候能上网、有时候不能或者两台机器轮流断网。检查方法是对比两台机器的ip link show ens33输出里的link/ether字段如果一样就得改。VMware 在克隆时一般会问你要不要重新生成 MACVirtualBox 则需要在虚拟机设置的高级选项里点一下重新生成。已经克隆完的手工改 MAC 或者在虚拟机设置里重新生成都可以。6.2 手工验证与恢复流程我习惯的恢复流程是这样的按顺序执行每一步都看输出sudo ip link set ens33 up sudo ip addr flush dev ens33 sudo dhclient -r ens33 sudo timeout 30 dhclient -v ens33 ip -br addr show ens33 ip route show defaulttimeout 30是为了避免 dhclient 卡死在那儿一直等。-v的输出里重点看四行DHCPDISCOVER on ens33 to 255.255.255.255 port 67、DHCPOFFER of 192.168.x.x from 192.168.x.x、DHCPREQUEST、DHCPACK。四个都齐了说明 DHCP 链路完全正常问题在别处缺了 OFFER说明请求没被响应去看宿主机服务和虚拟网络编辑器的 DHCP 设置有 OFFER 但没 ACK多半是租约冲突或者服务端拒绝了请求。如果 DHCP 怎么都救不回来临时方案是直接配静态 IP 应急。拿到网关地址虚拟网络编辑器的 NAT 设置里看选一个池外的地址手工加上sudo ip addr add 192.168.188.50/24 dev ens33 sudo ip route add default via 192.168.188.2 dev ens33 echo nameserver 223.5.5.5 | sudo tee /etc/resolv.conf这套命令是临时的重启就没了但能让你先把活干完回头再慢慢修 netplan。我在赶项目的时候用过好几次这种先通再修的路子比死磕配置文件效率高得多。提示手工改/etc/resolv.conf在 Ubuntu 24.04 上大概率会被systemd-resolved覆盖回去因为那个文件通常是个指向/run/systemd/resolve/stub-resolv.conf的软链接。临时用可以长期方案见下一节。7. 问题五能 ping 通 IP 却打不开网页DNS 链路排查7.1 systemd-resolved 与 resolv.conf 的真实关系这一类故障的表现特别有辨识度ping 223.5.5.5通ping archive.ubuntu.com提示Temporary failure in name resolutionapt update卡在Waiting for headers或者直接报解析失败。这说明 IP 层完全正常问题出在域名解析。Ubuntu 24.04 的 DNS 解析走的是systemd-resolved/etc/resolv.conf默认是个软链接指向/run/systemd/resolve/stub-resolv.conf里面写的 DNS 服务器是127.0.0.53这是本地的一个存根解析器真正的上游 DNS 由 resolved 管理。所以你在/etc/resolv.conf里手写nameserver 8.8.8.8重启或者网络重连之后就会被覆盖回去白改。先看现状ls -l /etc/resolv.conf resolvectl status systemctl status systemd-resolved --no-pagerresolvectl status会打印每块网卡当前使用的 DNS 服务器、DNS 域和 DNSSEC 状态。如果Current DNS Server那一栏是空的或者指向一个根本不可达的地址比如宿主机内网某个你已经离开的 DNS那问题就找到了。7.2 三种让 DNS 永久生效的写法第一种也是最推荐的写进 netplan 配置。静态 IP 场景下直接在nameservers里写nameservers: addresses: [223.5.5.5, 119.29.29.29] search: []DHCP 场景下如果 DHCP 服务器下发的 DNS 不对NAT 模式下通常下发的是宿主机那个虚拟网关地址理论上它能转发 DNS但有时会失效可以覆盖掉dhcp4-overrides: use-dns: false nameservers: addresses: [223.5.5.5, 119.29.29.29]配合sudo netplan apply这是最干净的做法重启不丢。第二种用resolvectl直接给网卡设 DNS临时用sudo resolvectl dns ens33 223.5.5.5 119.29.29.29 sudo resolvectl domain ens33 ~. sudo resolvectl flush-caches~.这个域配置的意思是所有域名都走这块网卡的 DNS加上它才能覆盖默认的路由域逻辑。flush-caches清掉之前的错误缓存不然改了 DNS 还是解析不了容易让人以为没生效。第三种如果你就是想让/etc/resolv.conf变成普通文件、自己完全掌控sudo rm /etc/resolv.conf sudo tee /etc/resolv.conf EOF nameserver 223.5.5.5 nameserver 119.29.29.29 EOF sudo chattr i /etc/resolv.conf # 加不可变属性防止被覆盖chattr i这步要谨慎加了之后谁都改不了包括你自己将来想改要先chattr -i。我一般不建议这么干除非是固定用途的测试机。正常场景用 netplan 那一套就够了。还有一个容易忽略的分支DNSSEC 校验失败。有些环境里上游 DNS 的响应过不了 DNSSEC 验证表现为部分域名解析失败、部分正常。resolvectl status里能看到DNSSEC supported: yes如果怀疑是这个原因可以在 netplan 里加dhcp4-overrides之外的配置关掉它或者用resolvectl临时设置。这个坑比较深一般环境碰不到但一旦碰上特别耗时间因为看起来完全不像 DNS 问题。8. 那些容易被忽略的次级原因8.1 MTU、IPv6 优先级和时间不同步MTU 问题在 NAT 模式下不算高频但表现极其迷惑小包能通大包不通。具体就是ping网关没问题ping外网 IP 也没问题但apt update、打开网页、git clone全部卡住不动。原因是路径上某一跳的 MTU 小于 1500而虚拟机发出的包被标记了不分片大包直接被丢弃小包正常通过。验证方法ping -c 2 -M do -s 1472 223.5.5.5 ping -c 2 -M do -s 1400 223.5.5.5-M do是禁止分片-s 1472加上 28 字节的 IP/ICMP 头正好是 1500。如果 1472 不通而 1400 通说明路径 MTU 在 1400 到 1500 之间。临时方案是调整网卡 MTUsudo ip link set dev ens33 mtu 1400永久生效则要写进 netplan 的mtu: 1400字段。不过说实话NAT 模式下遇到 MTU 问题的概率不高一般是走了双层隧道或者特殊网络环境才会碰到。我把它列出来是因为它的症状太像DNS 坏了很多人会在这上面绕很久。IPv6 是另一个隐形干扰项。Ubuntu 24.04 默认启用 IPv6某些环境下会优先尝试 IPv6 连接超时之后才回落到 IPv4表现出来就是网页打开特别慢但最终能打开。resolvectl status里看有没有 IPv6 的 DNS 服务器ip -6 route看有没有默认路由。如果环境里根本没有可用的 IPv6最简单的办法是在 netplan 里直接关掉dhcp6: false accept-ra: false时间不同步也会造成能上网但某些操作失败的假象。HTTPS 握手对时间敏感系统时间偏差过大时证书校验会失败报错看起来像是网络问题。timedatectl看一眼如果显示System clock synchronized: nosudo timedatectl set-ntp true打开自动同步。虚拟机从挂起状态恢复后时间漂移是常事这个检查我一般顺手就做了。8.2 快照恢复与网卡驱动异常虚拟机快照是个好东西但它有个副作用恢复到旧快照之后虚拟机的网络状态可能是旧地址 新租约的混合体。表现为ip addr里能看到两个地址或者地址是旧的但路由是新的。遇到这种情况最干脆的做法是清空网络状态重新初始化sudo systemctl restart systemd-networkd sudo systemctl restart NetworkManager sudo netplan apply三个命令按需选一个不用全敲取决于你的 renderer 是哪个。实在不行就重启虚拟机让整个网络栈从零开始。驱动层面的问题相对少见但如果你在dmesg里看到类似e1000: eth0 NIC Link is Down或者一堆TX timeout的报错那就是虚拟网卡型号和驱动不匹配。VMware 的适配器类型有e1000、e1000e、vmxnet3几种vmxnet3性能最好但需要系统里有对应驱动。Ubuntu 24.04 内核自带vmxnet3驱动一般没问题但如果是从老版本升级上来的系统可能缺模块。检查方法lsmod | grep -E vmxnet3|e1000 dmesg | grep -iE eth|ens|link如果lsmod里什么都没有而虚拟机设置里选的是vmxnet3那把适配器类型改成e1000e是最快的兼容性方案虽然性能差一点但至少能通。9. 常见问题速查表与几条实战心得9.1 症状对照速查表排查的时候最怕思路发散我整理了一张对照表按症状直接跳到对应章节能省不少时间。症状表现最可能的原因对应处理只有 lo没有 ens 开头的网卡虚拟网卡未连接或驱动缺失检查虚拟机设置里的已连接、换适配器类型网卡 UP 但无 IPv4 地址DHCP 服务未运行或地址池耗尽启动 DHCP 服务、重置虚拟网络地址是 169.254.x.xDHCP 请求无响应同上检查 NAT 服务和虚拟网卡状态有地址网关 ping 不通宿主机虚拟网卡被禁用网络连接面板启用 VMnet8网关通外网 IP 不通子网与宿主机网段冲突改虚拟网络编辑器的子网外网 IP 通域名不通DNS 配置错误resolvectl / netplan 设置 DNS小包通大包卡死路径 MTU 偏小调整 MTU 到 1400 左右网页打开极慢但最终能开IPv6 优先但不可用netplan 关闭 dhcp6 和 accept-ra两台虚拟机轮流断网MAC 地址冲突重新生成 MAC重启后又坏了cloud-init 覆盖配置禁用 cloud-init 网络配置9.2 几条踩出来的经验第一条改配置之前先做快照或者备份配置文件。虚拟机这东西一次错误的netplan apply可能就把 SSH 连接切断如果是远程操作你连回滚的机会都没有。netplan try的 120 秒回滚窗口是免费的保险务必用上。第二条别迷信恢复默认设置。虚拟网络编辑器里的恢复默认设置确实能解决很多疑难杂症但它会把子网、DHCP 范围、端口转发规则全部重置之前配好的东西全没了。用之前先截图记一下当前的配置尤其是做过端口转发的重建起来很烦。第三条学会看日志而不是猜。journalctl -u systemd-networkd -u NetworkManager --since 10 minutes ago这几条命令能直接把最近十分钟的网络事件打出来比在配置文件里瞎改高效得多。dmesg -T | tail -50看内核层面的链路事件网卡 up/down 的时间点一目了然。第四条虚拟机和宿主机的时间、时区、主机名这些东西看着跟网络无关实际会在一些边缘场景下互相影响。我遇到过一次 NAT 明明正常、DNS 也正常但apt update就是报证书错误折腾半天最后发现是虚拟机从挂起恢复后系统时间停在了两天前。第五条如果你需要长期在虚拟机里干活建议在环境搭好之后立刻导出一份干净快照命名成网络正常基线。以后再遇到网络问题先对比当前配置和基线配置的差异往往一眼就能看出是哪次改动引入的问题。这个习惯帮我省下的时间比我写过的所有排查笔记加起来都多。 
长河君 · 2026/10/23 3:21:21 · 阅读 1.2k Ubuntu 24.04 NAT模式虚拟机网络断网排查指南
1. 先把 NAT 模式这条链路的真实结构搞清楚Ubuntu 24.04 虚拟机网络连不上绝大多数人第一反应是虚拟机里网卡没配好然后一头扎进 netplan 里反复改改到怀疑人生。我踩过太多这种坑之后发现一个规律NAT 模式下的断网故障点分布在整个链路上虚拟机内部只是其中一环而且往往是最不容易出问题的那一环。Ubuntu 24.04、NAT 模式、虚拟机网络这几个词摆在一起真正难的不是配置本身是搞清楚哪一段断了。NAT 模式的本质是在宿主机上跑了一个软件路由器和一个小型 DHCP/DNS 服务虚拟机发出的包先交给这个软件路由器由它做地址转换后借用宿主机的物理网卡出去。回来的时候再按连接记录反向还原。这个模型意味着宿主机上的虚拟网卡必须是启用状态、后台的服务进程必须活着、虚拟子网不能和宿主机所在的真实网段撞车、虚拟机必须能拿到同一网段的地址、DNS 请求必须能被正确转发。任何一环断掉表现都是上不了网但修法完全不同。这篇内容适合三类人刚在本地搭好 Ubuntu 24.04 做开发环境、第一次遇到 NAT 连不上网的新手已经会改 netplan 但总在改了没用、重启又坏之间反复横跳的中间用户以及需要给团队写一份可复用的环境排查手册的人。我会按真实排查顺序把五种最常见的故障逐条拆开每一种都给出判断依据、修复动作和背后的原因参数怎么算、配置为什么这么写都会讲明白。文中的命令可以直接复制路径和网段按你自己环境里的实际情况替换。2. 排查前的五分钟准备把玄学变成可验证的证据2.1 分层自检清单从上往下捋一遍虚拟机网络排查最忌讳乱试。我的习惯是固定按宿主机服务 → 宿主机虚拟网卡 → 虚拟子网配置 → 虚拟机网卡识别 → IP 与网关 → DNS这个顺序走每层只问一个问题这一层的地基在不在。先说结论式的判断方法你照着敲几条命令基本三分钟就能定位到断在哪一层。先看虚拟机里网卡有没有被系统认出来ip -br link ip -br addr ip routeip -br link输出里如果只有lo说明虚拟网卡压根没被识别问题在虚拟化层或者驱动层跟你改 netplan 一点关系都没有。如果能看到ens33、ens160之类的名字但状态是DOWN那是链路没起来。如果有地址、有默认路由那虚拟机内部基本是好的问题在宿主机或者上游。再看这三个命令的输出我一般会拿张纸记下来检查项命令期望结果网卡是否识别ip -br link出现 ens33 或 ens160状态 UP是否拿到地址ip -br addr有 192.168.x.x/24 或 10.0.2.15/24默认网关是否存在ip route有default via 192.168.x.2之类的行网关是否可达ping -c 3 网关IP通外网 IP 是否可达ping -c 3 223.5.5.5通域名是否可解析getent hosts archive.ubuntu.com返回 IP这张表的价值在于它把上不了网这个模糊描述切成了六个可以独立回答的是非题。网关通、外网 IP 不通说明 NAT 转换没生效外网 IP 通、域名解析不出来那就是纯粹的 DNS 问题网关都不通直接去看宿主机虚拟网卡和虚拟网络编辑器。很多人的时间浪费在外网不通就去改 DNS这种错位操作上。2.2 先确认宿主机侧的地基再动虚拟机在动手改任何配置文件之前我强烈建议先在宿主机上确认三件事虚拟网卡是否启用、后台服务是否运行、虚拟子网是什么。这三个信息决定了后面所有配置的取值。Windows 宿主机上Win R输入ncpa.cpl打开网络连接面板找到名字类似VMware Network Adapter VMnet8的那块网卡。它必须是已启用状态禁用状态下虚拟机和宿主机之间的软件路由器链路就是断的虚拟机里怎么配都没用。这块网卡的 IP 通常就是 NAT 子网的网关地址比如192.168.142.1而虚拟机侧的网关往往是192.168.142.2这两个不要搞混。接着按Win R输入services.msc找两个服务VMware DHCP Service和VMware NAT Service。这两个必须处于正在运行且启动类型为自动。我遇到过不止一次某个安全软件清理后台进程时把它们设成了手动重启后虚拟机就再也上不了网而虚拟机内部一切正常。打开虚拟网络编辑器在虚拟机软件的编辑菜单里需要管理员权限选中 NAT 模式那一行点NAT 设置能看到网关地址点DHCP 设置能看到地址池范围。把这两组信息记下来后面配静态 IP 的时候要用。提示虚拟网络编辑器的改动需要点应用才生效而且有概率触发一次虚拟网络的重新加载正在运行的虚拟机会短暂断网操作前最好先把虚拟机挂起或者关掉。Linux 宿主机上则是另一套东西用ip addr看有没有vmnet8接口用systemctl status查对应的服务单元NAT 转发依赖内核的转发开关和iptables/nftables的伪装规则sysctl net.ipv4.ip_forward必须返回 1。这块内容展开会很长本文主要以 Windows 宿主机为主线因为这是绝大多数人的实际场景。3. 问题一虚拟网卡被禁用或后台服务没启动3.1 症状特征虚拟机内有地址但网关完全不通这是最高频的一类也是最容易被误判的一类。典型表现是虚拟机里ip addr能看到192.168.x.128/24这样的地址看起来一切正常但ping 192.168.x.2直接 100% 丢包或者返回Destination Host Unreachable。这时候很多人会去怀疑防火墙、怀疑 ip_forward、怀疑内核模块其实九成以上是宿主机侧那块虚拟网卡被禁用了或者 DHCP/NAT 服务挂了。判断方法很简单在宿主机上ping虚拟机的 IP。如果宿主机 ping 不通虚拟机而虚拟机自己也 ping 不通宿主机上的 VMnet8 地址那基本可以确定是虚拟链路层断开。再去看网络连接面板里那块网卡的图标是不是灰色的已禁用服务列表里那两个服务是不是停了答案立刻就出来了。还有一种变体网卡是启用的但被设成了公用网络配置文件Windows 防火墙对公用网络默认策略更严格会拦掉入站的 ICMP 和一些转发流量。这时候表现为虚拟机 ping 宿主机通、宿主机 ping 虚拟机不通或者反过来。把 VMnet8 这块网卡的防火墙配置文件切成专用通常就能解决但我一般建议更干脆的做法在防火墙的入站规则里直接放行 VMnet8 这块网卡的全部流量因为它是纯内部的虚拟链路不涉及对外的暴露面。3.2 修复动作与背后的原因修复顺序我建议这样走。先启用网卡网络连接面板里右键 VMnet8 → 启用等十秒钟让系统重新加载驱动和 DHCP。再启动服务services.msc里把VMware DHCP Service和VMware NAT Service都启动并把启动类型改成自动。最后在虚拟机里重新触发一次 DHCP 请求sudo dhclient -r ens33 # 释放旧租约 sudo dhclient -v ens33 # 重新获取-v 会打印完整过程-v参数很关键它会实时打印 DHCP 的四次握手过程。如果看到DHCPDISCOVER发出去之后一直没有DHCPOFFER回来说明请求根本没到 DHCP 服务问题在链路层如果收到了 OFFER 但后续 REQUEST/ACK 失败那可能是地址池耗尽或者租约冲突。这个输出比任何日志都直观。为什么禁用网卡会导致这么彻底的不通因为 NAT 模式的软件路由器是绑定在这块虚拟网卡上的网卡一禁用相当于把路由器的一个物理端口拔了。虚拟机和宿主机之间的二层通路断了DHCP 请求自然发不出去NAT 转换也无从谈起。这不是配置错了是线路断了所以改 netplan 一万遍也没用。注意有些优化类工具会把VMware NAT Service判定为不常用后台服务并禁用它装完系统或者做完整理之后建议顺手确认一下这两个服务的状态这是我见过最隐蔽的复发原因。4. 问题二虚拟子网和宿主机真实网段撞车4.1 怎么判断是网段冲突而不是配置错误如果你在公司网络或者某些特殊的路由环境下用虚拟机这个坑几乎是必踩的。表现很有迷惑性虚拟机拿到地址了网关也 ping 得通但就是上不了外网ping 223.5.5.5全部超时traceroute出去第一跳之后就没了。或者更诡异能上网但访问公司内网的某个服务时流量跑到了虚拟机内部而不是走真实网络。原因不复杂。NAT 模式默认的子网经常是192.168.142.0/24这类而很多企业内网、家用路由器的网段也是192.168.1.0/24、192.168.0.0/24甚至有些环境直接用192.168.142.x。一旦 NAT 子网和宿主机所在的物理网段重叠宿主机的路由表就会出现两条指向同一网段但出口不同的路由谁优先级高谁说话结果是流量走错地方NAT 转换自然失败。判断方法在宿主机上执行ipconfigWindows或ip routeLinux看物理网卡的网段是什么再去虚拟网络编辑器里看 VMnet8 的子网是什么。如果前三段相同或者两个网段能互相包含那就是冲突了。还有一个更直接的验证方法在宿主机上ping虚拟机的 IP如果 ping 不通而虚拟机自己ping自己的网关也不通同时宿主机物理网段又和虚拟子网撞了基本可以确诊。4.2 改子网的完整操作与参数计算改法是在虚拟网络编辑器里选中 NAT 那一行点更改设置需要管理员权限把子网 IP 改成一个不冲突的段比如192.168.188.0子网掩码255.255.255.0。虚拟机会自动把网关设成.2把 DHCP 池设成.128到.254。这里有几个参数值得算一下不然容易踩第二个坑。掩码255.255.255.0对应/24可用地址是.1到.254。虚拟网络编辑器默认的分配约定是.1给宿主机侧的 VMnet8 网卡.2给 NAT 网关.3到.127一般留给静态地址手工使用.128到.254给 DHCP 动态分配。所以你如果打算给虚拟机配静态 IP最好落在.10到.100这个区间既避开了网关和宿主机网卡也避开了 DHCP 池不会出现地址被抢的情况。改完子网之后虚拟机的旧地址会失效需要重新拿一次地址。这时候我一般会顺手做一次完整复位sudo ip addr flush dev ens33 sudo dhclient -r ens33 sudo dhclient -v ens33 ip -br addr ip route如果虚拟机里还残留着旧网段的路由比如default via 192.168.142.2新的 DHCP 拿到的地址和网关会和旧路由打架表现为能 ping 通新网关但上不了网。ip route的输出里如果出现两条 default 路由用sudo ip route del default via 旧网关删掉多余的那条或者干脆重启虚拟机让网络栈重新初始化。提示改完子网后如果你之前给虚拟机配过静态 IPnetplan 或者 NetworkManager 里的旧配置不会自动跟着变。要么同步改成新网段要么切回 DHCP别指望它自己适应。这是很多人改完子网还是不通的真正原因。5. 问题三Ubuntu 24.04 的网络管理栈踩坑5.1 24.04 桌面版和服务器版的管理方式不一样这个问题在 24.04 上格外突出因为同一个版本号下桌面版和服务器版的网络管理栈是不同的。桌面版默认用 NetworkManagernetplan 里的 renderer 一般写着NetworkManager配置文件通常是/etc/netplan/01-network-manager-all.yaml这种服务器版默认用systemd-networkd配置文件往往由 cloud-init 生成路径是/etc/netplan/50-cloud-init.yaml。区别在哪如果你照着网上某篇老教程去改50-cloud-init.yaml但你的系统是桌面版、实际生效的是 NetworkManager那改了等于没改netplan apply之后看着没报错重启又回到原样。反过来服务器版你去用nmcli命令配那也是白费力气因为 NetworkManager 根本没在跑。先确认自己在哪个栈上ls /etc/netplan/ cat /etc/netplan/*.yaml systemctl is-active NetworkManager systemd-networkd systemd-resolved如果NetworkManager是 active、systemd-networkd是 inactive那就走 NetworkManager 那条路。如果反过来就走 networkd。两个都 active 的情况也有通常是桌面版装了服务器组件这种时候以 netplan 里写的 renderer 为准不一致就会出现命令生效了但配置被覆盖的诡异现象。5.2 三种典型写错方式和一份可抄的配置第一种错法是 YAML 缩进。netplan 的配置文件用的是 YAML缩进只能用空格不能用 Tab而且层级必须严格对齐。多一个空格少一个空格都会导致解析失败。好在netplan有内置的检查命令sudo netplan generate # 只做语法和语义校验不应用 sudo netplan try # 应用并给 120 秒确认窗口超时自动回滚 sudo netplan apply # 直接应用我强烈推荐用netplan try而不是直接apply尤其是远程连着的机器。它会先应用配置然后等你在终端里按回车确认120 秒内不确认就自动回滚到之前的配置。这在改网络配置时等于一个免费的安全网改错了不会把自己锁在外面。第二种错法是gateway4这个字段。24.04 里它已经被标记为废弃虽然有些情况下还能用但会打印警告而且在某些版本上直接不生效。正确的写法是用routes配默认路由。第三种错法是把dhcp4: true和静态addresses同时写在一个接口下两者冲突实际行为取决于版本很容易出现地址有了但网关没有的半残状态。一份 DHCP 场景下可以直接抄的配置长这样文件名建议/etc/netplan/01-netcfg.yamlnetwork: version: 2 renderer: NetworkManager ethernets: ens33: dhcp4: true dhcp4-overrides: use-dns: true use-routes: true optional: trueoptional: true这个字段值得单独说一句。它表示这块网卡没起来也不阻塞开机流程对于虚拟机环境很有用避免因为网络初始化慢导致开机卡在等待网络那一步。dhcp4-overrides里的use-dns和use-routes是告诉系统接受 DHCP 服务器下发的 DNS 和路由默认就是 true但有些精简镜像会关掉显式写一遍更保险。静态 IP 的版本则是network: version: 2 renderer: NetworkManager ethernets: ens33: dhcp4: false addresses: - 192.168.188.50/24 routes: - to: default via: 192.168.188.2 metric: 100 nameservers: addresses: [223.5.5.5, 119.29.29.29] optional: true写完sudo chmod 600 /etc/netplan/01-netcfg.yaml权限不对 netplan 会拒绝读取这是很多人漏掉的一步。然后sudo netplan try确认没问题再回车。注意如果系统是服务器版且用了 cloud-init它会在每次启动时重新生成/etc/netplan/50-cloud-init.yaml把你的手动修改覆盖掉。解决办法是新建一个编号更小的文件比如01-netcfg.yaml或者在/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg里写一行network: {config: disabled}把 cloud-init 的网络配置彻底关掉二选一即可。5.3 网卡名字对不上是个隐形杀手Ubuntu 24.04 用的是可预测网卡命名名字可能是ens33、ens160、enp0s3、enp3s0取决于虚拟化平台和固件。如果你从别处抄了一份配置里面写的是ens33而你实际的网卡叫ens160netplan 不会报错只会默默忽略这个不存在的接口结果就是配置应用成功了但网络一点变化都没有。确认名字的方法就一条ip -br link看第二列。改配置之前先把这个名字抄下来再往 YAML 里填。这个低级错误我见过太多次而且它特别难自查因为整个过程没有任何报错提示。6. 问题四DHCP 拿不到地址或者拿到了但网关是错的6.1 租约冲突与地址池耗尽DHCP 相关的问题有两类典型表现。一类是ip -br addr里只有127.0.0.1网卡状态是 UP 但没有 IPv4 地址反复重启也不见好转。另一类是有地址但地址是169.254.x.x开头的这是链路本地地址意思是我发了 DHCP 请求但没人理我系统自己给自己分了个临时地址。第一类情况先看 DHCP 服务。宿主机上服务停了、地址池改小了、或者虚拟网络编辑器里的 DHCP 被取消勾选了启用都会导致这个结果。第二类情况除了服务没起还有一个隐蔽原因地址池耗尽。默认池是.128到.254127 个地址听起来很多但如果你的虚拟机做过大量克隆、每个克隆都占一个租约池子是会满的。这时候把租约时间改短或者在虚拟网络编辑器里点恢复默认设置重置一下通常就好了。还有一个特别容易被忽略的点虚拟机克隆。克隆出来的虚拟机如果保留了原来的 MAC 地址两台机器会抢同一个 DHCP 租约表现为有时候能上网、有时候不能或者两台机器轮流断网。检查方法是对比两台机器的ip link show ens33输出里的link/ether字段如果一样就得改。VMware 在克隆时一般会问你要不要重新生成 MACVirtualBox 则需要在虚拟机设置的高级选项里点一下重新生成。已经克隆完的手工改 MAC 或者在虚拟机设置里重新生成都可以。6.2 手工验证与恢复流程我习惯的恢复流程是这样的按顺序执行每一步都看输出sudo ip link set ens33 up sudo ip addr flush dev ens33 sudo dhclient -r ens33 sudo timeout 30 dhclient -v ens33 ip -br addr show ens33 ip route show defaulttimeout 30是为了避免 dhclient 卡死在那儿一直等。-v的输出里重点看四行DHCPDISCOVER on ens33 to 255.255.255.255 port 67、DHCPOFFER of 192.168.x.x from 192.168.x.x、DHCPREQUEST、DHCPACK。四个都齐了说明 DHCP 链路完全正常问题在别处缺了 OFFER说明请求没被响应去看宿主机服务和虚拟网络编辑器的 DHCP 设置有 OFFER 但没 ACK多半是租约冲突或者服务端拒绝了请求。如果 DHCP 怎么都救不回来临时方案是直接配静态 IP 应急。拿到网关地址虚拟网络编辑器的 NAT 设置里看选一个池外的地址手工加上sudo ip addr add 192.168.188.50/24 dev ens33 sudo ip route add default via 192.168.188.2 dev ens33 echo nameserver 223.5.5.5 | sudo tee /etc/resolv.conf这套命令是临时的重启就没了但能让你先把活干完回头再慢慢修 netplan。我在赶项目的时候用过好几次这种先通再修的路子比死磕配置文件效率高得多。提示手工改/etc/resolv.conf在 Ubuntu 24.04 上大概率会被systemd-resolved覆盖回去因为那个文件通常是个指向/run/systemd/resolve/stub-resolv.conf的软链接。临时用可以长期方案见下一节。7. 问题五能 ping 通 IP 却打不开网页DNS 链路排查7.1 systemd-resolved 与 resolv.conf 的真实关系这一类故障的表现特别有辨识度ping 223.5.5.5通ping archive.ubuntu.com提示Temporary failure in name resolutionapt update卡在Waiting for headers或者直接报解析失败。这说明 IP 层完全正常问题出在域名解析。Ubuntu 24.04 的 DNS 解析走的是systemd-resolved/etc/resolv.conf默认是个软链接指向/run/systemd/resolve/stub-resolv.conf里面写的 DNS 服务器是127.0.0.53这是本地的一个存根解析器真正的上游 DNS 由 resolved 管理。所以你在/etc/resolv.conf里手写nameserver 8.8.8.8重启或者网络重连之后就会被覆盖回去白改。先看现状ls -l /etc/resolv.conf resolvectl status systemctl status systemd-resolved --no-pagerresolvectl status会打印每块网卡当前使用的 DNS 服务器、DNS 域和 DNSSEC 状态。如果Current DNS Server那一栏是空的或者指向一个根本不可达的地址比如宿主机内网某个你已经离开的 DNS那问题就找到了。7.2 三种让 DNS 永久生效的写法第一种也是最推荐的写进 netplan 配置。静态 IP 场景下直接在nameservers里写nameservers: addresses: [223.5.5.5, 119.29.29.29] search: []DHCP 场景下如果 DHCP 服务器下发的 DNS 不对NAT 模式下通常下发的是宿主机那个虚拟网关地址理论上它能转发 DNS但有时会失效可以覆盖掉dhcp4-overrides: use-dns: false nameservers: addresses: [223.5.5.5, 119.29.29.29]配合sudo netplan apply这是最干净的做法重启不丢。第二种用resolvectl直接给网卡设 DNS临时用sudo resolvectl dns ens33 223.5.5.5 119.29.29.29 sudo resolvectl domain ens33 ~. sudo resolvectl flush-caches~.这个域配置的意思是所有域名都走这块网卡的 DNS加上它才能覆盖默认的路由域逻辑。flush-caches清掉之前的错误缓存不然改了 DNS 还是解析不了容易让人以为没生效。第三种如果你就是想让/etc/resolv.conf变成普通文件、自己完全掌控sudo rm /etc/resolv.conf sudo tee /etc/resolv.conf EOF nameserver 223.5.5.5 nameserver 119.29.29.29 EOF sudo chattr i /etc/resolv.conf # 加不可变属性防止被覆盖chattr i这步要谨慎加了之后谁都改不了包括你自己将来想改要先chattr -i。我一般不建议这么干除非是固定用途的测试机。正常场景用 netplan 那一套就够了。还有一个容易忽略的分支DNSSEC 校验失败。有些环境里上游 DNS 的响应过不了 DNSSEC 验证表现为部分域名解析失败、部分正常。resolvectl status里能看到DNSSEC supported: yes如果怀疑是这个原因可以在 netplan 里加dhcp4-overrides之外的配置关掉它或者用resolvectl临时设置。这个坑比较深一般环境碰不到但一旦碰上特别耗时间因为看起来完全不像 DNS 问题。8. 那些容易被忽略的次级原因8.1 MTU、IPv6 优先级和时间不同步MTU 问题在 NAT 模式下不算高频但表现极其迷惑小包能通大包不通。具体就是ping网关没问题ping外网 IP 也没问题但apt update、打开网页、git clone全部卡住不动。原因是路径上某一跳的 MTU 小于 1500而虚拟机发出的包被标记了不分片大包直接被丢弃小包正常通过。验证方法ping -c 2 -M do -s 1472 223.5.5.5 ping -c 2 -M do -s 1400 223.5.5.5-M do是禁止分片-s 1472加上 28 字节的 IP/ICMP 头正好是 1500。如果 1472 不通而 1400 通说明路径 MTU 在 1400 到 1500 之间。临时方案是调整网卡 MTUsudo ip link set dev ens33 mtu 1400永久生效则要写进 netplan 的mtu: 1400字段。不过说实话NAT 模式下遇到 MTU 问题的概率不高一般是走了双层隧道或者特殊网络环境才会碰到。我把它列出来是因为它的症状太像DNS 坏了很多人会在这上面绕很久。IPv6 是另一个隐形干扰项。Ubuntu 24.04 默认启用 IPv6某些环境下会优先尝试 IPv6 连接超时之后才回落到 IPv4表现出来就是网页打开特别慢但最终能打开。resolvectl status里看有没有 IPv6 的 DNS 服务器ip -6 route看有没有默认路由。如果环境里根本没有可用的 IPv6最简单的办法是在 netplan 里直接关掉dhcp6: false accept-ra: false时间不同步也会造成能上网但某些操作失败的假象。HTTPS 握手对时间敏感系统时间偏差过大时证书校验会失败报错看起来像是网络问题。timedatectl看一眼如果显示System clock synchronized: nosudo timedatectl set-ntp true打开自动同步。虚拟机从挂起状态恢复后时间漂移是常事这个检查我一般顺手就做了。8.2 快照恢复与网卡驱动异常虚拟机快照是个好东西但它有个副作用恢复到旧快照之后虚拟机的网络状态可能是旧地址 新租约的混合体。表现为ip addr里能看到两个地址或者地址是旧的但路由是新的。遇到这种情况最干脆的做法是清空网络状态重新初始化sudo systemctl restart systemd-networkd sudo systemctl restart NetworkManager sudo netplan apply三个命令按需选一个不用全敲取决于你的 renderer 是哪个。实在不行就重启虚拟机让整个网络栈从零开始。驱动层面的问题相对少见但如果你在dmesg里看到类似e1000: eth0 NIC Link is Down或者一堆TX timeout的报错那就是虚拟网卡型号和驱动不匹配。VMware 的适配器类型有e1000、e1000e、vmxnet3几种vmxnet3性能最好但需要系统里有对应驱动。Ubuntu 24.04 内核自带vmxnet3驱动一般没问题但如果是从老版本升级上来的系统可能缺模块。检查方法lsmod | grep -E vmxnet3|e1000 dmesg | grep -iE eth|ens|link如果lsmod里什么都没有而虚拟机设置里选的是vmxnet3那把适配器类型改成e1000e是最快的兼容性方案虽然性能差一点但至少能通。9. 常见问题速查表与几条实战心得9.1 症状对照速查表排查的时候最怕思路发散我整理了一张对照表按症状直接跳到对应章节能省不少时间。症状表现最可能的原因对应处理只有 lo没有 ens 开头的网卡虚拟网卡未连接或驱动缺失检查虚拟机设置里的已连接、换适配器类型网卡 UP 但无 IPv4 地址DHCP 服务未运行或地址池耗尽启动 DHCP 服务、重置虚拟网络地址是 169.254.x.xDHCP 请求无响应同上检查 NAT 服务和虚拟网卡状态有地址网关 ping 不通宿主机虚拟网卡被禁用网络连接面板启用 VMnet8网关通外网 IP 不通子网与宿主机网段冲突改虚拟网络编辑器的子网外网 IP 通域名不通DNS 配置错误resolvectl / netplan 设置 DNS小包通大包卡死路径 MTU 偏小调整 MTU 到 1400 左右网页打开极慢但最终能开IPv6 优先但不可用netplan 关闭 dhcp6 和 accept-ra两台虚拟机轮流断网MAC 地址冲突重新生成 MAC重启后又坏了cloud-init 覆盖配置禁用 cloud-init 网络配置9.2 几条踩出来的经验第一条改配置之前先做快照或者备份配置文件。虚拟机这东西一次错误的netplan apply可能就把 SSH 连接切断如果是远程操作你连回滚的机会都没有。netplan try的 120 秒回滚窗口是免费的保险务必用上。第二条别迷信恢复默认设置。虚拟网络编辑器里的恢复默认设置确实能解决很多疑难杂症但它会把子网、DHCP 范围、端口转发规则全部重置之前配好的东西全没了。用之前先截图记一下当前的配置尤其是做过端口转发的重建起来很烦。第三条学会看日志而不是猜。journalctl -u systemd-networkd -u NetworkManager --since 10 minutes ago这几条命令能直接把最近十分钟的网络事件打出来比在配置文件里瞎改高效得多。dmesg -T | tail -50看内核层面的链路事件网卡 up/down 的时间点一目了然。第四条虚拟机和宿主机的时间、时区、主机名这些东西看着跟网络无关实际会在一些边缘场景下互相影响。我遇到过一次 NAT 明明正常、DNS 也正常但apt update就是报证书错误折腾半天最后发现是虚拟机从挂起恢复后系统时间停在了两天前。第五条如果你需要长期在虚拟机里干活建议在环境搭好之后立刻导出一份干净快照命名成网络正常基线。以后再遇到网络问题先对比当前配置和基线配置的差异往往一眼就能看出是哪次改动引入的问题。这个习惯帮我省下的时间比我写过的所有排查笔记加起来都多。