Mac 自行重连 VPN：检查按需规则

你断开了 VPN，三十秒后菜单栏图标又回来了。这并非灵异：macOS 的按需规则会在网络变化时、或有程序请求规则覆盖的名称时启动连接，而这条规则可能存在于一份你从未写过的配置描述文件中。按顺序做完下面的检查，比重新安装客户端更快。规则就是策略，所以先读懂策略，再与它较劲。

规则实际盯着什么

按需规则有两个判定点：Mac 所连的网络，以及某个程序正试图解析的域名。任何一点都能把隧道拉起来，所以查一个内网名称就会启动一个没人打开过的 VPN。这套部署还需要在无人值守时也能工作的身份验证，所以受管设备群普遍采用基于证书的方案。

系统策略之外还可能有按 App 的重连选项，所以第一个问题是究竟是哪种机制重连了隧道。先查系统策略，再查客户端，最后才查是谁点了断开。大多数看起来该负责的客户端偏好，其实并不负责。这个顺序很重要，因为系统策略默认胜出，而客户端层面的设置只能解释策略没有覆盖的情况。

策略归谁，移除的代价是什么

改动任何一项之前，先读已安装的描述文件和客户端支持的控制项。如果 Mac 受管，条件一定记录在某处，去要那份文档比从外部逆推 SSID 和域名要好。

Mac 上的信任材料与其他所有使用它的服务共享，所以吊销是最后一步，而不是第一步。先移除拥有该规则的描述文件，再确认规则不再触发，最后才碰证书。只移除一半的描述文件，正是人们断定行为随机的原因。展示装了什么的这两条命令值得留着：

profiles show -type configuration
scutil --nc list

按需重连并不能证明什么

按需重连并不能说明空档：隧道正在建立时，除非另有策略兜住，流量仍可能从物理网卡出去。在隧道存在之前就拦截，和启动隧道是两回事。重连很快的机器，最初几秒仍可能泄漏。

路由范围是第三个问题，因为启动隧道的规则并不说明它承载哪些前缀。与其假定重连就等于全覆盖，不如确认这条连接到底路由了什么。有意测试一次：退出客户端，确认服务已停止，然后请求那条规则本该保护的资源。

记录触发条件，而不是图标

写下是什么把隧道拉起来的：接入某个网络、打开某个 App、解析一个私有名称、从睡眠中唤醒。注意它什么时候发生，而不只是发生过，因为顺序本身就是证据。一个具体的触发条件，比图标的截图更有价值。

然后，在连接建立之后验证资源。菜单栏只能证明某个服务在运行，不能证明你需要的目标能通过它到达。这两者完全可能因为再普通不过的原因分道扬镳，包括路由指向了别处。

当规则拉起了错误的连接

在不该启动时启动的连接，通常来自过期的描述文件、比预期更宽的域名条件，或两套争抢同一网络的配置。三者都能在已安装的配置里看到，而开关服务一个都澄清不了。

把触发条件、描述文件的归属方和预期行为，一起带给管理策略的人。Apple 关于按需连接的文档就是这场对话的共同词汇，而且它比争论更短。请对方修改策略，而不是直接移除，这样双方都还能保留一套可用配置。