内容摘要：下午三点十七分，我在虚拟机里敲下apt update，屏幕滚过一串404。这不对劲。昨天还能正常拉取软件包，今天却连archive.kali.org都连不上。我ping了一下，返回的是ping: un

下午三点十七分，域名我在虚拟机里敲下apt update，解析屏幕滚过一串404。失败这不对劲。域名昨天还能正常拉取软件包，解析今天却连archive.kali.org都连不上。失败我ping了一下，域名返回的解析是ping: unknown host——不是超时，不是失败拒绝，是域名压根解析不出域名。DNS挂了。解析

Kali的失败DNS问题向来是玄学。我第一反应是域名检查/etc/resolv.conf，果然，解析里面的失败nameserver指向了127.0.0.53。这是systemd-resolved的本地缓存地址，通常没问题。但问题恰恰出在这里——本地缓存里的上游DNS可能早就失效了。我试着直接nslookup google.com 8.8.8.8，能通。问题确认，不是网络断了，是系统解析链路出了岔子。

老实说，遇到这种事我反而有点兴奋。纯当工具用的时候，你根本不会注意DNS这层透明的机制。只有当它失灵，你才被迫去翻配置文件，去理解系统解析的优先级顺序。Kali默认用DHCP获取网络配置，但虚拟机里我常改成静态IP。改完就忘了同步DNS设置，结果系统还记着旧网关的解析地址，那个地址早就不可达了。

解决办法倒是不难。最简单粗暴的，直接编辑/etc/resolv.conf，把nameserver改成8.8.8.8或者114.114.114.114。但有个坑——这个文件可能被NetworkManager或systemd-resolved接管，你改了也会被覆盖。我习惯先chattr +i给文件加个不可修改的锁，再改内容。虽然粗暴，但对临时测试来说最省事。

要是你想治本，就得去动NetworkManager的配置文件。在/etc/NetworkManager/NetworkManager.conf里加一段[main] dns=default，然后重启网络服务。或者干脆点，禁用systemd-resolved：systemctl stop systemd-resolved，再手动指定DNS。这些操作在Kali论坛里能翻到无数个版本，但真正适合你的，只有你自己试出来的那一种。

折腾了半个小时，最后发现罪魁祸首是虚拟机的NAT网络在宿主机切换了Wi-Fi后，网关DNS没刷新。重启一下虚拟网络适配器，问题自己就消失了。你说气不气人？但这就是Kali的日常——你以为系统出了问题，其实是你和网络环境之间的默契断了。

解析失败不是世界末日。它只是提醒你，你用的每一行命令背后，都有一堆你平时看不见的依赖关系在默默工作。下次再遇到temporary failure in name resolution，别急着重启。先看看自己的网络环境是不是变了，再检查配置文件。多数时候，问题不在Kali，而在你忽略了它和现实世界之间的那根网线。