NetworkManager 与 wg-quick：谁掌管你的 WireGuard 路由？

你在 WireGuard 文件里改了 AllowedIPs，重启隧道，路由表却和之前一模一样。常见的做法是删掉碍事的那条路由然后继续，这能奏效，直到下一次重连又把它加回来。你编辑的文件不一定是产生眼前状态的那个对象。两个管理器可以在同一台机器上运行同一协议，而同一时间只有一个拥有该接口。

迷思：机器上只有一份 WireGuard 配置

wg-quick 读取 /etc/wireguard/ 下的文件，并在你启用时构建接口。NetworkManager 以自有的 keyfile 格式保存连接配置，并在激活时呈现它，而且 导入 wg-quick 文件是把值复制进该配置，而不是链接到它。之后再编辑原始文件毫无作用，因为配置不再读取它。因此同一份对等端与密钥列表可能存在两份，生效的是第二份。

一个值得记住的信号：重启后仍在、但重新导入后不在的改动来自一个存储；重启后就消失的改动来自另一个。

一个实际例子能让这种分裂一目了然。对比 nmcli connection show 与 systemctl status wg-quick@wg0，然后检查路由实际挂在哪个接口上。如果服务已死而接口是通的，那么不管文件怎么说，干活的是那份配置。

迷思：路由规则是 WireGuard 的一部分

内核里的 WireGuard 设备只认识对等端和密钥，对策略路由一无所知。你看到的 ip rule 条目和额外路由表，都是把接口启起来的那个工具安装的。wg-quick 可以添加 fwmark 和专用路由表，以及指向它的规则；而 NetworkManager 通过自己的 ipv4 设置安装路由，并把 DNS 留给系统所用的解析后端。同一条隧道，不同的副作用。

在改动任何东西之前，先读 ip rule 和 ip route show table all ，并记录每条路由位于哪张表。你没有配置过的路由表编号，强烈暗示了创建它的工具。

迷思：删掉路由就是修复

运行时删掉的路由，拥有者会在下一次激活时重新装回，而激活可能在你不知情时发生：笔记本唤醒、链路抖动、服务重启或 NetworkManager 自动连接。这正是同一条路由反复出现的原因，也是这种权宜之计让人感觉不可靠而非错误的原因。先确认管理器，再改那个管理器真正读取的输入。

重新连接并重启相应服务，才是区分真正修复与表面整齐的测试。

只留一个拥有者，移除另一个

选择你的部署所支持的管理器，然后通过其有文档记载的控制方式禁用竞争的那个激活，而不是指望它一直闲着。被屏蔽的 wg-quick 服务或被删除的 NetworkManager 配置是明确的；两者都启用并让它们相互竞争则不是。在禁用任何东西之前，先保住可用的访问，因为承载你远程会话的接口可能正是你要移除的那个。

改动之后，先验证被包含与被排除的流量，再验证 DNS，最后重启一次。如果状态在单一管理器下经受住了重启，你拥有的是归属者，而不是巧合。

这条通用规则值得在 WireGuard 之外也记住：当某个设置反复回来，别再删除结果，去找那个不断产生它的过程。