在 OpenVPN 里勾选了一个应用？决定权在列表基准
同一个勾选的包，含义是包含还是排除，取决于列表的基准。先选“仅包含”基准，重新连接，然后测试整条工作流程。
复选框看起来像全部决定，在 Android 上却不是。同一个被勾选的包，在“仅包含”基准下意味着“只有这个应用走 VPN”，在“排除所选”基准下却意味着“这个应用跳过 VPN”。人们装上客户端，看到标注为“已允许的应用”的列表，勾上唯一在意的那个包，然后带着一条效果相反的策略离开。换客户端很少有用；在动列表之前先选好基准才有用。
基准才是策略，复选框不是
在 Android 的 VpnService 之下，客户端用 addAllowedApplication 或 addDisallowedApplication 来配置按应用分流。前者把隧道限制在所列的包内，后者让除它们之外的一切走隧道。客户端会把两者包进看起来很相似的界面，有的还按列表而非按模式给该区域命名，所以只看区块标题无法判断当前启用的是哪种基准。
要读列表上方的模式控件，而不是标题。在上游的 OpenVPN for Android 客户端里，已允许应用列表有“仅包含”和“排除所选”两种基准，品牌改版可以换一套措辞却保留这两种行为。来自别的客户端、或同一客户端旧版本的截图，都不能证明你当前处于哪种模式。
| What the client shows | What a checked app gets |
|---|---|
| Allowed apps, include-only baseline | The app uses the tunnel; unchecked apps do not |
| Allowed apps, exclude-selected baseline | The app bypasses the tunnel; everything else uses it |
| No list configured | Client or profile default, commonly all apps |
那张表就是全部的误解。勾选应用只是对一个包作出的陈述；这条陈述是“包含”还是“排除”，由基准决定。
先选模式，再选包
按这个顺序做，因为在一种基准下做出的选择可能跨过模式切换继续存在，并悄悄把效果反过来：
- 确认真实的包名，以及它是个人副本还是工作资料副本。
- 打开你实际连接的那个 VPN 配置的应用选择设置。
- 把含义为“只有选中的应用使用 VPN”的基准设好。
- 把目标包包含进来，让无关应用留在集合之外。
- 重新连接，让客户端按新列表重建接口。
配置和包同样重要。一个客户端可以有多个配置，而按应用的选择属于你真正连接的那个；编辑一个从不使用的配置不会改变任何东西。在受管设备上，工作资料是单独的用户，有自己的应用副本和自己的策略，所以个人实例在隧道里，并不能说明工作实例如何。
先重新连接，再判断结果
隧道接口建立时，VpnService 才会读取应用列表。正在运行的隧道不一定接收列表的改动，而各客户端也不同：有的自动重建，有的要等你断开再连。
如果改动看起来毫无作用，先测重新连接，再去怀疑列表。然后发出一个新请求，而不是刷新一个早就打开的页面：保持已建立连接的应用是糟糕的测试对象，你看到的结果可能属于旧接口。
你的工作流程可能离开该应用
应用可能把工作交给浏览器登录、文档查看器或分享目标。在“仅包含”基准下，这些帮手都在隧道之外，所以即使第一个应用配置正确，流程也可能中途失败。只有流程确实需要时才把帮手包含进来，并且主动添加，而不是在演示时才发现。
按应用选择也不能取代连接自身的路由策略。配置仍须承载应用所使用的目的前缀和地址族，网关仍须放行该服务。一个被正确列入、但目的地不可达的应用，看起来和配置错误的列表一模一样。
两边都测，然后把策略写下来
在被包含的应用里测一个新请求，再在应当留在外面的应用里测一个。比较出口地址和对私有资源的访问，然后在重新连接后再重复一次。如果你的组织使用 Android 的“无 VPN 时阻断连接”策略，被排除的应用可能被直接阻断而不是直连；那是策略在起作用，不是需要绕开的故障。
记录模式、带配置的包名、哪些应用应当绕过、隧道承载哪些地址族，以及隧道断开时应当发生什么。如果客户端无法干净地表达这条流程，就选择更宽的已批准应用集合或受管配置策略，而不是在 root 层改防火墙规则——那并不属于 Android 支持的按应用机制。