为什么删除的 WireGuard peer 会在重启后回来

身份从正在运行的接口里消失了，改动看起来已经完成。可服务重启之后它又回来了，读起来像是 WireGuard 无视了这条命令。实际发生的事情更简单：启动配置里仍然留着这个 peer。

有两种状态保存着这份列表。只有两者都失去了它，吊销才算真正生效。

wg set 究竟改了什么

命令 wg set wg0 peer <public-key> remove 只修改内核里正在运行的接口。它不向磁盘写入任何内容。配置文件、NetworkManager 配置档或者路由器的已保存状态都没有被触碰。这是设计，不是缺陷。

这种分离是刻意的，因为工具根本不知道接口归谁管理。运行时命令必须对由别的东西管理的接口也是安全的。它无法猜到持久副本放在哪里。结论很容易说清：运行时的移除按构造就是临时的。

于是 peer 在下次重启时回来了，而且带着它原本允许的前缀一起回来。经由它路由的一切也会被重建。一个据称已被吊销的身份，因此在重新加载之后仍能抵达它从前去往的目的地。运行时输出里没有任何提示警告过任何人。

编辑文件之前，先找到写入方

接口有一个所有者。可能是读取文件的 wg-quick，是应用配置档的 NetworkManager，是路由器自己的接口配置，也可能是启动时重建接口的容器入口。编辑一个所有者根本不读的文件，完全不会产生持久改动。

从正在运行的接口出发，先识别公钥，因为名字和地址是比密钥本身更弱的标识。然后把这份列表与所有者真正读取的已保存配置做对比。

wg show wg0 peers
wg show wg0 allowed-ips
systemctl status wg-quick@wg0 --no-pager
ls -l /etc/wireguard

一个活着的接口，其 peer 列表与文件内容对不上，这就是全部的诊断。启动时已保存的配置胜出，运行时状态落败。改动任何一方之前，先把两者对比清楚。

SaveConfig 的陷阱

wg-quick 有一个折角，专抓那些手工编辑文件的人。启用 SaveConfig 之后，它有文档记载的关闭行为会把当前的运行时状态写回配置文件之上。

这就把持久化的通常方向反了过来。你从文件里删掉一个 peer，然后服务停止。运行中的状态被写回，覆盖了你的编辑，把你刚删掉的 peer 又恢复了。

所以顺序很重要：在接口关闭时编辑文件，或者在编辑前关掉 SaveConfig，然后再把接口拉起来，确认实际加载了什么。在接口开着的时候手工编辑，就是在和关闭时的写入赛跑。

两处都改，然后重新加载

在运行时按密钥移除 peer。在已保存的配置里，通过所有者支持的操作移除同一个块，而不是在它周围绕开去改。

然后复查这个 peer 承载了什么。属于被吊销身份的路由网段，应当被有意识地重新分配或移除，而不是被下一个被编辑的 peer 悄悄继承。

如果网关同时承载你的管理访问，请留一条恢复通道。删错 peer 的重启是自己造成的故障。删错路由的重启也一样。

一次通过的测试是什么样

重新加载或重启服务，然后再读一次 peer 列表。旧密钥必须不在，而你打算保留的 peer 必须仍在并且工作正常。

wg show wg0 peers
wg show wg0 allowed-ips
sudo wg-quick down wg0 && sudo wg-quick up wg0
wg show wg0 peers

在情况允许的地方，确认旧身份再也到不了它从前使用的资源。重启前一份整齐的接口列表只是测试的一半。另一半是重启之后这个身份还能做什么。

如果某个管理器一直在恢复这个 peer，就别再重复低层的移除。去修那个写入方所读取的清单，因为在那之前，每一次重启都是又一次邀请这个身份重新出现。