iPhone 按需 VPN 连的是办公室 Wi-Fi，不是蜂窝网络

九点，手机接入办公室的无线网络，隧道自己建立起来，然后一整天都保持连接。蜂窝网络随后的表现完全符合所有人的本意。几周前有人为公司网络加了一条排除，所以配置档案在审查时显得很干净，可每天早上仍然得到同样的结果。设备在遵循它被给予的那份列表，而列表所说的，与它的作者所相信的并不相同。

列表从上往下读，第一条匹配的说了算

条目按顺序评估。第一个条件成立的条目决定那一刻的结果，它下面的一切从此不再被查看。因此顺序本身的意义，不亚于规则内部写下的任何条件。从上往下读这个数组，就能解释一个看起来无视了明明包含在其中的排除的配置档案。

把一条通用的无线连接条目放在办公室排除之前，现场就必然建起隧道。要让行为翻转，载荷里别的什么都不用动。

断开条目做两件事

当动作是断开时，该条目会关闭已经运行的会话，并在条件仍然成立期间阻止新建会话。两半对一条排除都很重要，而第二半往往被忘掉。同一条目出现在第二个配置档案里，就能解释某层楼在其他地方都正常时 VPN 却拒绝启动。没人动过隧道；是列表动了。

表格展示了它的形状，排除在前，其中的名称必须来自你自己的部署。通常两条条目就够了，第三条给蜂窝网络，剩下的就可预测了。

把两个条件都留在排除上

把网络名称和接口类型配成一对。只有名称时，一条携带相同标签的网络共享链路也可能触发；只有接口类型时，用户当天去过的每一个无线网络都会被排除。两半属于同一条条目，而不是碰巧相邻的两条规则。

名称比较是精确的，并且区分大小写。这适合一个已知网络，在别处却处处吃紧，因为访客网络会重复使用熟悉的标签，站点在合并后会被改名，而有线工位根本不带名称。向网络团队要准确的标签，而不是从墙上的牌子上去读。

当探测胜过名称

探测条目请求一个 URL，并把成功的应答读作条件成立。选一台只从内部应答的主机，比如无法公开解析的内网服务，规则就不再在乎网络自己叫什么。从任何地方都能应答的探测，检验的是互联网，而不是这栋楼。决定这套做法是否奏效的性质，是应答在不经过重定向的情况下到达；一个把每个请求都弹回去的访客门户，会把探测变成噪声。

基于域名的规则是另一种形式：NEEvaluateConnectionRule 匹配请求的域名，并能在查询某个名称时建立连接。它的通配符只接受作为最左侧的标签，因此 *.example.com 有效，而 example.*.com 无效。如果某个配置档案既不用接口条件也不用可达性探测，那就检查它是不是改用了这种规则类型。

按需规则管不到的事

规则选择隧道是否启动，对让它保持运行没有发言权。会话出现、几分钟后又消失，指向的是空闲计时器、网关会话上限或路径大小。每一种都留下不同的痕迹，这正是要先排除规则列表、再改动其中任何一项的理由。保活设置解释不了这种模式，改动它们只是把工作挪了个地方，并没有碰到原因。

用户可以在设置里关掉按需功能，而受管理的分配会在下一次签到时把它恢复。当开关总是滑回原来的位置时，分配才是主动的一方。这个区别很重要，因为强制会自己回来，而提议会一直关着。

确认设备归哪个配置档案组所有，以及意图是强制建立隧道，还是仅仅提供它。这个答案决定了用户偏好算是一个缺陷，还是一项功能。