开启 3 天免费试用
注册即可免费体验全部高级功能。
*仅限新用户；每位用户只能获得一次试用。
按应用路由与拆分隧道有何区别？规则选择、优先级与失败行为
Ryan Foster
2026年9月12日· 7 分钟阅读
按应用路由与拆分隧道是“选择条件”与“策略结果”的关系。前者依据应用身份选择路径；后者表示一部分符合条件的流量经过 VPN，另一部分走其他路径。应用身份可以造成拆分，却不是唯一选择维度。［1］［2］［3］
完整 VPN 指南介绍路由与隧道范围。本文进一步区分策略术语、规则优先级、受管部署和验证证据。
关键要点
- 按应用路由以应用身份为选择器；拆分隧道描述多路径结果。
- 拆分规则也可按目的前缀、域名、流量过滤器或多个条件组合。
- 纳入清单与排除清单有相反的默认行为和失败后果。
- 应用规则、路由、DNS 与已有连接都可能影响观察结果。
- 受管按应用 VPN 适合划分工作与个人流量，但依赖稳定身份和明确所有者。
按应用路由与拆分隧道是什么关系？
拆分隧道泛指保护路径与普通路径同时存在。一项策略可以只把企业私有网段送入 VPN；另一项策略可以让某个应用无论访问何处都进入隧道；也可以同时匹配应用和目的地。
因此，应用身份只是一个选择维度。Android VpnService.Builder 可建立允许清单，让名单内应用使用 VPN；也可建立排除清单，让名单内应用绕过 VPN，但同一个 builder 不能同时使用两者。［1］ Apple 则支持由设备管理把受管应用关联到按应用 VPN 配置。［2］
| 策略问题 | 按应用路由 | 更广义的拆分隧道 |
|---|---|---|
| 主要选择器 | 应用身份 | 应用、前缀、域名、过滤器或组合 |
| 常见单位 | 软件包、bundle 或受管应用 | 匹配策略的网络流 |
| 默认行为 | 取决于纳入或排除模型 | 取决于默认路由与规则优先级 |
| 身份依赖 | 高 | 可选 |
| 目的地判断 | 可与过滤器组合 | 常用于路由或域名拆分 |
| 管理用途 | 分开工作与个人应用 | 控制访问、可达性与策略范围 |
| 主要风险 | 应用身份错误或变化 | 规则重叠、路由/DNS 不一致或回退 |
纳入清单与排除清单有何不同？
纳入清单表示只有指定应用进入 VPN。新安装或未识别应用默认直连，范围较窄；如果要求所有工作应用都受保护，而软件包身份变化或受管注册未完成，这种默认就可能形成 fail open。
排除清单表示除明确例外外，所有应用都进入 VPN。默认覆盖更广，却可能把延迟敏感、本地或按政策豁免的流量误送入隧道。Android 文档还要求在建立接口之前确定相应清单。［1］
两种模型没有绝对安全高低。应根据“未知应用出现时最可接受的结果”选择默认项，并从管理系统取得 package 或 bundle identifier，而不是依赖显示名称。还要定义应用重装、克隆、更新或替换后的行为。
受管按应用 VPN 增加了什么？
受管部署把策略绑定到应用和设备管理状态，不要求用户手动切换。Apple 的部署文档说明，管理系统可分发按应用关联，让受管应用触发或使用指定 VPN 配置。［2］
这有助于在同一设备上划分工作和个人软件，却不代表父应用的后台服务、扩展、内嵌浏览器或系统账户都会自动继承。具体身份边界由平台规定。
应用、设备管理与 VPN 团队要统一身份、下发顺序和删除行为，否则正常隧道也可能承载错误应用。
拆分隧道还能怎样选择目的地？
路由拆分依据目的 IP 前缀，可以只安装私有网络路由，也可使用 VPN 默认路由加直连例外。Microsoft VPNv2 的路由列表与 traffic filter 表明，拆分策略并不依赖应用身份。［3］
域名策略便于描述变化中的服务，但会引入 DNS 时序、别名和缓存连接。它可能影响解析或动态路由，却不一定控制之后的每条连接。
过滤器可结合应用与网络属性，增加优先级。“工作应用访问私有 API”须落成身份、地址族、目的地、协议和失败动作。
为什么两条拆分规则会冲突？
不同策略引擎可能在不同阶段工作。设备管理先选择按应用 VPN，VPN 配置再安装路由，本地防火墙应用过滤器，应用还可能复用规则改变前建立的连接。DNS 也可能返回不在预期前缀内的地址。
优先级具有平台差异。更具体路由通常优先于默认路由，但按应用策略可能在目的路由前就选择接口上下文；代理或浏览器扩展又会增加应用层路径。因此，TUN 与系统代理不是同一种拆分控制。
测试前应为每个重要流量写表：应用身份、目的地类别、地址族、预期接口、DNS 所有者、本地网络规则与失败动作。若两个规则同时匹配，应明确谁拥有优先级，不能接受偶然出现的结果。
如何选择合适的选择器？
若安全边界跟随受管软件，应选择应用身份，例如工作应用无论 API 托管在哪里都必须使用私有网关。需要确认平台能否识别相关 helper、extension 与内嵌组件。
若边界跟随地址稳定的网络，则选目的前缀。路由表容易观察，但云服务和共享基础设施未必能用窄网段表达，不应为了让单个应用可用而加入过宽的第三方地址范围。
只有平台说明域名怎样转化为策略时，才应选择域名，并考虑别名、DNS 缓存、IPv4/IPv6 和直接 IP 连接。界面标签不足以证明执行方式。
多个选择器只应用来解决已记录的歧义。条件越多，规则重叠和遗漏越容易发生。最易维护的是有明确所有者的策略。
怎样验证拆分策略？
同时建立正向与反向测试。正向测试证明受保护流量通过预期隧道抵达获准的私有或受控端点；反向测试证明排除应用或目的地按政策直连，或在禁止直连时被阻断。
还要覆盖生命周期：受管注册前、配置下发后、应用更新后、网络切换后、隧道重启后和策略删除后。旧连接应关闭或单独标记，避免连接复用冒充新路由结果。
每次记录策略使用的应用身份、目的地址、DNS 答案、地址族、接口、出口观察和服务器日志。拆分隧道看似失效时，应按这张矩阵诊断，而不是只看公网 IP。
还应在受控环境停止隧道、使私有目的地不可达并撤销授权，观察应用是阻断、重试、提示还是直接回退。故障行为本身就是策略契约。
可否判断 AethoVPN 的路由控制？
如果要为此评估 AethoVPN，先从它明确说明的控制项入手，也就是全局模式：开启时，所有应用的流量都经 VPN 转发；关闭时，访问你所在地区网站的流量不经 AethoVPN 中转。这是按地区分流，而不是按应用选择。依赖它之前，在两种状态下各测试一个本地网站和一个境外网站。按应用列表、域名选择器和受管部署都不在 AethoVPN 的说明范围内，需要这些能力的策略应交给明确提供它们的工具。开始 3 天试用，比较两种状态。
总结
- 按应用路由是一种选择器，拆分隧道是不同流量走不同路径的总体结果。
- 纳入与排除清单为未知应用设置相反默认项。
- 前缀、域名和过滤器也能在不选择应用时形成拆分。
- 管理、路由、DNS、代理和连接状态之间的重叠必须明确解决。
- 应跨生命周期验证预期 VPN 流量，以及预期直连或阻断流量。
常见问题
按应用路由一定属于拆分隧道吗？
当指定应用走 VPN、其他应用走另一条路时，通常会形成拆分。但拆分隧道是更广的概念，也可只按目的地或域名选择。
拆分隧道可以不用应用清单吗？
可以。VPN 可按 IP 前缀、目的地、域名或流量过滤器选择，并把同一规则应用到所有程序。
纳入清单一定比排除清单安全吗？
取决于所需默认行为。纳入清单限制 VPN 范围，却可能让新工作应用直连；排除清单默认覆盖新应用，也可能把不该进入的程序纳入。
应用标识变化后会怎样？
旧规则可能不再匹配。受管系统应使用平台定义的稳定身份，并规定未匹配应用应直连还是阻断。
域名规则能代替 IP 路由吗？
不能一概而论。它依赖平台 DNS 集成，还要处理别名、缓存、变化地址、IPv6 与直接 IP 连接。
排除应用为何仍显示 VPN 地址？
它可能调用已纳入 VPN 的 helper、复用旧连接、选择另一地址族或使用应用代理。修改策略前应记录身份、目的地、路由与连接时间。
拆分流量应 fail open 还是 fail closed？
应逐类流量决定。私有工作流量通常需要 fail closed，明确排除的个人应用可以直连。预期动作必须书面化并测试。
免责声明：本文仅提供一般网络与设备管理信息。请遵守组织政策和所管理系统的规则。
来源：
- Android Developers, “VpnService.Builder”: https://developer.android.com/reference/android/net/VpnService.Builder
- Apple Platform Deployment, “Per-app VPN overview”: https://support.apple.com/en-asia/guide/deployment/depae3d361d0/web
- Microsoft Learn, “VPNv2 CSP”: https://learn.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp
Sources checked 2026 年 9 月 12 日。
延伸阅读：
