接口已经起来但 wg-quick 失败：接下来怎么办

服务单元是红的，接口存在，隧道大体能通，这是最容易让人误判的组合。启动是一条先后顺序：先创建接口，再配置地址、路由、解析器设置以及任何 hook 命令。第四步失败时前三个步骤会留在原地，所以接口名只能证明启动开始过，不能证明它完成过。多一个事实就能省掉这场混乱：失败的是哪一步。

部分状态才是常态故障

这种表现值得预期，而不是当成损坏。接口是整条配置里最便宜、也最容易残留的一环，它恰恰让机器看上去像半好。

还没出现的，是失败步骤之后的所有配置。 如果失败发生在解析器阶段，地址和路由都在，DNS 不在。如果失败的是路由，隧道有了地址，却没有穿过它的路径。

结果是机器对一部分测试有回应、对另一部分没有。于是人们断定服务在抖动，可它从未成功启动过。从未跑完的服务不会抖动，它只会因同一个原因反复失败。

找出第一个失败步骤

读服务单元的日志，而不是只看当前状态，并且从失败那次运行的顶部读起。最后一行告诉你退出码，第一行错误告诉你该修什么。

下面这些命令会打印单元状态、该单元本次启动的日志，以及隧道的实时状态：

systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager | tail -40
wg show
ip -4 addr show dev wg0

解析器报错、路由已存在、hook 以非零码退出、配置解析失败，都会出现在这个窗口里，而且各自点名自己的组件。只看接口状态去猜，等于把这些信息全部丢掉。

决定修复方式的三类情况

先决定你是要清理、原地修复，还是把单元从启动路径里移除，而且要在动手之前决定。

接口坏了但配置正确，就清理后重来。配置错了，先改配置，但仍然要先清理，因为在部分状态上再起一个管理器会让同一个接口有两个主人。如果失败是缺少某个系统组件，比如机器上没有解析器辅助程序，那就明确地安装或移除该依赖，而不是反复修改单元直到它不再报错。

这三类情况覆盖了大多数看似神秘的红色单元。真正区分它们的问题是：同样的失败在干净状态的机器上会不会发生，答案通常就在第一行错误里。

重试之前先清理

在已有状态上重试，可能因为新原因失败，并把原始原因盖住。用创建它的同一个工具把接口降下来，然后确认没有残留。

不要删除无关接口，也不要重置主机的网络栈。两者都是为修一个小对象而动的大手术，会把一条失败的隧道变成一台需要重建其他连接的机器。正确的范围是一个接口和拥有它的单元。任何更大的动作，都要在动手前写清理由。

要证明隧道，而不是单元

绿色单元只说明启动序列以零退出。它并不说明数据包到达了对端，也不说明解析器按你的意图设置好了。

通过隧道发一次请求，并读回产生它的状态：

systemctl is-active wg-quick@wg0
wg show wg0 latest-handshakes
ping -c 3 10.63.0.1
resolvectl query internal.example.net

没有回应的握手依然说明隧道已经成形、远端是安静的，这和从未启动的单元是不同的问题。把单元状态、握手和请求结果放在同一条记录里，因为它们各自独立失败，只有组合起来才能描述系统。