问题场景
用户希望工作应用走VPN，本地打印、网银或低延迟应用保持直连。
先建立对照基线
关闭分流并确认全局连接正常，列出准备包含和排除的应用。
本次需要控制的变量
按应用、域名和IP的分流规则覆盖范围不同，系统DNS也可能不随应用分开。
执行步骤
- 先只添加一个测试应用到包含清单。
- 分别在包含与排除应用中检查网络出口。
- 测试本地局域网设备是否仍可访问。
- 重启客户端后确认规则仍然保存。
怎样解读现象
界面显示规则不代表实际流量一定按预期。必须用两个应用分别验证，并留意共享系统服务。
最容易出现的误判
混淆“只有所选应用走VPN”和“所选应用不走VPN”两种相反模式。
先画出哪些流量应该经过VPN
分流不是简单的开或关。测试前列出必须经VPN的应用、应保持本地访问的设备与不确定项目，再决定按应用还是按目标地址配置。清单能防止把支付、公司系统或局域网设备误放到错误路径。
系统更新、浏览器辅助进程和应用内嵌网页可能不跟随主程序规则。只看到应用图标被加入列表，不能证明它产生的全部连接都按预期分流，需要用无敏感数据的任务逐项验证。
分别验证出口、DNS和局域网
为经VPN与直连的应用各准备一个可识别出口的测试，再检查域名解析是否符合预期。若启用局域网访问，确认打印机或存储设备可用，同时验证这些设备不会被错误暴露到公网。每次只修改一条规则。
切换Wi-Fi、重启客户端和设备休眠后还要复测，因为部分规则只在初次连接时加载。恢复后路径发生变化而界面没有提示，应记录为稳定性风险，而不是单次配置成功。
默认拒绝比模糊放行更容易解释
涉及工作资料或隐私任务时，规则不明确的应用应先进入受保护路径；确认确有兼容问题后再建立例外。例外要写明用途、创建日期和复查条件，避免半年后没人知道为何被排除。
分流会降低排障直观性。报告需要附上规则类型、测试应用版本和失败时的实际出口，不用“智能分流正常”这样的笼统表述。若客户端无法显示规则范围，应明确指出可验证边界。
分流规则需要定期复查的原因
应用升级可能新增辅助进程，系统重启也可能改变规则加载顺序。每月或重要更新后，重新验证受保护应用、直连应用、DNS和局域网访问，并删除已经卸载软件留下的例外。规则备注写清创建目的和日期。
验收表中同时记录界面配置和实际出口，两者不一致时以可观察流量为准并标记异常。企业设备遵循管理员策略，不自行建立绕过。分流越复杂，越应缩小例外范围，避免长期无人理解的隐私缺口。
遇到支付或身份验证失败时，先暂时停用单条例外并复测，不要清空整套规则。确认具体冲突后，为该应用写下最小范围的处理方案；问题消失或应用版本改变，再把例外撤销并重新验收。
本次复查清单
- 直连基线已记录
- 每轮只改一个变量
- 失败样本保留
- 环境和版本写完整
- 恢复动作可撤回
- 结论标明适用范围
参考资料
以下资料于 2026-08-20 核对。系统界面、订阅政策与技术规范可能更新，操作前请查看来源最新版本。