iPhone VPN 关闭后仍会自动重连：是谁在启动它？

在 iPhone 的 VPN 上点按断开，打开浏览器，页面还没加载完隧道就又起来了，开关看起来像是坏了。它通常是在按设计工作，只是不符合用户的意图。断开只结束了一次会话；还有别的东西仍然拥有发起新会话的权限。在 iOS 上，三种不同的责任方都能做到这一点，而它们留下的重连时机各不相同。

断开不等于停用

手动断开会告诉隧道停止。它并不一定告诉系统停止索取隧道。按需连接规则、服务商应用自己的自动连接策略，以及受管的“始终开启”配置，都会在一次断开后继续存在，而且每一种都能在用户不碰任何东西的情况下重新发起连接。

这个区别很重要，因为解决方案在责任方手里。把开关按得更用力从来没用，而删除描述文件是比问题所需的动作大得多的一步。先找到触发动因，再决定是否该由你来改它。这个顺序也能避免你为了追查住在别处的规则，反而把能用的配置删掉。

按需连接会对操作系统评估的条件作出反应：加入某个网络，或涉及规则所匹配域名的请求。服务商应用可以在应用启动时、或它自己的后台策略决定时发起连接。受管的“始终开启”部署是设备层面的要求，用户根本不应绕过它。

看看重连之前发生了什么事件，责任方就相当明显了。这就是可编辑的规则与只能询问的策略之间的差别。

按需行为是一份有序列表。每个条目匹配一个条件并产生一个动作：连接、断开、评估一次连接尝试，或忽略。排在断开规则之前的连接规则，只要两者都匹配就会胜出，这就是手动断开后设备立刻重连的原因。

规则也可以由域名驱动，按请求中的主机名匹配，而不是按网络接口变化匹配。这正是“我一打开内网站点 VPN 就回来”背后的模式，它指向安装该规则的服务商或描述文件，而不是 iOS 本身。

在受监督、受管理的设备上，组织可以要求 VPN 保持开启，并剥夺用户关闭它的能力。在“设置”里怎么切都改变不了这一点，诚实地说，这个行为属于管理员的策略。

问清楚适用哪条策略，以及是否存在例外流程。删除已安装的管理描述文件并不是受支持的做法；它会移除设备依赖的其他配置，还可能破坏合规上报。

让描述文件保持安装，断开连接，然后重复此前重新拉起隧道的那件事：加入同一个 Wi-Fi、打开同一个应用、请求同一个内部名称。如果隧道在那一刻回来，你就已定位触发动因，可以去找拥有它的那个设置。

在责任方那里改动一个设置，再重复同样的测试。如果重连停止，你就得到了答案；如果仍在继续，触发动因就在别处，而描述文件从来不是问题。仍躺在“文件”里的已下载设置文件也不是已安装的配置，所以删掉文件并不能证明什么。

有用的结果是一句你能写下的话：这条连接由这条规则或策略启动，归这一方所有。一旦成立，开关就不再显得不可预测，下一位报告问题的人也能得到直接答复，而不是再重装一次。