WireGuard 的 DDNS 已更新仍不通：运行中的 Endpoint 可能还是旧 IP

家里的公网 IP 已经变化，DDNS 查询也返回新地址，但一直运行的 WireGuard 隧道仍然不通。重新加载配置后立即恢复时，应比较运行中的 Endpoint 与域名当前解析结果，而不是继续缩短 DNS TTL。

以下针对 Linux 上由 wireguard-tools 的 wg、wg-quick 管理的接口。桌面客户端或网络管理器可能自带重新解析策略，不能把它们一律当作相同行为。本文也不把“握手很久没有更新”单独当作故障证据：空闲且没有保活流量时，这可以是正常状态。

DNS 更新不等于运行端点更新

配置里的 Endpoint = vpn.example.com:51820 可以使用域名。wg 解析配置或设置端点时，会把它解析为实际 IP 地址和端口；已经配置好的接口不会仅因该 DNS 记录的 TTL 到期，就自动重新执行这次解析。

先在实际运行该隧道的机器上查看对端及端点，wg0 是示例接口名：

sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakes
sudo wg show wg0 transfer

按目标对端公钥定位对应行，再通过该机器实际使用的解析器查询 vpn.example.com。不要拿另一台电脑或另一台公共 DNS 的结果直接代替本机解析结果。若本机仍返回旧地址，先处理 DDNS 或解析缓存；若本机已返回新地址而运行端点仍旧，才进入重新设置端点这条路径。

多条 A/AAAA 记录也需要核对：返回了某个新 IPv4 地址，不代表工具最终选中的 IPv6 地址可达。DNS 正确并不证明 UDP 端口转发、防火墙或运营商入站条件也正确。

输出包含对端公钥、地址和流量信息，分享前应脱敏。不要为检查端点公开 wg showconf 或 wg show wg0 dump，这些形式可能包含私钥或预共享密钥。

只更新已有对端的端点

保留当前端点、配置备份与另一条管理通道后，可在受控环境重新设置目标对端。下面公钥是占位文字，必须换成现有目标对端的完整公钥，域名与端口也应替换：

sudo wg set wg0 peer 'REPLACE_WITH_PEER_PUBLIC_KEY' \
  endpoint 'vpn.example.com:51820'

这次设置会重新解析域名，不需要为此更换密钥、删除全部 Peer 或扩大 AllowedIPs。务必先确认公钥已经存在：写错公钥不是在更新原来的对端。

这是一项运行时变更，不等于把所有配置文件和网络管理器状态一起修改。保留原配置中的正确域名，确认接口下一次启动仍从预期配置加载；不要用当前解析出的 IP 永久替换 DDNS 域名。若接口由其他管理器接管，应通过它的管理方式完成，避免稍后被旧配置覆盖。

重新设置后，发起原本允许的隧道内业务请求，再查看端点、最新握手和收发计数。应确认请求得到有效回应。握手恢复但业务不通时，继续检查对应路由、转发和服务，不能把重新解析当作解决所有 VPN 问题的方法。

保活与地址漫游不能代替 DNS 重查

WireGuard 可以根据正确认证的对端数据包，更新该对端的来源 IP 和端口。这种漫游依靠实际收到数据包，并不是定时查询域名。因此动态地址一侧能主动向另一侧发送时，连接可能自行恢复；两侧都在等待或入站条件不成立时，不能依赖这种效果。

PersistentKeepalive 的用途是周期性发送认证空包，以维持 NAT 或状态防火墙映射。增加保活并不会直接刷新域名解析；如果仍向旧端点发送，也不能仅靠频率更高保证找到新地址。

长期运行的隧道需要按自己的管理环境安排重新解析。wireguard-tools 提供过按配置中的 Endpoint 重新设置对端的脚本示例，但脚本并不是 wg 默认运行的后台任务。采用此类方案前应核对本机软件、脚本版本、调度权限及 DNS 不可用时的行为，记录失败并限制重试频率，不要盲目周期性重建整个接口。

回退时可把目标对端恢复到事先记录的端点，并恢复本次调整的调度配置。旧 IP 已失效时，恢复旧值不会恢复连通；此时应通过备用管理通道修正地址和网络条件，而不是反复改动其他对端。