WSL2 Ubuntu 网络不可达与临时故障名称解析故障的修复实践

微软专家

在将 WSL2 Ubuntu 发行版迁移到非系统驱动器后，或是升级 WSL 内核版本时，经常会出现 apt update 报 Temporary failure resolving 以及 ping 显示 Network is unreachable 的错误。这个问题在 WSL1 中不会出现，因为 WSL2 基于 Hyper-V 虚拟机，网络栈与宿主机桥接的方式不同。本文将汇总多次验证后的有效修复步骤，特别是针对自动生成的 resolv.conf 和 wsl.conf 配置失效的情况，以及一个容易被忽略的根因——Windows 将 AppData 下的 Packages 文件夹压缩后导致 WSL2 网络接口无法正常启动。

环境与现象
操作系统：Windows 10 10.0.19044
WSL 版本：2
发行版：Ubuntu 20.04 x64（其他发行版如 OpenSUSE 42 也可能遇到）

当执行 sudo apt update 时出现：

2. Err:1 http://archive.ubuntu.com/ubuntu focal InRelease
3. Temporary failure resolving
4. Err:2 http://security.ubuntu.com/ubuntu focal-security InRelease
5. Temporary failure resolving
6. ...
7. W: Failed to fetch ... Temporary failure resolving

复制代码

ping 8.8.8.8 则显示：Network is unreachable
ping google.com 显示：Temporary failure in name resolution

降级到 WSL1 可临时解决，但切换回 WSL2 问题复现：

2. wsl --set-version Ubuntu 1   # 正常
3. wsl --set-version Ubuntu 2   # 故障复现

复制代码

常规修复：手动接管 DNS 配置
WSL 文档推荐的做法是删除自动生成的 resolv.conf 和 wsl.conf，然后手动创建静态配置。

在 WSL 终端中执行：

2. sudo cp /etc/wsl.conf /etc/wsl.conf.bk 2>/dev/null || true
3. sudo cp /etc/resolv.conf /etc/resolv.conf.bk 2>/dev/null || true
4. sudo rm -f /etc/resolv.conf /etc/wsl.conf

复制代码

创建 /etc/wsl.conf 并禁止 WSL 自动管理 resolv.conf：

2. sudo bash -c 'cat > /etc/wsl.conf <<EOF
3. [network]
4. generateResolvConf = false
5. EOF'

复制代码

创建 /etc/resolv.conf 并填入可用的 DNS 服务器：

2. sudo bash -c 'cat > /etc/resolv.conf <<EOF
3. nameserver 8.8.8.8
4. nameserver 8.8.4.4
5. nameserver 192.168.1.254
6. EOF'

复制代码

其中 192.168.1.254 是从 Windows 的 ipconfig 中获取的默认网关地址。

Windows 侧网络堆栈重置
以管理员身份打开命令提示符，执行：

2. wsl --shutdown
3. netsh winsock reset
4. netsh int ip reset all
5. netsh winhttp reset proxy
6. ipconfig /flushdns

复制代码

之后从 Windows 设置中执行“网络重置”（会重新安装所有网络适配器），然后重启 Windows。

完成上述操作后，大多数场景下 WSL 网络应恢复正常。但一些用户（包括本文情况）仍然无效。此时需要检查 WSL 虚拟网卡的状态。

检查 eth0 状态
在 WSL 中运行 ip addr：

2. $ ip addr
3. ...
4. 6: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
5.     link/ether 00:15:5d:c2:ee:f9 brd ff:ff:ff:ff:ff:ff

复制代码

eth0 处于 DOWN 状态。而 WSL1 下 eth0 是 UP 且分配了 IP（如 169.254.143.197/16）。这表明确实是 WSL2 虚拟网卡未能正常启动。

根本原因与最终解决方案
经过排查发现，当 Windows 对 C:\Users\用户名\AppData\Local\Packages 文件夹开启了“压缩内容以便节省磁盘空间”选项时，WSL2 的虚拟网络设备可能无法正确初始化，导致 eth0 保持 DOWN 状态。

解决办法如下：
1. 打开文件管理器，导航到 C:\Users\<你的用户名>\AppData\Local\Packages。
2. 右键点击 Packages 文件夹，选择“属性”。
3. 点击“高级”按钮。
4. 在“压缩或加密属性”中，取消勾选“压缩内容以便节省磁盘空间”。
5. 点击“确定”，在弹出的“确认属性更改”对话框中选择“将更改应用于此文件夹、子文件夹和文件”。
6. 等待系统完成属性变更（可能需要几分钟）。
7. 在命令行中执行 wsl --shutdown 确保 WSL 完全停止。
8. 重启 Windows。

重启后再次启动 WSL，运行 ip addr 确认 eth0 状态变为 UP 并获得了 IP 地址，apt update 与 ping 恢复正常。

此方法在多个发行版（Ubuntu 20.04、OpenSUSE 42）上验证有效，且无需修改注册表或安装额外工具。建议在新建 WSL 发行版后立即检查 Packages 文件夹的压缩设置，避免此类网络故障。

热心网友6

感谢分享这么详细的排查过程！我之前也遇到过WSL2网络不通的问题，手动改resolv.conf和重置网络都试过，有时候能好有时候又不行，一直没找到稳定的规律。你提到的Packages文件夹压缩导致虚拟网卡起不来这个原因，我之前完全没往这方面想过——这个发现太实用了。现在回想一下，可能我之前的故障就出在这里，因为确实习惯性给系统盘开压缩省空间。下次再遇到类似问题，一定先检查这个设置。另外想问一下，你遇到的发行版里，ArchWSL或者Alpine有没有类似情况？还是说主要影响Ubuntu和OpenSUSE这类带有systemd的发行版？