wg-quick 连接时破坏 DNS：先读设置报错

隧道建立、握手完成，域名解析却停了。对等配置里什么都没变，因为 DNS 那一行从来就不属于对等配置。它属于设置助手，也就是说，故障出在宿主机的解析器工具上，而不在 WireGuard 的密钥里。

读助手打印的第一条消息，而不是最后一条，缺失工具与服务器不可达之间的区别就会一目了然。

DNS 那一行是助手的特性

核心配置字段描述的是对等节点、密钥和允许的地址。域名解析是由拉起接口的脚本额外加上的，每个实现的做法都不一样。桌面客户端可能通过自己的服务管理 DNS，发行版脚本可能调用若干解析器工具之一，容器则可能两者都不做。配置文件无法告诉你当前走的是哪条路径。

这就是为什么配置文件对协议有效，却仍可能在设置阶段失败：故障属于协议根本看不到的钩子。

把扩展字段写进核心配置，并指望协议工具接受它，只会在相反方向制造同样的混乱。两个解析器读的是不同的文件。

知道运行的是哪一个，是诊断的第一步，而它通常体现在你键入的命令里，而不是配置文件里。

读助手打印的第一条错误

在前台拉起接口，按顺序读输出。缺少解析器工具、钩子失败、服务器不可达，都会在不同环节停住同一条命令，各自的修法也不一样。

wg-quick up wg0
resolvectl status wg0
ip route get 10.66.0.1

第一条命令报告设置进度，第二条显示接口现在声明了哪些服务器，第三条显示解析器地址是否真的能通过隧道到达。配置了却不可路由的解析器，产生的是超时而不是配置错误，所以两项检查要一起做。只看状态输出，会得出自信而错误的结论。

如果设置完成而解析仍然失败，就把助手安装的解析器与网络原先使用的解析器作比较。私有解析器需要一条穿过隧道的路由，而只列出它却不覆盖其前缀的配置，会让每个查询都在等待。

宿主机实际用的是哪个解析器

现代 Linux 宿主机常常运行本地 stub 解析器，因此助手安装的地址是被那个 stub 用掉的，而不是被应用直接使用。手动编辑生成的文件，可能看起来有效，直到下次重连时助手把它重新写回。

使用发行版支持的集成方式，让一个组件单独掌管解析器状态。两个所有者造成的竞争，与两个所有者争一个接口地址相同，症状是每次改动后只有几分钟解析正常。

内部名称值得单独检查。公共解析器可以恢复一般浏览，却让每个企业内网名称失败，这恰好与隧道的用途相反。在断定 DNS 已修好之前，先向目标服务器查询内部名称。

清理和设置同样重要

降下接口，再检查一次解析器状态。能恢复原有配置的助手会把宿主机留成可用状态；把自家服务器留在原地的助手，会制造下一次故障，往往是几小时后隧道早已消失的时候。

陈旧状态只要去找就很容易发现。解析器列表可能指向一个已不存在的接口上的地址，搜索域则可能从今早离开的网络里残留下来。任何一项都会让下一次连接变得不可预测，而两项都不会出现在隧道自己的状态输出里。这项检查只花十秒，却能为下一个人省下一小时。

把诊断与修复分开。如果 出问题的是所有目标，而不只是名称查询，那嫌疑就在路由和转发上，DNS 那一行只是干扰。 wg-quick 手册 记录它处理哪些字段、哪些属于协议，这条边界就是这类报告的大部分答案。