当您在Ubuntu系统中发现浏览器无法访问网站，或者终端命令如ping google.com、sudo apt update失败，但直接ping一个IP地址（如ping 8.8.8.8）却能成功时，您很可能遇到了“ubuntu不能dns”的问题，DNS，即域名系统，扮演着互联网电话簿的角色，负责将我们易于记忆的域名（如www.google.com）翻译成机器能够理解的IP地址，一旦这个翻译过程失灵，整个网络世界对您来说仿佛就断了联系,本文将系统地引导您诊断并解决Ubuntu系统中的DNS解析问题。
初步诊断：确认问题根源
在着手修复之前，我们需要通过一系列简单的命令来确认问题的确出在DNS上,这个过程能帮助我们排除其他网络故障的可能性。
-
测试基础网络连通性：确认您的网络接口本身是工作的，并且能够连接到外部网络，打开终端,执行以下命令：
ping -c 4 8.8.8.8
如果这个命令能够成功收到回复，说明您的计算机到互联网的物理链路是通畅的，如果失败，则问题可能出在您的网络配置、路由器或网络服务提供商（ISP）上,应优先排查这些环节。
-
测试DNS解析功能：测试域名解析是否正常,执行：
ping -c 4 www.google.com
如果此时终端提示
ping: www.google.com: Name or service not known或类似的错误，而第一步的IP地址ping是成功的,那么就可以高度确定是DNS解析出了问题。 -
检查当前DNS配置：Ubuntu系统使用
/etc/resolv.conf文件来指定DNS服务器,查看该文件内容：cat /etc/resolv.conf
正常情况下,您会看到类似下面的一行或多行内容：
nameserver 127.0.0.53 options edns0 trust-ad search .这里的
nameserver 127.0.0.53指向了一个本地存根解析器（systemd-resolved服务），它会进一步向上游的DNS服务器查询，如果这个文件是空的，或者指向了一个无法访问的地址，ubuntu不能dns”的根源就在这里。
常见原因与解决方案
确认问题后,我们可以根据不同的原因采取相应的解决措施。
systemd-resolved服务异常
现代Ubuntu版本（尤其是17.10及以后）默认使用systemd-resolved服务来管理DNS，该服务作为本地DNS缓存和转发器，如果它停止运行或配置错误,就会导致解析失败。
解决方案： 检查该服务的状态：
systemctl status systemd-resolved
如果服务未运行（显示inactive (dead)）,请启动它并设置为开机自启：
sudo systemctl start systemd-resolved sudo systemctl enable systemd-resolved
如果服务正在运行但仍有问题,可以尝试重启它：
sudo systemctl restart systemd-resolved
重启后，再次尝试ping www.google.com,看问题是否解决。
上游DNS服务器不可用或响应慢
systemd-resolved服务本身不直接解析域名，它需要从网络配置（如DHCP）或手动设置中获取上游DNS服务器地址（通常是您的路由器或ISP提供的DNS），如果这些上游服务器宕机或性能不佳,解析就会失败或超时。
解决方案： 最直接有效的方法是手动配置可靠、快速的公共DNS服务器,推荐使用以下知名公共DNS：
| 提供商 | 主DNS | 备用DNS | 特点 |
|---|---|---|---|
8.8.8 |
8.4.4 |
稳定、快速，全球通用 | |
| Cloudflare | 1.1.1 |
0.0.1 |
强调隐私保护，速度快 |
| Quad9 | 9.9.9 |
112.112.112 |
自动拦截恶意域名，安全 |
永久配置方法（推荐）：
直接编辑/etc/resolv.conf通常只是临时生效，因为systemd-resolved或网络管理器可能会在重启后覆盖它，正确的永久化配置方法是通过Netplan（Ubuntu 18.04及以后默认的网络配置工具）。
-
找到Netplan配置文件，通常位于
/etc/netplan/目录下，文件名可能为01-netcfg.yaml或50-cloud-init.yaml等。ls /etc/netplan/
-
使用编辑器（如
nano）打开该文件：sudo nano /etc/netplan/你的配置文件.yaml
-
在配置中添加
nameservers部分,将DNS设置为Cloudflare的：network: version: 2 renderer: networkd ethernets: enp0s3: # 这里的网卡名称可能不同，请根据实际情况修改 dhcp4: yes nameservers: addresses: [1.1.1.1, 1.0.0.1]注意：YAML文件对缩进非常敏感,请务必保持正确的缩进格式。
-
保存文件后,应用配置：
sudo netplan apply
应用后，系统会自动更新
/etc/resolv.conf，并使其指向您新设置的DNS服务器，现在再次测试域名解析,应该就能恢复正常了。
防火墙拦截
在某些情况下，本地防火墙（如ufw）或网络中的其他设备（如公司防火墙）可能会阻止DNS查询所使用的端口（TCP/UDP 53）。
解决方案： 检查本地防火墙状态：
sudo ufw status
如果防火墙是激活状态，可以检查其规则。ufw默认允许出站连接，所以问题不大，但如果您有严格的规则,可能需要添加一条允许DNS流量的规则：
sudo ufw allow out 53
如果怀疑是外部网络环境（如公司、学校网络）的限制，可以尝试切换到其他网络（如手机热点）进行测试,以确认问题所在。
综合排查流程小编总结
当遇到“ubuntu不能dns”问题时,可以按照以下流程进行系统化排查：
ping 8.8.8.8：确认基础网络连通性。ping www.google.com：确认DNS解析失败。systemctl status systemd-resolved：检查核心DNS服务状态,必要时重启。cat /etc/resolv.conf：查看当前DNS配置,了解其指向。- 通过Netplan永久配置公共DNS：这是最根本、最可靠的解决方案,能解决大部分由上游DNS引起的问题。
- 检查防火墙规则：排除本地防火墙拦截的可能性。
- 更换网络环境测试：排除外部网络环境的限制。
通过以上步骤，绝大多数Ubuntu下的DNS解析问题都能被定位并解决，理解DNS的工作原理以及Ubuntu系统中systemd-resolved和Netplan的角色,是高效处理此类网络问题的关键。
相关问答FAQs
问题1：为什么我修改了/etc/resolv.conf文件，重启后设置又失效了？
解答：这是因为现代Ubuntu系统使用systemd-resolved服务来动态管理/etc/resolv.conf文件，您看到的/etc/resolv.conf通常是一个符号链接，指向/run/systemd/resolve/stub-resolv.conf或类似路径，每当网络状态发生变化或系统重启时，systemd-resolved服务会根据其自身的配置（主要来自Netplan或NetworkManager）重新生成这个文件，从而覆盖您的手动修改，正确的做法是修改Netplan的YAML配置文件来指定DNS服务器，然后运行sudo netplan apply,这样设置才会被系统持久化保存。
问题2：使用公共DNS服务器（如8.8.8.8）安全吗？会不会泄露我的隐私？ 解答：使用公共DNS服务器在大多数情况下是安全的，并且相比一些ISP提供的默认DNS，它们通常更快速、更稳定，关于隐私，确实，您所查询的每一个域名都会被DNS服务提供商记录，这意味着Google或Cloudflare会知道您访问了哪些网站，这些大型服务商通常有严格的隐私政策，声称不会将这些查询数据与您的个人身份关联用于广告或其他目的，如果您对隐私有更高的要求，可以选择一些注重隐私保护的DNS服务，例如Cloudflare（1.1.1.1）承诺不会将用户数据用于商业化，Quad9（9.9.9.9）则会自动过滤掉已知的恶意网站，提供额外的安全层，这是一个在性能、便利性和隐私之间的权衡。