VPN 连接后 Handoff 失效：该检查什么

在 iPhone 上打开一个网页，走到 Mac 旁边，Dock 图标却没有出现。关掉 VPN 就好了。这个序列看起来像 VPN 问题，而且往往确实是，但不是人们以为的那个原因：Handoff 是本地设备间的功能，隧道干扰的是本地那一段，而不是互联网那一段。

只修一个任务和一对设备

选一个支持 Handoff 的任务，比如 Safari 里的网页或 Notes 里的草稿，以及一对设备。保持应用、账户和物理位置不变，一次只改一个变量。同时动三样东西的测试，得到的观察结果你没法用。

Handoff 是任务接续，不是投屏，也不是文件共享。如果需求是镜像屏幕或挂载共享，你调试的是另一项功能，前提条件也不同。

把确切的任务写下来，因为任何修复的验证标准就是这同一个任务能跑通。

前提条件是本地的，不是远程的

Apple 对 Handoff 的要求是：附近有兼容设备、两台设备都开启 Wi-Fi 和 Bluetooth、登录同一个 Apple Account、并开启 Handoff。要查的是用于 Continuity 的账户，而不是购买应用的账户，因为在共用 Mac 上两者可能不同。然后确认应用和任务确实支持 Handoff，因为随便一个应用开着并不能证明什么。这些检查成本很低，应该最先排除。

这一切都通过本地无线完成。Bluetooth 广播活动，Wi-Fi 承载数据，所以即使两台都能上网，设备也必须靠得很近。

这些都不取决于任何一台设备使用的公网地址。

VPN 客户端对本地流量做了什么

全局隧道客户端可能连同其他流量一起捕获本地子网，除非你允许本地网络访问，有些客户端正是这样做的。Apple 提醒，阻止本地联网的 VPN 配置可能干扰 Continuity 功能。这句话说的是客户端的策略，而不是某个被封锁的端口。

许多客户端提供本地访问例外；启用前先读清楚它允许什么，并且优先选择厂商支持的选项，而不是手工改防火墙规则。

如果客户端没有这个选项，这个设计决定属于部署的所有者。

共用出口给不了你什么

两台设备使用同一个 VPN 服务器，只共享一个出口地址，也仅此而已。它不会产生 Bluetooth 广播，不会把它们放到同一条本地链路上，也不会修好不匹配的 Apple Account。把共同的公网地址当作前提，是范畴错误，会导致毫无意义的客户端改动。

VPN 服务上的订阅者隔离，也和附近两台设备接续任务不是一回事，所以开放订阅者之间的转发不是 Handoff 的步骤。

基于路由器的 VPN 改变的是哪套策略作用于设备，它仍然补不上缺失的无线或账户。

和策略所有者一起决定，然后验证两个结果

三个条件决定怎么修。关掉 VPN 时前提链条还成立吗？客户端有没有受支持的本地访问选项，策略允许吗？还有，你能否在不削弱隧道本来要提供的保护的前提下验证这次改动？如果第三个答案是否定的，这次改动需要管理员，而不是绕路方案。

获批改动之后，两个结果都要确认：任务在附近设备上接续，需要隧道的应用保持预期的访问和拦截行为。

把例外记录在那条连接的配置旁边，否则下一次配置文件更新会悄悄把它删掉。