Ubuntu DNS 解析问题：确认链路、配置归属与临时测试结果

Ubuntu DNS 不工作时，先确认网络链路和 IP 路径仍然正常：只有路径正常、主机名却解析失败或返回错误结果时，才算是 Ubuntu DNS 解析问题。接着用 resolvectl status 和 resolvectl query 查看活动链路实际使用的是哪台 DNS 服务器和哪个路由域，并在测试一项临时改动之前记录当前的配置所有者和各项值。清除临时改动后，让配置所有者重新应用设置，再把结果与保存的状态对照。

关键要点

• Wi-Fi 或以太网链路、IP 路由、互联网可达性和 DNS 解析是不同的层级。
• Ubuntu 可以按链路选择 DNS；全局列出的服务器未必负责处理某个特定查询。［1］
• /etc/resolv.conf 可能由 systemd-resolved 或其他网络组件管理。不要盲目覆盖或删除这个链接。［2］
• 公共解析器只能作为临时对照，不是通用的永久修复方案。

如果多个层级都可能出了问题，先看通用的设备故障排查指南。现有的DNS 服务器无响应总览更宽泛地解释 DNS；本文聚焦 Ubuntu 当前的解析器（resolver）状态。

Ubuntu DNS 解析问题应该怎样一步步排查？

步骤 1：记录故障状态

在改动任何设置之前，保存失败的主机名、完整错误、时间、活动接口，以及当前的 resolvectl status 输出。

步骤 2：证明链路和路由正常

确认预期的 Wi-Fi 或以太网链路已启用，并且失败的路径有路由。如果链路或路由不存在，就留在那个分支排查，而不是修改 DNS。

步骤 3：对照 IP 与域名行为

把一项获准进行的 IP 层检查与一次系统主机名查询进行对照。只有 IP 路径正常，而名称解析失败或返回错误结果时，才把 DNS 当作首要假设。

步骤 4：确定被选中的解析路径

对确切的名称运行 resolvectl status 和 resolvectl query。确认被选中的链路、服务器、路由域，以及故障是全局性的还是只限于某个域名。

步骤 5：找出配置所有者

检查 /etc/resolv.conf 和当前使用的网络栈。记录这个值是由 NetworkManager、Netplan、DHCP、VPN、systemd-resolved 还是策略提供的。

步骤 6：测试一个临时的每链路值

如果配置所有者和环境允许，临时修改一个每链路（per-link）DNS 值，重复同一次查询，然后对该链路运行 resolvectl revert。

步骤 7：让所有者重新应用设置

让配置所有者重新应用它的设置，并把新的状态与保存的输出对照。不要把 revert 说成是恢复已保存的快照。

步骤 8：在所属层级修复并验证

只在所属的配置层级做持久修复，并准备好回滚路径；之后重复最初的查询，确认内部域名和公共域名都按预期工作。

每一步的结果决定下一个分支。如果 IP 检查和名称检查都失败，用公共解析器做对照也无法证明是单纯的 DNS 故障。如果只有一个分流 DNS（split DNS）域名失败，替换所有解析器可能会破坏仍在正常工作的路由。如果临时服务器测试成功，你得到的是一次有用的对照，而不是允许你留下一个无人管理的覆盖设置。

如何证明故障确实在 DNS？

写下失败的主机名、完整错误、时间、网络接口，以及同一请求在另一台设备或另一个网络上是否正常。检查链路和路由，不要以为“已连接”图标就证明能访问互联网：

ip -brief link
ip route

然后，把一个你获准测试的 IP 层目标，与同一服务使用的主机名进行对照。IP 路径成功而名称查询失败，才支持 DNS 假设。如果两者都失败，应改为调查路由器、强制门户、本地路由、防火墙或上游连接。全网故障可参考路由器已连接但无法上网的排查树。

不要只用浏览器里一个有缓存的标签页来测试。浏览器可能使用自己的加密 DNS 设置、缓存、代理或安全网络功能，所以还要对照一次系统解析器查询。

resolvectl status 能看到什么？

运行：

resolvectl status
resolvectl query example.com

在本地可以安全公开的前提下，把 example.com 换成实际失败的主机名。status 会显示全局和每条链路的 DNS 服务器、搜索域或仅路由域、协议以及活动接口的状态。query 会报告返回的地址，通常还会显示涉及的链路和协议。resolvectl 手册也提供统计和清除缓存的操作，但清除缓存应以证据为依据，而不能代替诊断。

重点查看：

• 预期的 Wi-Fi、以太网、VPN 或隧道链路是否处于活动状态；
• 哪条链路拥有默认 DNS 路由，或最匹配的路由域；
• DNS 服务器来自 DHCP、受管理网络、VPN 还是手动设置；
• 是否只有一个域名失败，尤其是内部的分流 DNS 名称；
• 重新连接同一条链路后，结果是否改变。

按链路路由意味着输出中的两台服务器不一定可以互换。公司域名可能有意走 VPN 链路，而公共域名走家庭网络连接。

谁在管理 DNS 配置？

检查解析器文件，而不是直接编辑它：

ls -l /etc/resolv.conf
cat /etc/resolv.conf
systemctl is-active systemd-resolved

systemd-resolved 手册描述了 /etc/resolv.conf 的几种受支持模式，包括指向本地 stub 或生成的解析器列表的符号链接，以及与由其他组件管理的文件配合运行。当 DHCP、NetworkManager、Netplan、VPN 或管理策略更新链路时，生成的文件可能随之改变。

确认这台机器上的实际所有者。NetworkManager 配置文件、Netplan 配置、服务器网络工具和组织策略各有不同的持久配置路径。不要把另一个 Ubuntu 版本的文件路径照搬过来，当作通用做法。如果设备受管理，修改 DNS 或 VPN 配置文件前先询问管理员。

如何做可回滚的 Ubuntu DNS 测试？

先保存相关的 resolvectl status 输出，并确认接口名称。如果活动的每链路状态归 systemd-resolved 管理，管理员可以在该链路上临时设置一台测试服务器：

sudo resolvectl dns interface-name resolver-address
resolvectl query example.com
sudo resolvectl revert interface-name

请使用适合你网络的实际值。revert 命令会移除临时覆盖，并把该链路的所有 DNS 设置重置为默认值；它不会回放已保存的原配置。回滚之后，让实际的配置所有者重新应用它的设置（只有当重新连接是所有者支持的方式时才重新连接），再把 resolvectl status 与测试前保存的输出对照。在改动之前、期间和之后运行同一次查询。测试期间成功，说明原服务器或其路由需要调查；但不能证明测试服务器就是正确的永久选择。

不要同时修改 DNS 并关闭 VPN、代理、防火墙和 IPv6。多项改动会破坏对照。在需要内部域名、过滤、家长控制或组织策略的网络上，不要永久硬编码公共 DNS 解析器。

如何做持久修复？

在拥有该值的层级修复：

• DNS 由 DHCP 提供、且所有客户端都收到错误值时，修正路由器或 DHCP 服务器；
• 由 NetworkManager 管理的连接，使用该配置文件支持的设置，并有意识地重新连接；
• 由 Netplan 管理的服务器，使用该 Ubuntu 版本支持的格式（schema），验证改动，并保留控制台访问；
• VPN 或受管理设备，修正 VPN 配置文件或联系其管理员；
• 只有某个权威域名失败时，联系该域名或服务的所有者，而不是替换每台客户端的解析器。

应用持久改动之前，记录原始配置并准备好回滚路径。之后只通过所属工具重新连接或应用，再重复 resolvectl status 和最初的查询。

如果只有 apt update 报 DNS 错误呢？

保留确切的软件源主机名和错误。如果 resolvectl query 对该主机名失败，就继续留在 DNS 分支。如果能够解析，但 APT 报告签名、Release 文件、TLS、软件源或依赖错误，DNS 就不是主要诊断方向，请继续看APT 错误与依赖修复指南。

总结

在把故障定性为 DNS 之前，先证明链路和 IP 可达。用 resolvectl 读取全局和每链路状态，找出由哪个组件管理这些值，并且每次只改一个变量。清除临时覆盖，让所有者重新应用设置；任何持久修复都应在 NetworkManager、Netplan、DHCP、VPN 或策略中进行，而不是盲目替换 /etc/resolv.conf。

常见问题

为什么 IP 地址能访问，主机名却失败？

这种情况可能说明名称解析失败，因为 IP 路由无需把名称转换成地址就能工作。用 resolvectl query 确认，并排除应用自身的代理或缓存。

为什么会显示多台 DNS 服务器？

Ubuntu 可能从多条链路获得服务器。路由域和默认 DNS 路由决定由哪条链路处理查询，在 VPN 分流 DNS 场景中尤其如此。

应该直接编辑 /etc/resolv.conf 吗？

在弄清它的所有者之前，通常不应该。它可能是受管理的符号链接或生成的文件，直接编辑可能被覆盖，或破坏受支持的解析器模式。

重启 systemd-resolved 一定能解决问题吗？

不一定。重启可能清除临时状态，但无法纠正错误的 DHCP 值、失效的上游服务器、错误的路由域或受管理的 VPN 策略。

应该删除 /etc/resolv.conf 符号链接吗？

不应该。先确认它有文档记载的模式和配置所有者。删除它可能让应用与本地 stub 或生成的服务器列表断开。

可以永久使用公共 DNS 服务器吗？

只有在考虑过内部域名、隐私、过滤、策略和可靠性之后才可以。一次短暂的对照不足以作为永久改动的依据。

Ubuntu Server 上 DNS 不工作怎么办？

在 Ubuntu Server 上，持久的 DNS 值通常由 Netplan 管理，写在接口的 nameservers 键下的 addresses 和可选的 search 中。请修改所属的 Netplan 文件，或生成它的 cloud-init 设置，而不是 /etc/resolv.conf；然后用 sudo netplan try 应用改动：如果你没有在超时前确认，它会自动回滚，默认超时为 120 秒。保留控制台访问，确认被拒绝的改动确实已经回滚，再重复 resolvectl status 和最初的查询。

如何撤销临时的 resolvectl dns 测试？

对同一条链路运行 sudo resolvectl revert interface-name。它会清除临时覆盖，并把该链路的 DNS 设置重置为默认值；它不会恢复已保存的设置。让配置所有者重新应用设置，再把 resolvectl status 与测试前保存的输出对照。

VPN 连接是否改变了 Ubuntu 的 DNS 选择？

如果某个名称只在 VPN 连接后才失败，就在连接前后对同一个名称比较被选中的链路、DNS 服务器和路由域。VPN 配置文件可能提供每链路 DNS 或仅路由域，所以只影响内部名称的故障，可能反映的是分流 DNS 路由，而不是公共解析器坏了。对照时保持物理网络不变，并遵守网络所有者的策略。［1］［2］

如果被测连接涉及 AethoVPN，应把连接状态与 resolvectl status、原始查询结果一并记录。需要通过实际观察判断这套配置是否影响 DNS，不能只凭品牌名认定配置所有者。错误的 DHCP 值或持久的 NetworkManager/Netplan 设置仍须在来源处修复；清除临时覆盖后，也要确认内部域名仍能正常解析。

---

免责声明：resolver 所有者与持久网络配置会随 Ubuntu 版本、安装方式、网络栈、VPN 和组织策略变化。修改前请保留原值与控制台访问。

来源：

1. Ubuntu Manpage Repository — resolvectl(1) — https://manpages.ubuntu.com/manpages/noble/man1/resolvectl.1.html
2. Ubuntu Manpage Repository — systemd-resolved(8) — https://manpages.ubuntu.com/manpages/noble/man8/systemd-resolved.8.html

Sources checked 2026 年 10 月 4 日。

---

延伸阅读：

• 设备故障排查指南
• 如何修复 DNS 服务器无响应
• 路由器已连接但无法上网
• 修复 apt update 错误和损坏的依赖