共享服务取数据时，按应用划分的 VPN 例外会失效

你把某个应用从 VPN 中排除，它需要的下载仍然失败；更糟的是，它开始工作，而另一个毫不相关的功能停了。可见的窗口不一定是打开每个连接的进程：应用可以把工作交给辅助程序、后台传输服务或完全另一个包。因此，按应用的规则需要平台真实的身份模型，而不是熟悉的启动器文件名。下面的检查从观察出发，回溯到真正发出请求的一方。

这类工单通常同时出两个问题：排除了错误的组件，而且排除之后从不收窄范围。

找进程，不要找窗口

复现失败的操作，并在它发生时识别持有该连接的进程或包。在 Windows 上，这与哪个窗口有焦点是不同的问题，因为后台传输可能由一个以自身身份运行的服做中介。在 Linux 和 macOS 上，同样的分裂表现为辅助进程和系统守护进程。

记下三个细节：可执行文件或包的身份、它当时联系的目标，以及它在工作流中发生的时间点。开始时失败的下载，往往是另一个组件在取元数据，而不是中途失败的下载。仅凭这一差别，通常就足以在改规则之前选对身份。如果身份其实是服务而不是应用，这一事实会改变整条规则，所以要先确认。

如果操作太短而无法观察进程，就用更大的负载或更慢的目标重做一次。目标是得到一次可复现的观察，而不是猜测涉及哪个辅助程序。

把 DNS 当作独立路径

系统名称解析可能完全不跟随被排除的应用，所以被排除的浏览器仍可能在私有主机名上失败，而它的流量确实正确地走在隧道之外。被排除的是浏览器，不是解析器。

检查按应用规则生效时平台如何处理 DNS，并把它与 HTTP 请求分开检查。如果解析器是共享服务，它服务于设备上的每个应用，那么你正在考虑的例外，影响面远大于你测试的那一个。

记录是哪个解析器、通过哪个接口作答。仅这一项观察就能解决很大一部分「应用已排除但名称解析不了」的报告，所以要把它和工单放在一起。

不要扩大共享辅助程序

共享服务为多个应用工作，所以为了修好一个工作流而排除它，也会改变不相关的流量。Windows 上的后台智能传输服务就是这种形态的好例子：它是许多应用都能使用的基础设施，其身份并不是请求传输的那个应用的身份。

在添加该例外之前，检查客户端支持的规则模型和组织的要求。问清楚还有谁在使用该组件，以及你准备写的规则能否针对目标而不是针对共享进程来表达。

如果这项要求根本无法表达为应用边界，基于目标的策略或其他经批准的设计，可能比不断增长的一串辅助程序例外更容易理解，也更安全。

测试整个工作流，而不只是失败的那一步

在受支持的变更之后，用一次全新请求把预定任务从头到尾跑一遍。然后跑另一个使用该共享组件的工作流，因为广泛的绕过正是在那里暴露自己。修好第一个却悄悄弄坏第二个，不叫修复。把两个结果都留在工单里，并明确写出第二个工作流，方便复核者复现。

让测试保持小而可重复：同一目标、同一账户、同一条件。如果第二个工作流没有文档，先问它的负责人依赖什么，再判断这次变更是否安全。

留下理由，而不是名单

记录该组件、它服务的工作流，以及它被排除的原因。没有关联目的的辅助程序名单，两个发布周期内就会变得无法维护，下一位工程师在清理时会删错条目。

每条例外一行就够：没有它什么会坏、谁负责那个工作流、上次验证是什么时候。这三个字段能把一份谜一样的名单变成有人可以为之辩护的策略。