DNS 变更后 WireGuard 仍在使用旧端点

服务器的 DNS 记录迁移之后隧道就不再传输流量，而从同一台机器上解析该域名却是正确的。这两件事并不矛盾。WireGuard 配置里保存的是一个端点，工具在应用该配置的那一刻才解析域名，所以正在运行的接口可能仍在沿用几小时前查到的地址。在更换密钥或改动隧道网段之前，先确认接口究竟在用哪个地址。

域名只解析一次，而非持续解析

WireGuard 的基础配置把一个端点保存为地址和端口，而拉起接口的工具会在那一刻解析主机名。基础协议里没有任何东西按计划轮询 DNS，客户端应用可能在此基础上外加自己的刷新行为。把解析出的地址、地址族和端口记在域名旁边，这个落差就看得见了。没有这份记录，配置看起来是正确的，而接口其实在跟别处通信。

确实有一种自动更新，而且值得了解，因为它看起来像 DNS 刷新，其实并不是。当经过正确认证的流量从新地址到达时，对端端点可能发生迁移，这属于漫游而非域名解析。它跟随对端，因此无法发现旧端点从未联系过的、毫无关系的新服务器。

把记录与正在使用的地址进行对比

用客户端所用的解析器查询文档中给出的域名，然后询问接口持有哪些端点。这两个答案就是决定本页其余内容的对比：

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

这些行使用的 show 子命令记录在wg(8) 手册中。除了地址，还要比较地址族，因为多了一条 IPv6 记录的记录，与 IPv4 地址发生变化的记录是两种不同的比较。如果端点与记录不一致，说明接口在用过期信息，域名从来就不是问题所在。如果两者一致而隧道仍然失败，就该转向监听端和规则，而不是配置文件。

握手时间戳之所以放在那段里，是因为仅凭端点并不能判断对端是否可达。正确端点旁边出现过期时间戳，是路径问题而不是解析问题，这一区分决定了你接下来该动哪里。

通过接口的管理器重启

确认端点已过期之后，通过拥有该接口的机制刷新它，而不是直接编辑运行中的配置。对由 wg-quick 启动的接口，这是一次 down 和 up；对 systemd 单元，这是一次重启；对由管理器持有的接口，则是在该管理器里做的改动，因为运行时编辑会在下次应用时被覆盖：

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

然后确认替换后的监听端及其身份确实是你想要的服务。DNS 迁移不是身份变更，所以它绝不该成为信任一个未经验证的密钥的场合。如果接口现在报告的是新地址却仍然没有握手，故障已经转移到新的网络路径或监听端，这是进展，而不是同一个故障重复两次。

先看握手，再看数据路径

在选择检查清单之前，先把两种结果分开。应用失败但握手成功，属于数据路径问题：路由、允许的前缀或隧道内部的 DNS。握手从不发生，则属于端点侧的可达性或身份问题。把两者混在一起，只会得到一份没人能复现的报告，和一份含三处无关改动的变更记录。

记下域名、解析出的地址、正在使用的端点，以及握手是否完成。这四个事实回答了此故障反复提出的问题，也让下一次发生变成两分钟的检查。域名维护和客户端采用仍然是两件独立的事：修正记录并不会完成采用，重启接口也修不好一条仍然错误的记录。