拆分隧道为何覆盖不到应用的更新

你把应用加入拆分隧道的排除列表，应用直连互联网，更新却仍然失败，或者仍然在隧道里慢吞吞地走。排除本身是生效的。它只是覆盖了另一个进程，而不是真正执行下载的那个进程，因为现代更新程序很少和应用窗口是同一个可执行文件。

误区：排除应用就等于排除它的流量

按应用拆分的隧道匹配的是进程、安装包或应用路径，取决于平台。它并不匹配品牌、功能或用户意图。当应用把下载交给辅助程序、共享的平台服务或浏览器组件时，那个辅助程序有自己的身份，也有自己穿越隧道的路径。排除列表根本不知道这两个进程属于同一个产品。它只知道你点名的那一个。

所以规则只是照做而已。关于谁拥有这次传输的假设错了，修复的起点是找出那个归属者，而不是继续加排除项。

找出传输的归属者

在 Android 上，更新可能由共享的服务包取回，而不是你排除的那个应用包，而按应用生效的 VPN 规则作用于打开套接字的那个包。在 Windows 上，更新服务可能在与应用不同的可执行路径下运行，所以只匹配应用路径的规则会漏掉它。在 macOS 上，可能由特权辅助程序或系统更新守护进程完成传输，应用只是发出请求。

用证据确认归属者：平台的网络活动视图、按进程过滤的抓包，或者明确写出更新组件名称的厂商文档。只凭进程名猜测，正是两个相似的二进制文件被搞混、结果排除错的那一个的原因。

更新系统往往也会拆分工作。一个很小的元数据请求用来检查版本，而大得多的安装包下载则去往内容分发主机或另一个域名。元数据检查可以顺利穿过隧道，安装包传输却卡在隧道走了另一条路由的主机上。这种拆分能解释那份令人困惑的报告：更新被检测到了，却始终装不上。要测试的是安装包下载本身，用同一台设备、同一个网络，而不是测试应用能不能打开。

校验能经受路由变化

换一条路由并不取代 TLS、发布者身份或安装包签名校验。不要因为下载只有在点掉一个来路不明的证书警告之后才成功，就把这些校验关掉。只在被排除路径上出现的警告是一条线索，不是障碍。先查清它，再扩大绕过范围。

在受管理的设备上，应当申请受支持的例外，而不是为每个系统服务都加一条大范围规则。为了修好一个更新程序而排除所有共享服务，会让绕过范围远远超出最初的请求。

先测试更新，再记录归属者

改动之后重新连接，并再次确认生效的规则，因为有些客户端会在隧道重连时重建路由。跑完一个完整的更新周期：检查、下载、校验、安装。检查成功只证明了整条路径中最小的那一段。

把传输的归属者、目标主机和预期路由记录在与拆分隧道规则相同的地方。否则，下一次更新机制变动就会悄悄让这条例外失效，而接手的人将无从知道这条规则是为哪个进程写的。