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.comssh程序在连接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 链路全景速查谁是上游谁是下游把整条链路画出来看会更清楚我在实际排查时会按下面这个顺序逐层检查层级检查对象常见问题第一层WSL内的/etc/resolv.conf指向了不可达的DNS服务器地址第二层WSL虚拟网卡状态网卡未启用、IP地址异常第三层Windows虚拟交换机适配器被禁用、进入低功耗状态第四层Windows DNS客户端服务服务未运行、缓存异常第五层上游DNS服务器公共DNS不可达、内网DNS不响应第六层防火墙或网络过滤软件拦截了UDP 53端口的DNS流量你可以把这张表当作排查地图。大多数情况下问题集中在第一层和第六层要么/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为RunningStartType为Automatic。如果服务被禁用或停止了WSL里的DNS请求也会跟着遭殃。再看ipconfig /all的输出找到你当前上网用的那个网卡确认DNS服务器地址是否正常。如果DNS服务器地址是乱七八糟的无效地址那就先从Windows侧恢复正常的网络环境再回过头来看WSL。3.3 排查速查表为了照顾不喜欢记命令的朋友我把上面这些排查动作整理成一张速查表你也可以把它当成决策树来用现象判断处理方向WSL内 ping 223.5.5.5 不通网络栈异常执行wsl --shutdown后重启WSLping IP通ping域名不通DNS解析链路问题检查/etc/resolv.conf、Windows DNS服务Windows上nslookup gitee.com正常WSL内不正常WSL到Windows的转发路径异常尝试手动指定公共DNS或开启DNS隧道Windows上nslookup gitee.com也不正常宿主机自身DNS异常检查Windows网络连接、重启DNS服务重启WSL后暂时好转过段时间又复发虚拟交换机或网关IP不稳定关闭resolv.conf自动生成固定DNS配置这张表基本覆盖了我遇到过的绝大多数场景。剩下的就是把每一类问题对应的修复手段讲透。4. 从我踩过的坑里整理出的五套修复方案4.1 方案一重启WSL网络栈应急如果你的WSL之前一直好好的突然某天就出现了这个报错尤其是发生在Windows休眠唤醒之后那么最简单的方案就是重启WSL让整个虚拟网络栈重新初始化。在Windows的PowerShell或CMD里执行wsl --shutdown这条命令会强制终止所有正在运行的WSL发行版然后重新打开一个WSL终端。正常情况下WSL会重新创建虚拟网卡、重新生成DNS配置问题就消失了。这个方案的本质是“重启大法”但它不是治本方案。因为如果Windows侧的某个配置已经损坏或者有软件持续干扰网络环境重启WSL只是暂时恢复正常过不了多久又会复发。所以这个方案更适合作为应急手段而不是长期依赖。我还试过在WSL内部手动重置网卡这样不用重启整个WSLsudo 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阿里公共DNS119.29.29.29腾讯公共DNS114.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] networkingModemirrored dnsTunnelingtrue保存关闭然后执行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里临时禁用IPv6sudo sysctl -w net.ipv6.conf.all.disable_ipv61 sudo sysctl -w net.ipv6.conf.default.disable_ipv61但要注意这个操作会影响整个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。具体方法是确认Windows上能够正常解析内网域名。在WSL的/etc/resolv.conf里把公司的内网DNS地址放在最前面公共DNS放在后面作为兜底。测试内网域名和外网域名是否都能正常解析。注意/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 gitgitee.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.confnameserver 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不能解析域名的情况我建议按这个顺序操作先执行wsl --shutdown重启WSL看能否恢复。如果还不行检查/etc/resolv.conf确认里面写的DNS服务器地址是否还在。重点观察是不是系统休眠后虚拟网关IP变了。如果检查不到再上诊断命令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是否正常一用一个准。
