加入 Wi-Fi 会触发 iPhone 的 VPN：先把动作单独建好

两种失败从外面看完全相同：一个无法完成的 VPN 动作，和一个从未运行过的自动化。先建连接、后建触发器，一分钟左右就能把两者分开。这样做还让自动化挂在一个已经验证过的东西上，在权限问题进入谈话之前就去掉了一半变量。这个顺序不花任何代价，还能省掉触发器静默触发之后的那场混乱。

先把动作单独建好

用一个以后认得出的名字新建快捷指令，然后加入「设定 VPN」动作，指向手机里已有的那个配置。明确选择「连接」而不是开关，因为开关取决于当前状态，第二次运行会给出不同的结果。接着手动运行这个快捷指令，完成配置文件通常会要求的认证。请在手机未锁屏时做一次，这样第一次运行不会同时变成锁屏行为的测试。

如果这个配置在动作里根本不出现，就停在这里，去读提供方自己的说明。有些客户端不把连接开放给快捷指令，任何自动化都造不出这个开放。在断定动作坏了之前，先查一下应用自己的文档里有没有关于快捷指令的章节。

先证明动作可用，再信任触发器

从应用里运行这个快捷指令，看 VPN 指示是否出现，再打开一个只有走隧道才能访问的私有资源。服务失败时指示仍是绿的，那是路由问题，不是自动化问题，必须在触发器压上去之前修好。关掉应用再打开，确认服务的回答是走隧道来的，而不是来自缓存。

立刻再运行第二次。如果第二次是断开而不是连接，那这个动作其实是伪装成动作的开关，网络一变，自动化每次都会给出同样的行为。

然后再挂上 Wi-Fi 自动化

新增一个以 Wi-Fi 为触发条件的个人自动化，选中那个网络，并选择立即运行而不是先询问。把它指向你刚刚证明过的那条快捷指令。只有在判断这种可能需要人来处理的连接可以接受之后，才打开允许它在锁屏状态下运行的选项。

第一次测试时，拿着手机走出范围再走回来。先看自动化到底有没有触发，再看 VPN 做了什么。

自动化仍然做不到的事

它没法为交互式挑战提供一个人。如果配置文件弹出网页登录或要求一次性验证码，自动化就停在那儿；为了绕过它而把密码或验证码塞进文本动作，等于把一个秘密搬到保护更弱的地方。

它也没法保证在隧道准备好之前手机不发出任何流量。加入网络和完成 VPN 连接是两件独立的事，所以「隧道之前不许有流量」这种严格要求属于连接本身的强制执行策略，而不属于快捷指令的时序。

什么时候系统自带的 On Demand 更合适

对于「在蜂窝网络上连接、在指定网络上保持断开」这类长期规则，应用或受管理配置文件可以提供由系统持续评估的 On Demand 条件。两套机制提出相反的要求，只会做出一条反复抖动的隧道，所以只留一个负责人。

对可信网络例外要当心。网络名只是一个标签，任何一个接入点都能叫这个名字；与其继承一个「什么都不匹配就断开」的配置，不如有意识地决定在蜂窝网络和未知网络上分别怎样处理。