企业官网建设流程全解析

ssh: Could not resolve hostname gitee.com: Temporary failure in name resolution

这段报错，只要你在WSL里用过git push、ssh或者curl，大概率都撞上过。第一次遇到的时候，我盯着终端愣了好几秒——明明昨天还好好的，怎么今天连域名都解析不了？其实这不是玄学，也不是gitee挂了，而是WSL的DNS解析链路出了问题。这类问题在WSL2上尤其常见，几乎可以算作WSL2用户的“必修课”。

这篇文章我会从报错本身入手，把WSL的DNS链路完整拆开讲一遍，再给出一套从应急到治本的修复方案，最后分享几个我实际踩过的坑和排查经验。不管你是刚入门WSL的新手，还是已经被这个问题折磨过几次的老用户，照着这篇文章的步骤走一遍，基本都能把问题解决。

1. 报错现场与快速定性

1.1 一行报错里藏了哪些信息

先拆解一下报错本身。ssh: Could not resolve hostname gitee.com: Temporary failure in name resolution这行信息其实包含了两层含义：

• Could not resolve hostname gitee.com：ssh程序在连接gitee.com时，需要先把域名翻译成IP地址，这一步失败了。
• Temporary failure in name resolution：这个“Temporary failure”是关键的定位词。它说明系统不是找不到这个域名（那会提示Unknown host），而是解析过程中遇到了临时性故障——比如DNS服务器没响应、请求超时、或者配置文件里的服务器地址不可达。

换句话说，这个报错的核心不是连接问题，而是解析问题。你的网络可能完全正常，只是负责“把域名变成IP”的那个环节挂了。

顺着这个方向继续排查，你会发现一个更典型的规律：在WSL里ping 223.5.5.5这种纯IP地址是通的，但ping gitee.com这种域名就是不通。这说明网络链路本身没问题，问题就出在DNS解析这一环上。

1.2 为什么说这是“典型”的WSL DNS问题

很多刚接触WSL的朋友会有一个疑问：我在Windows里上网好好的，浏览器也能打开gitee，为什么一进WSL就解析不了？

这就要说到WSL的两个版本差异了。WSL1是“翻译层”模式，它直接复用Windows的网络协议栈，所以网络行为和Windows几乎一致，DNS基本不会出问题。但WSL2不一样，它是一台轻量级虚拟机，有自己的虚拟网卡、独立的路由表、独立的DNS配置。这种虚拟化带来的隔离性让WSL2的兼容性更好，但也引入了新的故障点。

在WSL2里，程序发起DNS请求时，会先读取WSL内部的/etc/resolv.conf文件，看看该把请求发给哪个DNS服务器。这个文件里的地址通常指向Windows宿主机侧的一个虚拟网关，然后由Windows的DNS客户端服务作为“中间人”把请求转交给真正的上游DNS。整个过程涉及WSL内部配置、虚拟交换机、Windows服务、防火墙策略等多个环节，任何一个环节出问题，都会表现为“Temporary failure in name resolution”。

这就是为什么这个问题如此“典型”——它不像某个具体软件配置错误那样有一个固定答案，而是一条链路上的多点故障，需要你具备一点网络排查的思路。

1.3 自查三步走：确认问题范围

我个人的习惯是，遇到这类报错先不要急着找“终极解决方案”，花三分钟做一轮快速自查，把问题范围缩小。

第一步，测网络连通性：

ping -c 4 223.5.5.5

如果这个IP能通，说明WSL到外网的网络链路是好的。如果不通，那问题可能不在DNS，而在更底层的网络栈，需要在排查方向上做调整。

第二步，测DNS解析：

getent hosts gitee.com

如果这条命令返回了IP地址，说明解析正常；如果报错或者超时，说明DNS链路确实有问题。

第三步，看当前解析配置：

cat /etc/resolv.conf

这一步主要是确认WSL当前用的是哪个DNS服务器。看到的内容往往是以下几种情况之一：一个类似172.x.x.1的网关地址、一个类似10.255.255.254的虚拟DNS地址、或者某些情况下直接指向了公共DNS地址。

这三步做完，你基本就能判断出问题出在哪个层面：是网络不通，还是DNS配置失效，还是DNS服务器本身不可达。后面的修复方案都可以基于这个判断来选。

2. WSL的DNS链路到底长什么样

2.1 WSL2的网络模型决定了它容易在DNS翻车

既然说到了WSL2是虚拟机，那它的网络模型就值得展开讲一下。WSL2默认使用NAT模式，也就是通过一个虚拟交换机，让WSL2内部形成一个独立的局域网。Windows宿主机在这个局域网里扮演网关角色，WSL2里的网络请求都通过这个网关转发出去。

这个模型本身没问题，问题在于DNS请求的转发路径比你想的要长：

WSL里的程序发起解析请求 → 读取/etc/resolv.conf→ 把请求发给Windows侧虚拟网关 → Windows的DNS客户端服务接收请求 → 转发给上游DNS服务器 → 拿到结果原路返回 → 程序获得IP地址

看到问题了吗？链路越长，故障点越多。虚拟网卡状态异常、网关IP变化、Windows防火墙拦截、DNS客户端服务卡住，任何一个环节出问题，WSL里的解析就会失败。而Windows本机的网络正常恰恰说明，问题往往就出在“WSL到Windows”这一段特殊通道上。

这个模型还有一个隐蔽的问题：WSL2的NAT网关IP不是固定不变的。Windows休眠后唤醒、虚拟交换机重建、甚至某些网络软件调整了系统网络配置，都可能导致网关IP变化。如果WSL内的/etc/resolv.conf还指向旧地址，那DNS请求自然石沉大海。

2.2 /etc/resolv.conf 的前世今生

/etc/resolv.conf是Linux系统里最基础的DNS配置文件，形式很简单，就是一行行nameserver记录。但在WSL里，这个文件有个特殊的“脾气”：它默认是WSL启动时自动生成的，不是你自己手动写的。

你可以先执行一下这条命令看看：

ls -l /etc/resolv.conf

大概率会看到这样的输出：

lrwxrwxrwx 1 root root 29 ... /etc/resolv.conf -> /run/resolvconf/resolv.conf

它是个符号链接，指向系统运行时目录。WSL在每次启动发行版时，会根据当前虚拟网络状态，自动生成一份配置文件写到这个路径下。也就是说，你自己手动编辑/etc/resolv.conf，当时可能生效，但下次重启WSL后，又被覆盖回去了。

这个“自动生成”机制本身是为了方便用户，但也成了问题根源。一旦Windows侧的网络状态或虚拟交换机状态异常，自动生成的配置就可能指向一个不可达的地址。理解了这一点，后面你要修复它，就有两条路：要么让自动生成的配置变得正确，要么干脆关闭自动生成，自己接管这个文件。

2.3 链路全景速查：谁是上游谁是下游

把整条链路画出来看会更清楚，我在实际排查时会按下面这个顺序逐层检查：

你可以把这张表当作排查地图。大多数情况下，问题集中在第一层和第六层：要么/etc/resolv.conf里的地址不对，要么有额外软件干扰了WSL到Windows的DNS转发链路。搞清楚这条链路上的每一个节点，再遇到报错就不会两眼一抹黑了。

3. 先用5分钟做一轮快速排查

3.1 三条命令锁定问题范围

排查的第一步，是把“网络问题”和“DNS问题”区分开。很多人一看到无法解析域名，就开始怀疑DNS配置，但如果底层网络都不通，你改再多的DNS配置也是白搭。

在WSL里依次执行下面三条命令：

# 检查路由和默认网关 ip route show # 检查虚拟网卡信息 ip addr show eth0 # 测试纯IP连通性（用国内的公共DNS服务器做测试目标） ping -c 4 223.5.5.5

如果ping 223.5.5.5能收到回包，说明网络链路通畅。接下来再看DNS：

# 尝试解析域名 getent hosts gitee.com # 查看当前DNS配置 cat /etc/resolv.conf

如果getent hosts超时或报错，而IP能通，问题基本可以锁定在DNS解析环节。如果不想记那么多命令，还有一个更直接的办法：

ping -c 4 gitee.com

这条命令同时依赖网络和DNS。如果提示Temporary failure in name resolution，说明是DNS问题；如果提示Destination Host Unreachable或超时，那就是网络问题。

3.2 Windows宿主机侧配合检查

WSL的DNS链路依赖Windows侧的健康状态，所以光在WSL里排查还不够，Windows这边也要看一下。

在Windows的PowerShell或CMD里执行：

# 查看DNS客户端服务状态 Get-Service -Name Dnscache | Format-List Status, StartType # 刷新DNS缓存 ipconfig /flushdns # 查看本机DNS配置 ipconfig /all

比较理想的状态是：Dnscache服务的Status为Running，StartType为Automatic。如果服务被禁用或停止了，WSL里的DNS请求也会跟着遭殃。

再看ipconfig /all的输出，找到你当前上网用的那个网卡，确认DNS服务器地址是否正常。如果DNS服务器地址是乱七八糟的无效地址，那就先从Windows侧恢复正常的网络环境，再回过头来看WSL。

3.3 排查速查表

为了照顾不喜欢记命令的朋友，我把上面这些排查动作整理成一张速查表，你也可以把它当成决策树来用：

这张表基本覆盖了我遇到过的绝大多数场景。剩下的就是把每一类问题对应的修复手段讲透。

4. 从我踩过的坑里整理出的五套修复方案

4.1 方案一：重启WSL网络栈（应急）

如果你的WSL之前一直好好的，突然某天就出现了这个报错，尤其是发生在Windows休眠唤醒之后，那么最简单的方案就是重启WSL，让整个虚拟网络栈重新初始化。

在Windows的PowerShell或CMD里执行：

wsl --shutdown

这条命令会强制终止所有正在运行的WSL发行版，然后重新打开一个WSL终端。正常情况下，WSL会重新创建虚拟网卡、重新生成DNS配置，问题就消失了。

这个方案的本质是“重启大法”，但它不是治本方案。因为如果Windows侧的某个配置已经损坏，或者有软件持续干扰网络环境，重启WSL只是暂时恢复正常，过不了多久又会复发。所以这个方案更适合作为应急手段，而不是长期依赖。

我还试过在WSL内部手动重置网卡，这样不用重启整个WSL：

sudo ip link set eth0 down sudo ip link set eth0 up

但实测下来效果不稳定，不是每次都能恢复正常，而且还需要你手动确认IP是否重新获取成功。相比之下，wsl --shutdown虽然粗暴，但最可靠。如果你正在跑一些长时间任务，记得先保存好工作再执行。

4.2 方案二：手动指定公共DNS（立竿见影）

如果确认问题出在/etc/resolv.conf指向的DNS服务器不可达，最快见效的办法是手动换一个可靠的公共DNS。

可以先临时测试一下，直接在WSL里执行：

sudo bash -c 'echo "nameserver 223.5.5.5" > /etc/resolv.conf'

然后再试：

ping -c 4 gitee.com

如果马上能通，说明问题确实出在原来的DNS服务器上。但这里有个需要注意的点：直接修改/etc/resolv.conf是临时的，WSL重启后大概率会被覆盖回原样。所以这个方案只适合用来验证判断，想长期生效，需要结合下一个方案一起做。

测试通过之后，就可以把你的首选DNS固定下来。国内用户我一般建议用这几个：

• 223.5.5.5：阿里公共DNS
• 119.29.29.29：腾讯公共DNS
• 114.114.114.114：信风公共DNS

如果公司或校园网络有内网域名解析需求，可以把内网DNS放在最前面，公共DNS放在后面作为兜底。

4.3 方案三：关闭WSL的resolv.conf自动生成（治本）

如果你不想每次WSL重启后都被自动生成的配置覆盖，那就要从源头解决：让WSL不再自动生成/etc/resolv.conf，改成完全由你自己控制。

具体做法是编辑WSL发行版内的/etc/wsl.conf文件：

sudo vim /etc/wsl.conf

写入以下内容：

[network] generateResolvConf = false

保存后退出，然后在Windows侧执行：

wsl --shutdown

重新进入WSL后，你会发现/etc/resolv.conf已经不是符号链接了，而是一个普通文件。这时候再编辑它，写入你想要的DNS配置：

sudo rm -f /etc/resolv.conf sudo vim /etc/resolv.conf

写入内容示例：

nameserver 223.5.5.5 nameserver 119.29.29.29

这里有个细节容易踩坑：如果你的/etc/resolv.conf原来是指向/run/resolvconf/resolv.conf的符号链接，而你已经设置了generateResolvConf = false，那么最好先删掉这个链接，再创建一个全新的普通文件。如果直接对符号链接指向的文件做编辑，WSL下次启动时依然可能把这个文件重置掉，配置等于白写。

完成之后，验证一下：

sudo vim /etc/resolv.conf ping -c 4 gitee.com

如果解析正常，那么恭喜你，这个问题算是治本了。以后除非你主动改配置，否则DNS不会再因为WSL自动生成机制而失效。

提示：设置generateResolvConf = false后，如果以后你想恢复自动生成，只需要把这一行配置改成true或直接删掉，再执行wsl --shutdown即可。

4.4 方案四：Windows防火墙与服务侧修复

有一部分情况，DNS配置完全正常，但WSL里的解析就是失败。这通常意味着WSL发出的DNS请求根本没有到达Windows侧的接收端，或者被防火墙拦截了。

先检查Windows防火墙里是否有针对WSL相关组件的拦截规则。实际操作中，我看到过有人在防火墙里把“虚拟机监控程序平台”相关的网络功能给禁掉了，导致WSL的所有网络请求异常。

还有一种情况是Windows的DNS客户端服务卡死或崩溃。排查方法：

Get-Service -Name Dnscache | Format-List Status, StartType

如果Status不是Running，用管理员权限重启：

net stop dnscache net start dnscache

接下来检查Windows侧的网络适配器。打开“控制面板”→“网络和共享中心”→“更改适配器设置”，找一下名字类似vEthernet (WSL)的虚拟网卡。正常情况下它应该是“已启用”状态。如果被禁用了，右键启用它，再回到WSL试试。

注意：如果你开启了Windows 11新版WSL的mirrored镜像网络模式，可能不会看到vEthernet (WSL)这个适配器，这是正常现象。新旧网络模式的差异会在后面详细讲。

防火墙这一块我不建议上来就关，那是把双刃剑。更稳妥的做法是：先确认“Windows Subsystem for Linux”是否出现在防火墙的“允许应用”列表里。在“Windows安全中心”→“防火墙和网络保护”→“允许应用通过防火墙”中，找到WSL相关条目，确保专用和公用网络的勾选都打开。如果列表里没有，也不需要强行添加，先用其他方案排查。

4.5 方案五：新版本WSL的镜像网络模式与DNS隧道

如果你用的是Windows 11，并且WSL版本比较新，那可以试试一个更“根治”的方案：开启WSL的镜像网络模式和DNS隧道。

在Windows用户目录下编辑.wslconfig文件：

notepad "$USERPROFILE\.wslconfig"

如果文件不存在就新建一个，写入以下内容：

[wsl2] networkingMode=mirrored dnsTunneling=true

保存关闭，然后执行：

wsl --shutdown

重新打开WSL验证。

这个方案背后的逻辑是：mirrored模式下，WSL不再使用独立的NAT网络和虚拟网卡，而是直接共享Windows的网络接口，WSL里的DNS解析行为与Windows保持一致。dnsTunneling更进一步，把DNS请求通过专门的隧道通道送到Windows侧处理，绕开了虚拟交换机和网关转发那一段容易出问题的路径。

我在我自己的环境里实测过这个组合方案，效果确实好，休眠唤醒后基本不会再出现DNS失效的问题。不过需要注意几个点：

• mirrored模式只适用于Windows 11 22H2及以上版本，Windows 10用户用不了。
• dnsTunneling需要WSL 2.2及以上版本，建议先把WSL更新到最新版。
• 开启镜像模式后，WSL内部的IP地址和Windows保持一致，一些依赖独立IP的Docker端口映射、服务监听配置可能需要调整。
• 如果你的工作环境里有比较特殊的网络管理软件，mirrored模式可能引入新的兼容性问题，需要按实际环境测试后再决定是否长期使用。

4.6 Windows侧防火墙与服务检查的补充细节

上一节提到了防火墙和服务，这里再补充几个容易被忽略的细节。

第一，检查Windows虚拟网卡是否被网络管理软件“一键禁用”了。有些系统优化工具会把“非必要”的虚拟网卡全部禁用，vEthernet (WSL)就经常躺枪。被禁用之后，WSL里的网络表现为：能启动、能打开终端，但所有需要网络的命令全部超时。

第二，检查IPv6状态。虽然标题那个报错是解析阶段失败的典型症状，但我在实际使用中发现，gitee.com 这类国内站点有时会优先解析出IPv6地址。如果WSL的IPv6路由不通，可能出现连接超时、卡顿等问题。你可以用ping -6 gitee.com或ping6 gitee.com测试一下。如果IPv6不通，但IPv4正常，可以在WSL里临时禁用IPv6：

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1 sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1

但要注意，这个操作会影响整个WSL的IPv6能力，如果你有容器或服务依赖IPv6，需要谨慎。

第三，就是前面提到过的：/etc/resolv.conf里的DNS同样适用于WSL内所有需要解析域名的程序。如果你只是gitee解析失败，而其他域名比如github.com能正常解析，那问题可能出在特定域名的解析策略上，这个就涉及到更细层的排查，后面会详细说。

5. 常见问题与排查实录

5.1 改完resolv.conf，一重启又恢复原样

这是最常见的坑，也是新手最容易气馁的地方。明明刚刚手动改了/etc/resolv.conf，也生效了，Windows一重启或者WSL一重启，配置又变回了原来的样子。

原因前面已经说了：WSL的自动生成机制会在每次启动时重置这个文件。哪怕你手动改了内容，只要/etc/wsl.conf里的generateResolvConf还是默认值true，它就会在你下次进入WSL时把它覆盖。

解决方案就是方案三：在/etc/wsl.conf里设置generateResolvConf = false，然后删除旧的符号链接，再创建新的普通文件。记得改完一定要执行wsl --shutdown，让WSL完全停止，再重新启动。只关闭终端窗口并不能触发配置重新加载。

说完自动覆盖，还有一个方向值得注意：如果你把DNS服务器写死成某个内网地址，但WSL的网络环境发生切换，那个内网地址连不上了，解析也会失败。所以写死DNS之前，评估一下你的网络环境是否会变化。

5.2 Windows休眠唤醒后WSL DNS直接失效

我遇到这个问题的频率是最高的。Windows笔记本合上盖子再打开，WSL里的网络请求全部超时，域名解析全部失败。

原因是WSL2的虚拟交换机在系统休眠时进入了低功耗状态，唤醒后没有及时恢复，导致WSL里的虚拟网卡和网关之间的通信中断。

快速验证方法：在WSL里执行ping -c 4 223.5.5.5，如果IP都不通，那就是这个原因。

解决方案很简单，执行：

wsl --shutdown

然后重新打开WSL。90%的情况都能恢复正常。如果你不想每次休眠唤醒后都手动做这一步，有两个方向可以考虑：

• 升级到Windows 11的新版WSL，开启mirrored模式，这个模式在休眠唤醒后的表现明显更稳定。
• 在Windows的“任务计划程序”里，设置一个在唤醒后自动执行wsl --shutdown的任务。这个方法我没有长期用过，但逻辑上是可行的，对于急切的朋友可以先应急。

5.3 公司内网域名解析不了，公共DNS救不了

有些读者是在公司或校园网络环境下使用WSL，公司内网有一套自己的DNS，用来解析类似gitlab.intranet这样的内部域名。如果直接照搬公共DNS方案，内网域名会全部解析失败，因为它们只有在公司DNS服务器上才有记录。

这种场景下，我更推荐优先修复WSL到Windows的DNS转发链路，而不是绕路走公共DNS。具体方法是：

1. 确认Windows上能够正常解析内网域名。
2. 在WSL的/etc/resolv.conf里，把公司的内网DNS地址放在最前面，公共DNS放在后面作为兜底。
3. 测试内网域名和外网域名是否都能正常解析。

注意/etc/resolv.conf的匹配规则是“逐个尝试”：系统会先向第一个nameserver发起请求，如果它没有响应或返回错误，再尝试下一个。如果内网DNS对外网域名的解析速度很慢，会导致外网域名解析也变慢，这时可以考虑把公共DNS放到第一位。

还有一个思路是保持generateResolvConf = true，让WSL自动生成配置，前提是Windows侧的DNS配置正确。因为WSL自动生成的配置会复用Windows当前的DNS设置，Windows能解析的域名，WSL理论上也能解析。这种方式对动态网络环境更友好，环境一变，WSL重启后就能跟上新的配置。

5.4 解析正常但ssh连接卡住或超时

这个场景和标题报错有一定区别，但在排查gitee连接问题时也经常碰到。DNS解析已经成功了（比如getent hosts gitee.com能返回IP），但ssh连接就是卡住、超时。

这种问题一般不是DNS的问题，而是连接层面的问题。先排除一下是否真的是网络问题：

ssh -vT git@gitee.com

-v参数会打印详细的连接过程。如果看到卡在Connecting to ...阶段，可能是防火墙或网络策略拦截了22端口的TCP连接。如果卡在Authenticating阶段，可能是密钥认证没有通过。

还有一种情况是gitee.com解析出的IP地址不可达。你可以把解析出的IP手动填进ssh配置来验证，但不要把它当作长期方案，因为IP地址可能会变化。

另外，如果你的Windows侧配置了系统代理类软件，WSL里的流量需要额外配置才能访问特定网络，这种情况也会表现为“连接超时”或“无法访问”。这个和DNS问题要区分开，不要混在一起排查。

5.5 想用hosts一劳永逸？先别急着写死

看到这里，肯定有人会想：既然DNS老出问题，那我直接在/etc/hosts里写死gitee.com的IP不就行了吗？

这个方案确实能用，但我不推荐把它当作长期方案。原因有几个：

• gitee.com这类大型平台的IP不是固定的，它是通过负载均衡系统动态调度的，可能过一段时间就会换IP。
• 不同网络环境下，最佳访问IP可能不同。你在公司网络里写死一个IP，回家之后可能就变慢了。
• hosts文件只能解决“已知域名”的解析，每次遇到新域名还是要依赖DNS。

把hosts当作临时应急手段就好：解析出gitee.com当前可用的IP，临时写入hosts，解决眼下的紧急push需求，之后还是要把DNS链路修好。

5.6 系统代理类软件引发的连锁反应

最后聊一个不那么明显但实际很高发的原因：Windows上的系统代理类网络软件。这类软件为了接管系统网络流量，经常会修改Windows的DNS设置，或者安装自己的虚拟网卡和过滤器。一旦这些软件退出不干净、崩溃、或者更新后配置变更，WSL这种“边缘网络环境”常常首当其冲。

具体表现是：Windows上所有网络功能都正常，浏览器也能上网，但WSL里的域名解析就是失败。排查时，可以先在Windows上打开网络连接列表，看看有没有软件安装的虚拟网卡处于“已禁用”或“正在配置”状态，或者在Windows的DNS设置里看到了非默认的服务器地址。

如果你发现确实是这类软件的影响，最直接的处理办法是：在软件设置里找到与网络过滤、系统DNS接管相关的选项，把它们关掉或调整为不拦截WSL的流量。由于这类软件各有不同，我没有办法给出统一的配置步骤，但排查方向是通用的。

提示：我不能直接推荐具体某个网络软件，但在WSL DNS问题排查中，“查看Windows侧是否有额外网络过滤层”是一个绕不开的排查点。如果实在找不出原因，可以试试先退出系统托盘里的这类软件，再用wsl --shutdown重启WSL验证一下。

6. 我的长期推荐配置与自检清单

6.1 一套稳定的WSL DNS配置参考

如果你不想每次都折腾，可以参考我目前在用的这套配置：

• WSL版本：2.x（从商店获取最新版）
• /etc/wsl.conf：

[network] generateResolvConf = false

• /etc/resolv.conf：

nameserver 223.5.5.5 nameserver 119.29.29.29

这套配置的好处是：不依赖Windows侧的虚拟网关，绕开了最容易出问题的转发链路。只要WSL自身网络连通，DNS解析就稳定。缺点是，如果你需要解析公司内网域名，需要在nameserver列表中加入内网DNS地址。

如果你使用的是Windows 11，我更推荐直接上mirrored模式加dnsTunneling，这是新版本WSL最省心的方案。

6.2 每次遇到同类问题的1-2-3操作顺序

每次再遇到WSL不能解析域名的情况，我建议按这个顺序操作：

1. 先执行wsl --shutdown，重启WSL看能否恢复。
2. 如果还不行，检查/etc/resolv.conf，确认里面写的DNS服务器地址是否还在。重点观察是不是系统休眠后，虚拟网关IP变了。
3. 如果检查不到，再上诊断命令：ping 223.5.5.5测网络，cat /etc/resolv.conf看配置。最后结合本文的方案三和方案四一起处理。

这个顺序的好处是，先用成本最低的“重启法”过滤掉临时性问题，再从配置文件入手，最后才动Windows侧的设置。很多问题走到第1步就已经解决了，没必要每次都把全套操作来一遍。

6.3 关于WSL版本升级的补充建议

最后提一个容易被忽视的点：WSL本身是分版本的，Windows自带的旧版本WSL和从商店安装的新版WSL在功能上有很大差异。新版WSL不仅修复了大量网络问题，还引入了mirrored模式、dnsTunneling、自动回收内存等新特性。

如果你还在用旧版WSL，遇到DNS问题之后折腾半小时都没解决，我会建议你先升级一下WSL。升级方式很简单，在Windows PowerShell里执行：

wsl --update

然后重启WSL。很多时候，一个版本升级就把困扰许久的问题解决了。

我在实际使用中深刻体会到，WSL的DNS问题大多不是某一个文件、某一条命令能解释的。它是一个“环境病”，需要你理解整条链路，再对症下药。如果你这次靠着某个招数侥幸恢复了，建议还是花几分钟把这个问题的根源梳理清楚。否则，下个月Windows一更新，这个报错还会来找你的。

最后再分享一个小技巧：在WSL里配置完DNS之后，养成随手用getent hosts 目标域名验证解析的习惯。它比ping更直接、更快速，而且不依赖ICMP协议，判断DNS是否正常一用一个准。