绵羊料理1. 为什么说网络和软件源是Ubuntu 20.04的第一道坎
装好Ubuntu 20.04之后，大部分人遇到的第一个问题不是桌面卡顿，也不是软件装不上，而是网络明明连上了，打开浏览器却慢得像爬，或者干脆apt install什么都装不了。我见过不少新手卡在这一步就放弃了，转头去装回Windows。其实这个问题不难解决，关键在于你要理解Ubuntu的网络和软件源到底是怎么工作的。
先说结论：Ubuntu 20.04默认使用的软件源是官方源（archive.ubuntu.com），服务器在国外，国内访问速度极不稳定。而网络配置这块，Ubuntu从18.04开始把传统的/etc/network/interfaces换成了Netplan，配置文件格式变成了YAML，很多习惯旧方法的人会被这套新机制搞懵。
这两个问题叠加在一起，就是你刚装完系统时体验极差的根本原因。软件源从国外服务器拉取数据慢，而网络配置如果不当（比如DNS不对、网关冲突、虚拟机网络模式选错），又会加剧这种卡顿。所以我把它们放在一起讲，因为在实际排障中，这两者经常是同时出现、互相干扰的。
这篇文章适合刚装完Ubuntu 20.04正准备配置环境的读者，也适合在虚拟机里装Ubuntu但网络一直不通的玩家。我会从Netplan配置入手，讲清楚静态IP、DNS、虚拟机网络模式这几个核心点，再一步步教你换国内软件源，把那些apt报错、下载404、公钥无效的毛病一次性解决掉。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 网络配置：Netplan才是Ubuntu 20.04的正主
2.1 Netplan到底是个什么机制
Ubuntu从18.04开始引入Netplan作为默认网络配置工具，20.04继续沿用了这套方案。它的设计思路是：你写一个YAML配置文件，Netplan根据这个文件生成底层配置，然后交给systemd-networkd或NetworkManager去执行。
关键点在于，你写的配置文件是"声明式"的——你只需要说明"我想要什么状态"，Netplan会帮你处理"怎么变成这个状态"。
默认情况下，Ubuntu 20.04桌面版的网络是由NetworkManager管理的，对应的Netplan配置文件在/etc/netplan/目录下，通常叫01-network-manager-all.yaml。服务器版则通常使用systemd-networkd，配置文件可能是00-installer-config.yaml。
先记住几个基础概念：
- Netplan的配置文件默认在
/etc/netplan/*.yaml - 修改配置后需要用
sudo netplan apply使之生效 - 配置文件的缩进非常重要，YAML对空格敏感，用错一个空格就是"配置无效"
我第一次用Netplan的时候，犯了一个特别蠢的错误：把ethernets写成了ethernet。结果配置文件无法解析，网卡直接起不来。这种问题排查起来很浪费时间，因为报错信息不一定能精确定位到单词拼写问题。
2.2 静态IP配置实操：从DHCP到固定地址
如果你在服务器上部署服务，或者需要SSH远程连接，那就必须给网卡设置静态IP。以常见的ens33网卡为例（VMware虚拟机里通常叫这个名字），配置静态IP的完整步骤如下。
第一步，查看你的网卡名：
bash复制ip addr show
找到状态为UP的那个非loopback接口，记住它的名字。
第二步，编辑Netplan配置文件：
bash复制sudo vim /etc/netplan/01-network-manager-all.yaml
把内容替换成下面这样的配置：
yaml复制network:
version: 2
renderer: NetworkManager
ethernets:
ens33:
dhcp4: no
dhcp6: no
addresses:
- 192.168.1.100/24
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses:
- 223.5.5.5
- 119.29.29.29
这里192.168.1.100/24是你的静态IP地址，192.168.1.1是网关，DNS填的是国内公共DNS。/24这个写法是CIDR表示法，等于子网掩码255.255.255.0。
第三步，应用配置并验证：
bash复制sudo netplan apply
ip addr show ens33
ping -c 4 223.5.5.5
这里有个容易踩坑的地方：在桌面版Ubuntu中，如果renderer写成NetworkManager，在修改配置后有时候需要重启NetworkManager服务才能生效：
bash复制sudo systemctl restart NetworkManager
如果ping 223.5.5.5通了，但是ping www.baidu.com不通，那基本就是DNS解析问题。域名解析走53端口，你可以在/etc/resolv.conf里确认DNS是否写入成功，也可以临时用手动指定方式来测：
bash复制nslookup www.baidu.com 223.5.5.5
这一步能直接测试DNS服务器是否可用，方便区分是网络不通还是解析失败。
2.3 DHCP模式下的DNS被覆盖问题
有些场景下你不需要静态IP，交给路由器自动分配就好。这时候仍然会遇到DNS问题。典型现象是：上午还能正常上网，下午突然所有域名都解析不了，但IP能ping通。
原因通常是DHCP服务器（一般是路由器）下发的DNS地址变了，或者下发的DNS本身不稳定。处理方法有两种。
第一种，在Netplan的DHCP配置中单独指定DNS，覆盖下发的DNS。修改配置：
yaml复制network:
version: 2
renderer: NetworkManager
ethernets:
ens33:
dhcp4: yes
dhcp6: no
nameservers:
addresses:
- 223.5.5.5
- 119.29.29.29
然后netplan apply。
第二种，修改systemd-resolved的配置，强制使用指定DNS。编辑/etc/systemd/resolved.conf：
ini复制[Resolve]
DNS=223.5.5.5 119.29.29.29
FallbackDNS=8.8.8.8
然后重启systemd-resolved：
bash复制sudo systemctl restart systemd-resolved
需要注意，/etc/resolv.conf在Ubuntu 20.04上通常是软链接，指向/run/systemd/resolve/stub-resolv.conf，直接改这个文件是没用的，重启就还原。必须从Netplan或resolved.conf层面去改。
2.4 虚拟机网络模式怎么选：NAT还是桥接
在VMware或VirtualBox里装Ubuntu，网络不通的第一个排查点就是虚拟机的网络模式选错了。
VMware提供了几种网络模式，其中最常见的是NAT（网络地址转换）和桥接（Bridge）。它们的区别可以这样理解：NAT模式下，你的虚拟机躲在宿主机后面，通过宿主机的IP出去访问网络；桥接模式下，虚拟机就像宿主机旁边的一台独立电脑，直接占用局域网里的一个IP。
- 如果你只需要虚拟机上网、安装软件包：选NAT模式，最简单，只要宿主机能上网，虚拟机一般就能上网。
- 如果你需要局域网内的其他设备直接访问虚拟机（比如SSH、跑Web服务）：选桥接模式。
- 如果你需要虚拟机之间互联、又不想占用局域网IP：用仅主机模式，但需要额外配置。
很多人装好VMware虚拟机后发现没网，第一反应是关掉防火墙，其实多半是NAT服务没启动。在Windows宿主机上，可以打开"服务"管理工具，找到VMware NAT Service和VMware DHCP Service，确保这两个服务处于运行状态。
另外注意，如果你在VMware里克隆一个已有的Ubuntu虚拟机，克隆后网卡名称可能会从ens33变成ens38之类的，或者干脆变成eth0，这跟系统的udev规则有关。这时候不要慌，直接ip addr看当前网卡名，把Netplan配置里的网卡名改成实际名字就行。
2.5 网络测速与连通性验证
配置完网络后，我一般习惯做一轮完整的连通性测试，包括以下几个方面：
- 环回测试：
ping 127.0.0.1，确认协议栈正常 - 网关测试：
ping 192.168.1.1，确认链路层和局域网通畅 - 公网IP测试：
ping 223.5.5.5，确认NAT或路由正常 - DNS解析测试：
nslookup www.ubuntu.com，确认DNS服务可用 - HTTP访问测试：
curl -I http://archive.ubuntu.com，确认HTTP端口通畅
这几个测试可以快速定位网络问题出在哪一层。如果第3步不通，说明出网有问题；如果第3步通但第4步不通，说明DNS有问题；如果第4步通但第5步超时，可能是HTTP代理或防火墙拦截了80/443端口。
真正测网速的话，推荐用speedtest-cli，安装方式很简单：
bash复制sudo apt install speedtest-cli
speedtest-cli
如果你是刚换完软件源，这个工具还没装，可以用Python版本先顶着：
bash复制pip install speedtest-cli
speedtest-cli --share
3. 软件源更换：把apt提速的关键操作
3.1 为什么必须换源，以及不同镜像站的差异
官方源的服务器在海外，国内访问延迟高、带宽不稳定。你执行apt update时，元数据下载慢；执行apt install时，软件包下载慢。换个国内镜像源是最直接的解决办法。
国内常用的镜像站有清华TUNA、阿里云、中科大、华为云等。这些镜像站同步官方源的频率很高，基本能保证24小时内完成同步，日常使用完全够用。我个人的习惯是：服务器上用阿里云或腾讯云源（因为云厂商的服务器在机房内部走内网，速度极快），个人电脑或虚拟机上用清华或中科大源。
如果提到"麒麟应用商店更换软件源"这个场景，其原理和Ubuntu换源基本一致，只是把镜像源地址换成麒麟对应的源即可。核心操作都是修改软件源配置文件、更新缓存。
3.2 修改sources.list：一步一步来
Ubuntu 20.04的代号是focal，软件源配置文件是/etc/apt/sources.list。换源的第一步是备份原文件：
bash复制sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
然后编辑文件：
bash复制sudo vim /etc/apt/sources.list
以清华源为例，完整的focal源配置如下：
code复制deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-updates main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-backports main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-security main restricted universe multiverse
如果你习惯用阿里云源，把链接换成http://mirrors.aliyun.com/ubuntu/就行。
这里需要解释一下这些字段的含义：deb表示二进制软件包仓库，后面跟着镜像地址，然后是发行版代号（focal），最后是仓库组件。main（官方支持的自由软件）、restricted（官方支持的非完全自由软件）、universe（社区维护的自由软件）、multiverse（非自由软件）。日常使用这四类都保留就好，有些精简教程只保留main和universe，可能会导致部分软件装不上。
保存退出后，执行更新：
bash复制sudo apt update
这时如果看到一堆"Hit"而不是"Err"，说明源已经换成功了。再执行：
bash复制sudo apt upgrade
把系统自带的软件包升级到镜像源里的最新版本。第一次upgrade时间会比较长，耐心等就行。
这里还有一个细节：有的教程会让你把deb-src也加上，这是源码包仓库。如果你不打算从源码编译软件，建议不要加，因为apt update时源码索引会多花时间和磁盘空间。
3.3 那些常见的apt报错和解决办法
换源之后，最常遇到的就是各种报错信息。我把常见的整理一下，并附上排查方式。
首先是最常见的Hash Sum mismatch错误。特征是在apt update末尾出现一行"Hash Sum mismatch"，甚至还会提示"正在读取软件包列表... 完成"但中间穿插了杂乱的错误。这个问题的根源是镜像站同步过程中元数据更新不完整，或者本地缓存了旧的元数据。
解决办法也很简单，清理缓存后重新更新：
bash复制sudo rm -rf /var/lib/apt/lists/*
sudo apt update
如果还不行，有可能是代理层缓存了错误的响应，可以换一个镜像源，或者把sources.list里的https改成http试试。
第二种是NO_PUBKEY错误，报错内容大致是"W: GPG error: ... NO_PUBKEY 1234567890ABCDEF"。这是因为系统没有导入该软件源的公钥。Ubuntu的软件源基本都带签名，仓库管理员在发布时用私钥签名，apt在更新时会去验证签名，验证失败就是因为缺少对应的公钥。
解决方法是手动导入这个公钥：
bash复制sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1234567890ABCDEF
把1234567890ABCDEF替换成报错里显示的实际公钥ID。
第三种是Failed to fetch连接超时。这种错误在换源之前最常见，镜像站地址本身就是国外的，国内网络环境差的时候就会超时。换了国内源以后基本能解决。如果换了国内源还报超时，优先检查网络是否正常，其次看DNS配置是否正确，最后看是不是防火墙拦截了80或443端口。
第四种是404 Not Found。特征是在apt update时出现"E: The repository '... focal Release' does not have a Release file"，说明该地址下找不到对应的软件仓库元数据。这种情况通常是源地址和发行版代号不匹配。比如你在Ubuntu 20.04上用了jammy（22.04）的源，那肯定404。解决办法是检查/etc/apt/sources.list里的代号是不是focal。
3.4 软件源还可以按需裁剪
如果你的使用场景比较特殊，可以针对性地裁剪源配置。比如你有一个内网离线环境，只需要安装基础开发工具，那就可以只保留main和universe；如果你需要用到一些第三方软件（比如Docker、NVIDIA驱动），这些通常有独立的软件源，在/etc/apt/sources.list.d/目录下单独配置。
以Docker为例，官方给出的安装方式是添加一个独立的源文件：
bash复制echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu focal stable" | sudo tee /etc/apt/sources.list.d/docker.list
但这个地址也是国外的，国内访问同样不快。你可以把download.docker.com换成国内镜像站对应的路径，比如清华源、阿里云源都有Docker仓库的镜像。做法一样，把软件源配置指过去就行。
这里我特别想提醒一句：不要把所有的第三方源一锅端地塞进sources.list。每个第三方源都有自己的签名密钥和依赖关系，混在一起后一旦某个源出问题，整个apt update都会报错，排查起来非常痛苦。规范做法是每个第三方源单独建一个.list文件放在sources.list.d目录下，对应的公钥放在/etc/apt/trusted.gpg.d或/usr/share/keyrings里。
4. 延伸场景：虚拟机安装、输入法与显卡驱动
4.1 在VMware中从头安装Ubuntu 20.04
很多人是在虚拟机里接触Ubuntu的，过程中踩的坑一点不比物理机少。我梳理一遍VMware安装Ubuntu 20.04的关键步骤，帮你避开那些反直觉的坑。
第一步，下载Ubuntu 20.04镜像。官网地址是ubuntu.com/download，国内下载的话建议走镜像站，速度快很多。镜像文件名通常是ubuntu-20.04.6-desktop-amd64.iso，注意选Desktop版（桌面版）还是Server版（服务器版），桌面版带GUI，新手推荐先用桌面版。
第二步，在VMware里新建虚拟机。这里需要关注的配置项是：
- 客户机操作系统类型：选择"Linux > Ubuntu 64位"。如果选错成32位，后面安装会报错"no bootable device"。
- 内存：建议至少4GB，低于2GB跑桌面版会非常卡。
- 磁盘：建议至少40GB，虽然系统只占10GB左右，但后续装软件、跑环境会慢慢膨胀。
- 网络类型：默认NAT模式就行，等系统装好后再根据需求切换。
第三步，启动虚拟机开始安装。在安装类型界面选择"清除整个磁盘并安装Ubuntu"，注意这是虚拟机内部磁盘，不会影响宿主机。
第四步，安装完成后进入系统，第一件事就是按照前面讲的方法换源、更新系统。
4.2 搜狗输入法和中文输入法的安装思路
装好Ubuntu后，很多人第一件事就是装中文输入法。Ubuntu 20.04默认的中文输入法是IBus框架下的智能拼音，输入体验只能说凑合。如果你想用搜狗输入法，这里有一个关键坑：搜狗输入法官方为Ubuntu发布了deb包，但它依赖的是fcitx输入法框架，安装后如果没切换框架，输入法调不起来。
正确的安装步骤是：
第一步，安装fcitx框架和依赖：
bash复制sudo apt install fcitx fcitx-config-gtk
第二步，去搜狗输入法官网下载Linux版安装包（.deb文件）。下载时注意选对架构，现在绝大多数电脑都是amd64。
第三步，安装搜狗输入法：
bash复制sudo dpkg -i sogoupinyin_*.deb
如果提示依赖缺失，执行：
bash复制sudo apt -f install
第四步，把系统输入法框架从IBus切换到fcitx。这一步很容易被忽略。在"设置 > 区域与语言"里找到输入法框架切换，或者运行：
bash复制im-config
选择fcitx，然后注销重新登录。登录后输入法应该能正常工作了。
这里还有一个细节：搜狗输入法在Ubuntu 20.04上的依赖库有时候会和系统自带的库冲突，装完启动不了。我遇到过一次，解决方法是安装libqt5qml5和libqt5quick5这两个Qt库，然后重启fcitx。
输入法这块解决完之后，整个桌面体验就基本接近Windows了。
4.3 NVIDIA显卡驱动安装
Ubuntu 20.04自带的nouveau开源驱动虽然能用，但跑深度学习、玩3D应用、跑CUDA程序时性能很差，必须换成NVIDIA官方闭源驱动。装驱动这里有几个常见的坑。
最推荐的方式是直接用Ubuntu自带的ubuntu-drivers工具：
bash复制sudo ubuntu-drivers autoinstall
这个命令会自动检测你的显卡型号并安装推荐版本的驱动。装完重启即可。
如果你需要装特定版本的CUDA，那就得去NVIDIA官网下载runfile安装。这里提醒一下，runfile安装前必须禁用nouveau驱动，否则会冲突。具体操作是编辑/etc/modprobe.d/blacklist-nouveau.conf：
code复制blacklist nouveau
options nouveau modeset=0
然后重新生成内核initramfs：
bash复制sudo update-initramfs -u
重启后验证nouveau是否被禁用：
bash复制lsmod | grep nouveau
没有任何输出就说明已经禁用了。
装好驱动后用nvidia-smi验证，正常会显示显卡型号和驱动版本信息。
4.4 在线升级失败：18.04升级20.04闪退的原因与对策
热搜词里有"ubuntu18.04在线升级到20.04时候计算资源直接闪退了"，这个问题我见过不少次，特征是在执行do-release-upgrade时，系统在某个阶段直接无响应，甚至SSH断开、图形界面卡死。
要理解这个问题的原因，得从在线升级的原理说起。do-release-upgrade会把系统切换到新版本的软件源，然后批量下载新版本的软件包并逐步替换旧版本。在这个过程里，大量服务会被重启，网络配置会被重建，图形界面可能会被临时关闭。
闪退最常见的原因有三个：内存不足、磁盘空间不足、SSH连接被强制断开。对于远程服务器来说，SSH断开就等于"闪退"——你再也看不到升级界面了，但升级进程可能还在后台跑着。如果你是远程操作，强烈建议用tmux或screen这类终端复用工具来跑升级，即使SSH断开，升级进程也不会被终止。
具体操作方式：
bash复制tmux new -s upgrade
sudo do-release-upgrade
按Ctrl+B然后按D退出tmux，SSH断开也不怕。重新连接后运行：
bash复制tmux attach -t upgrade
就能看到升级进度。
如果升级到一半确实卡死，重启后系统可能处于一个比较微妙的状态。这时候先确认能否进入系统，如果可以，先修复软件包状态：
bash复制sudo dpkg --configure -a
sudo apt -f install
sudo apt dist-upgrade
然后再执行一次升级。
在线升级本身是有一定风险的，如果你的机器数据很重要，建议先做快照或备份再操作。物理机的话，优先考虑重装系统，体验反而更干净。
4.5 系统架构确认与常见开发工具
查系统架构其实是很多人忽略的一个基础操作。装软件、下载二进制包之前，先确认架构能避免装错版本。Ubuntu 20.04支持amd64（x86_64）和arm64两种主流架构，查看当前架构：
bash复制uname -m
uname -a
输出x86_64就是amd64架构，输出aarch64就是arm64架构。另外可以用dpkg --print-architecture查看当前系统的deb安装架构。
在开发工具方面，Ubuntu 20.04的apt源里能直接装很多常用工具。比如网络抓包工具Wireshark：
bash复制sudo apt install wireshark
注意安装过程中会询问是否允许非root用户抓包，建议选择"是"。然后把自己加入wireshark用户组：
bash复制sudo usermod -aG wireshark $USER
重启后就能正常抓包了。
Python环境的话，Ubuntu 20.04自带的Python 3.8，版本不算最新，但作为开发基础够用了。如果要用Anaconda，下载安装脚本后执行：
bash复制bash Anaconda3-2024.xx-Linux-x86_64.sh
安装过程中会提示是否初始化conda，选择yes，安装完后重启终端就能用conda命令了。
5. 常见问题与排查技巧实录
5.1 网卡起不来的几种情形
网卡起不来的表现是ip addr看不到网卡的IP地址，或者ifconfig -a看不到任何非loopback接口。常见的原因和处理方法如下。
第一种，Netplan配置写错了。这是最常见的情况，YAML缩进错误、网卡名写错、network字段拼错、或者在桌面版里漏了renderer: NetworkManager，都会导致配置无法正确应用。排查方法是执行：
bash复制sudo netplan try
这个命令会先测试配置，如果60秒内没有确认，配置会自动回滚，不至于把网络搞死。确认配置没问题后再用netplan apply。
第二种，NetworkManager服务没启动。桌面版如果之前改过默认target或者手动停过服务，NetworkManager可能没有运行。执行：
bash复制sudo systemctl enable --now NetworkManager
sudo systemctl status NetworkManager
第三种，NetworkManager接管了systemd-networkd管理的接口。如果你把renderer改成了systemd-networkd但又启用了NetworkManager，两个服务会抢同一个网卡。排查方法：
bash复制sudo systemctl status systemd-networkd
sudo systemctl status NetworkManager
正常情况下应该只有一个在管你的网卡。
5.2 DNS问题导致的"有网但打不开网页"
"能ping通IP、但域名全都解析不了"是另一类非常典型的网络问题。这个现象在虚拟机里尤其常见，宿主机换了WiFi或者路由器重启之后，虚拟机里的DNS缓存没刷新，就会一直解析失败。
排查思路是：先确认resolv.conf的内容：
bash复制cat /etc/resolv.conf
如果conf文件里只有127.0.0.53这个stub地址，说明走的是systemd-resolved。此时检查systemd-resolved的状态：
bash复制systemd-resolve --status
如果看到DNS Servers是空的或者乱的，就需要按照前面2.2和2.3节的方法，在Netplan配置里明确指定DNS，覆盖掉错误的配置。
还有一种情况是路由器下发的DNS服务器本身不稳，比如有些光猫自带DNS解析经常超时。这种情况可以直接在路由器管理后台把DNS改成223.5.5.5，也可以只在Ubuntu里指定DNS。我建议两个都改，因为路由器的DNS设置会影响局域网内所有设备。
5.3 apt update时的GPG签名错误
GPG签名错误的表现是类似"W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: ... NO_PUBKEY"。
这个问题的本质是apt在验证仓库签名时找不到对应的公钥。解决办法在3.3节里已经给了，用apt-key adv --keyserver导入公钥。但如果公钥服务器连不上（国内访问keyserver.ubuntu.com有时候很慢），可以换一个keyserver，比如：
bash复制sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1234567890ABCDEF
sudo apt-key adv --keyserver pgp.mit.edu --recv-keys 1234567890ABCDEF
如果apt-key命令本身提示不可用（Ubuntu 22.04里废弃了apt-key），可以改用gpg命令手动导入：
bash复制gpg --keyserver keyserver.ubuntu.com --recv-keys 1234567890ABCDEF
gpg --export 1234567890ABCDEF | sudo tee /etc/apt/trusted.gpg.d/custom.gpg
Ubuntu 20.04上apt-key还可用，但迟早要迁移到新的签名方式，提前了解手动导入的流程没有坏处。
5.4 下载速度慢的进一步优化
换了软件源之后，大部分人的下载速度能明显提升。但如果你用的是电信、联通这类跨网访问，有时候还是会遇到波动。这时候可以考虑两点优化。
第一，确认换源后是否执行了apt update。很多人改了sources.list就立即执行apt install，结果下载的还是旧源的缓存。apt每次安装前会对比本地元数据和源服务器上的元数据，如果元数据没更新，就会从旧源地址拉包，速度自然上不去。
第二，如果你的网络环境和某个镜像站匹配度高，可以尝试多个镜像站并对比速度。我实测下来，阿里云源在电信和联通网络下普遍较快，清华源在教育网下表现非常好，中科大源在移动网络下稳定性高。换源的成本很低，改一行链接、执行apt update而已，多试几次就知道哪个适合你。
5.5 虚拟机系统重装后的网络恢复
在虚拟机里折腾系统是家常便饭，经常装完系统断网、克隆后网卡名变了、桥接模式连不上局域网。遇到这种情况，先不要急着重装，按照以下顺序排查：
- 确认虚拟机的网络模式：VMware右下角网络适配器图标里看是NAT还是桥接
- 确认宿主机网络正常：宿主机能上网，虚拟机NAT才有戏
- 确认VMware网络服务启动：Windows服务里检查VMware NAT Service和VMware DHCP Service
- 确认虚拟机内部网卡启用：
ip link set ens33 up - 确认DHCP能否拿到地址：
dhclient ens33或者重建Netplan配置
第五步如果还不行，检查Netplan配置里的网卡名和实际网卡名是否一致：
bash复制ls /sys/class/net
如果系统里多了一个奇怪的接口名，直接改Netplan配置里的网卡名就行。注意，Netplan配置文件里可以有多个网卡配置，不需要的可以删掉，只保留实际存在的。
5.6 从Windows转到Ubuntu后的几个小习惯
最后补充几个从Windows转到Ubuntu后需要养成的习惯。首先是不要用sudo强制执行一切命令。有些新手遇到权限不够就习惯性加sudo，但sudo并不是万能钥匙，它会绕过某些用户级环境变量，导致程序行为异常。正确做法是只在需要管理员权限的命令前使用sudo。
其次是定期执行sudo apt update && sudo apt upgrade。Ubuntu的安全更新很重要，长时间不更新系统，后续升级大版本时问题会很多。
最后是善用man命令。遇到任何命令不会用，先执行man 命令名查看帮助文档，比到处搜索效率高得多。这个习惯能让你少走很多弯路。
6. 我的一些具体实操心得
最后聊几个我实际工作中经常用到的经验，可能对你有帮助。
关于软链接与配置恢复。改任何系统配置文件之前，先备份总没错。一条命令的事：
bash复制sudo cp /etc/netplan/01-network-manager-all.yaml /etc/netplan/01-network-manager-all.yaml.bak
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
这两个备份文件在你改砸了配置的时候，能救你大命。
关于离线安装软件包。如果你在一个完全没有外网的环境里装软件，可以在另一台同版本、同架构的Ubuntu机器上提前下载deb包，拷贝过去后用dpkg -i安装。下载deb包的命令：
bash复制sudo apt download 软件包名
或者用apt-get download。如果要下载某个软件及其所有依赖，可以用apt-rdepends先分析依赖树，再批量下载。
关于时间同步问题。Ubuntu的软件源验证签名时会参考系统时间，如果系统时间和实际时间差距过大，apt会报错说"Release file is not valid yet"。遇到这个问题先检查时间：
bash复制date
sudo ntpdate ntp.aliyun.com
或者直接开NTP同步：
bash复制sudo timedatectl set-ntp true
这个坑在刚装完的机器上特别常见，因为BIOS时间可能不准。
最后说一句。Ubuntu 20.04已经是一款非常成熟的系统了，只要网络和软件源配置到位，日常使用的流畅度和稳定性都能达到让人满意的水平。我这些年用它跑过开发环境、部署过服务、折腾过深度学习训练，真正被网络问题卡死的次数其实很少。大部分"装完就不想用"的负面体验，都源于一开始那半小时的配置没有做踏实。把前面这几步走完，你会发现自己收获的不只是一个能上网的系统，还有一套排查问题的方法论。之后再遇到类似故障，心态会稳很多。