Wi-Fi 会自己连上，VPN 则需要一条次级关联

你还没坐下，笔记本就已经连上 Wi-Fi，而 VPN 仍在等一次点击。在 VPN 配置文件上设置自动连接毫无作用，因为那个开关管的是配置文件自身的激活，而 NetworkManager 把 VPN 当作基础连接的随附项。文档记载的机制是基础连接的次级列表，那是另一个位置上的另一种属性。

自动连接不是 VPN 的开关

Wi-Fi 或以太网配置文件能自行激活，因为它拥有一个设备。VPN 插件配置文件并不以同样的意义拥有设备；它是伴随一个拥有设备的连接启动的。这就是 VPN 上的自动连接标志看似正确、保存正常却不会产生任何隧道的缘故。该标志回答的是关于配置文件的问题，而不是关于它所需的网络。

这样理解模型也解释了故障形态。基础连接成功，没有任何东西要求 VPN 启动，桌面于是在已连接的网络旁边显示一个未连接的 VPN。什么都没有坏；关联从未被建立。

用 UUID 识别两个配置文件

nmcli -f NAME,UUID,TYPE connection show

先选出应当触发隧道的那份 Wi-Fi 或以太网配置文件，再选出目标 VPN 配置文件。请使用 UUID 而不是名称，因为名称只是一个可能被复制或被改动的标签，而激活路径真正解析的是 UUID。

不要把配置文件名与接口名或机器当前持有的地址混为一谈。这是三种不同的标识符，只是在终端里恰好看着相似，把它们混用只会产生一个没有目标的修改。

把 VPN 追加到基础连接

nmcli connection modify uuid "PRIMARY_UUID" +connection.secondaries "VPN_UUID"

带加号的形式是向现有列表追加；省略加号则会替换整个列表，从而静默移除任何已经配置好的其他次级连接。动手之前先查看当前值并记录下来。

NetworkManager 的连接设置把次级项描述为随基础连接一同启动的 VPN 连接。原生的 WireGuard 配置文件是否属于同一类对象，取决于 NetworkManager 如何管理它，因此同一条命令对以接口形式而非 VPN 插件形式出现的隧道可能是错误的工具。

这是连接策略的变更，而不是运行时的开关。请通过部署所认可的任何重连流程来应用它，并且预期变更后的第一次激活会与你现在所处的会话表现不同。

密钥不属于这条关联

次级条目只说「把这个和那个一起启动」。它不会交出密码、解锁密钥环，也不会应答任何提示。一个在桌面登录后能顺利通过认证的配置文件，在密钥代理不可用的上下文中被激活时仍可能失败。

实际部署请使用受支持的系统方案或密钥代理方案。把所有人的密码放进脚本，好让隧道无人值守地启动，等于把一套认证设计变成一个比其主人的任职更长寿的文件。

先读两类事件，再检查资源

在一次尝试中同时观察基础连接与 VPN 激活。缺少 VPN 事件意味着触发器从未配置，或 UUID 有误。有 VPN 事件但随后认证失败，意味着触发器已经跑过，剩下的问题是凭据，那是另一种修复。

激活之后，去请求当初促成这套配置的那项资源，而不是相信图标。然后故意断开，观察接下来会发生什么，因为自动启动的关联不是紧急开关，也不承诺无限重试。如果要求是「没有隧道就没有流量」，那是另一套策略，需要它自己的配置和自己的测试。把两者混为一谈，正是机器一边反复重连、用户一边以为受到保护的原因。