很多有跨网访问需求的用户都遇到过这类场景：开全局VPN时刷国内视频平台加载速度变慢，关掉VPN之后查海外技术文档又连不上，反复切换连接状态非常麻烦，VPN按应用分流功能就是为了解决这类场景的痛点诞生的，不需要反复启停VPN，就能让指定应用的流量走加密隧道，其余应用的流量直接走本地运营商网络，本文就完整拆解这项功能的工作原理、实现逻辑、验证方法和常见故障定位思路。
VPN按应用分流功能可让指定应用走加密隧道，其余应用直连本地网络，无需反复切换VPN状态。
VPN按应用分流的基础运行前提
这项功能并不是所有VPN客户端都默认支持，它的底层运行需要调用系统级别的流量过滤接口，比如Windows平台需要调用操作系统内置的WFP过滤框架，macOS平台需要基于Packet Filter的锚点规则做二次开发，安卓系统需要VPN服务拿到全流量拦截的特殊权限，iOS平台则要依托NEFilterProvider的官方扩展接口实现，仅靠修改系统全局路由表的简易VPN客户端，根本不具备区分不同应用流量的能力。
传统全局VPN的运行逻辑非常简单，就是把系统所有对外流量的默认路由下一跳直接指向VPN生成的虚拟网卡，所有数据包不管来自哪个应用，都会被统一送到VPN隧道里做封装加密，这类模式下系统网络栈没有机会识别数据包对应的应用来源，自然也不可能实现按应用分配转发路径的效果。
VPN按应用分流的核心工作原理流程
VPN按应用分流的第一个运行环节是流量关联绑定，系统网络栈在数据包被送出网卡之前，分流模块会先检索这个数据包对应的源进程ID，把进程ID和系统内已经注册的应用包名、进程名做一一绑定，袋鼠整个匹配过程不会只靠端口或者目标IP做判断，避免出现不同应用共用端口导致的误分流问题。
第二个运行环节是规则匹配校验，用户提前配置的分流规则会被预先加载到高速匹配队列里，比如用户指定网页浏览器走VPN隧道、本地短视频应用走普通公网，分流模块就会把当前抓取到的应用标识和规则库逐一比对，命中走VPN规则的数据包，会被直接转发给VPN虚拟网卡做后续封装。
第三个运行环节是差异化转发，命中走本地网络规则的数据包，袋鼠会被直接绕过VPN虚拟网卡，走系统默认的物理网卡网关直接发往公网，这部分流量不会经过VPN隧道的加密、封装、转发全流程，路径和没有开启VPN时的普通上网路径完全一致。
分流功能有效性的现场验证方式
普通用户不需要专业抓包工具就能完成基础验证，首先打开系统自带的任务管理器或者活动监视器，袋鼠找到你指定走本地网络的应用对应的进程ID，查看该应用对外连接的源IP地址，确认这个地址和你本地运营商分配给物理网卡的公网IP完全一致。
接下来打开你指定走VPN隧道的浏览器或者其他应用，访问公开的IP查询网页，确认该应用显示的对外公网IP和你连接的VPN节点出口IP一致，两个应用获取到的公网IP属于不同的公网地址段，就说明当前的分流规则已经正常生效。
如果是在刷了第三方固件的家用路由器上配置的VPN应用分流，直接登录路由器后台的流量统计页面就可以核验，走VPN隧道的应用产生的流量会计入虚拟隧道接口的字节统计项，走本地网络的应用流量会计入物理WAN口的普通转发统计项，不需要逐台终端做校验。
常见的分流配置误区与故障定位思路
很多用户误以为只要把目标应用加到分流列表里就一定能正常生效，袋鼠加速器官网实际上不少主流应用都采用了多进程架构，比如浏览器的后台下载进程、视频平台的后台缓存子进程，这类子进程的标识没有被默认纳入规则匹配的名单，就会出现部分流量漏走其他路径的情况，需要把该应用关联的所有子进程标识都补充进分流规则才能解决。
还有不少用户忽略了DNS请求的分流配置，误以为应用流量走VPN就等于全链路流量都走隧道，实际上如果没有单独把指定走VPN的应用的DNS查询请求也纳入分流规则，这部分DNS请求很可能被系统默认的本地DNS服务器解析，出现DNS路径和应用流量路径不匹配的问题。
如果遇到分流规则配置完成后完全不生效、所有流量都走VPN隧道的情况，首先要检查VPN客户端有没有拿到系统对应的网络过滤权限，比如macOS下有没有在系统设置的扩展管理页允许VPN的网络扩展运行，安卓系统有没有给VPN应用开放全流量访问权限，权限缺失是分流功能失效的最常见原因。
