WireGuard：子网变更后无法路由到对端 — 两条出路

wg show 里的握手是新的，对端地址正确，密钥从未变过——而 ping 依然说无法路由到对端。你一小时前改过隧道子网。这个症状是前缀不匹配的签名，而不是密钥问题：WireGuard 完成了握手，随后丢弃了数据，因为源地址不再符合接收端会接受的网段。要落实子网变更，有两种合理做法，它们失败的位置并不相同。

落实变更的两种做法，以及各自的代价

方案 A 是原地改号：修改接口地址、对端网段、路由以及每一份配置副本，然后重新加载。方案 B 是在旧接口旁边、用新前缀再建一个接口，把对端迁过去，等流量确实迁移后再删除旧接口。

让方案 A 变得危险的正是那种半落地状态，因为它看起来并没有坏。接口起来了，握手成功了，只有数据通路失败。方案 B 更费工，但在你逐个找出引用期间，能保住一条可用的通路。

本地这一侧必须一起改的东西

本地主机上有四样东西描述同一个子网，改一处就等于全改：接口地址、每个对端的 AllowedIPs、系统为这些目的地使用的路由，以及管理器代你安装的一切。用 wg-quick 时，后两项在每次接口起来时都会从配置重新生成，所以一份过期副本会悄悄把旧前缀装回去。

与其相信其中任何一项，不如把配置与运行状态对照：

wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5

查路由是大家最常跳过的一步。它回答内核对某个目的地实际会怎么做，也包括管理器或容器运行时留下的更具体路由。如果它指向的不是隧道接口，那么配置不是问题所在。

对于正在运行的接口，在不拆隧道的前提下应用改好的文件：

wg syncconf wg0 <(wg-quick strip wg0)

这只会就地更新对端与网段。它不会更新接口地址或路由，因为那些不是 WireGuard 的设置——所以改号仍然需要重建接口，或者用 ip 改地址，然后再检查一次路由。

远端必须一起改的东西

子网变更通常死在这里。AllowedIPs 不只是路由提示；它同时是对端被允许呈现的源地址清单。当你改完客户端地址、却把服务器上的 AllowedIPs 留在旧前缀上时，服务器会接受握手、收到加密包，然后把它们丢掉，因为内层源地址不匹配它关联到该对端的任何网段。日志里没有报错，客户端只看到超时。

所以要主动更新接收侧：服务器上的对端条目必须列出新的客户端前缀，服务器自己的回程路由必须为该前缀指向隧道，服务器后面的任何下游网络都必须学到新路径。点名过旧网段的防火墙策略也要同样处理，任何做基于源地址选择的东西也一样。

区分这两种故障的诊断很便宜。握手是新的却没有数据，说明隧道是通的、内层编址不一致。完全没有握手，说明你在看可达性或密钥。不要为前缀问题去换密钥；那会把唯一还正常的东西重置掉。

比你这次修改活得更久的旧副本

改文件并不等于改运行中的系统，而副本比人们以为的多： 拥有该接口的 unit 或管理器、另一个目录里同名的第二份配置、把配置烤进镜像的容器、保留自己那份改过版本的路由器 UI，以及启动时会重新导入已保存隧道的客户端应用。它们任何一个都可能在你的变更看起来完成后，把旧前缀又装回来。

名字也会漂移。如果数字地址能通、主机名却失败，那说明某条内部 DNS 记录或某个服务配置还指向旧的隧道地址。修那条引用，而不是把每个对端网段都放宽——后者会掩盖真正的问题，同时把源地址 ACL 一起放大。

作业期间留一条恢复通道：进入主机的第二条路径、串口控制台，或者对配置文件安排一次回滚。一次把你锁在自己正在改的机器之外的隧道变更，是这类任务变成通宵最常见的方式。

在两者之间做选择，以及如何验证切换

当你拥有每一个对端、数量不多、也能接受短暂中断时，选 A。当对端是不受你控制的远端人手、站点到站点链路必须保持、或者你无法保证所有副本一次改完时，选 B。那种情况下，把新前缀同时加到两个接口上，逐个迁移对端，观察新接口上的流量，然后才删除旧接口及其路由。

无论选哪种，四项检查通过才算完成：握手是新的；对新前缀目的地的查路由指向隧道；几百字节的载荷双向都能通过；主机或管理器重启后同样成立。参见 wg(8) 手册 ，其中说明了各方向上 AllowedIPs 的含义；在为了让症状消失而放宽网段之前，值得重读一遍。

• 握手是新的却没有数据：先看接收端的 AllowedIPs，再动密钥。
• 查路由指向了错误的接口：路由归管理器或容器所有，不是你的文件。
• 数字地址正常、主机名坏了：是旧引用，不是路由环路。
• 重启之后仍然使用新前缀，变更才算真正完成。