很多用户配置VPN按应用分流规则之后，经常出现指定应用没走VPN隧道、非指定应用反而被分流的异常，单纯靠应用访问是否流畅判断路径是否正确很容易出现误判，这套VPN按应用分流访问路径验证的实操方法从现象溯源、逐项排查，确认分流规则的实际生效状态，避免后续出现业务访问异常、预设的隐私边界超出预期的问题。
正式开展分流路径验证前，先完成VPN模式校验、待测应用后台进程清理，避免残留连接干扰验证结果
配置前的基础前提校验
正式启动验证流程之前不能直接打开待测试应用，首先要确认当前设备的VPN分流模式确实是按应用分流，快喵VPN不是全局分流或者按域名分流，不少用户误把全局VPN模式当成分流模式，后续所有验证结果都会完全失去参考价值。
提前把待验证的两类应用分别列出来，一类是规则里明确指定走VPN隧道的应用，另一类是规则里明确指定走本地公网的应用，两类应用都要彻底关闭后台进程，避免之前残留的长连接网络连接干扰后续的验证结果。
第一阶段：基础连通性初验
先启动VPN连接，确认VPN隧道本身已经成功建立，不要直接打开待验证应用，先打开系统自带的路由表查看工具，查看当前设备的默认路由指向，正常按应用分流模式下，默认路由还是指向本地运营商网关，只有分流规则匹配的应用生成的专属路由条目才会指向VPN虚拟网卡。
先启动一个规则里指定走本地公网的应用，比如系统自带的默认浏览器，打开普通公网IP查询站点，记录当前显示的公网出口IP，这个IP应该和你没开VPN之前的本地公网IP完全一致，这一步如果显示的是VPN节点的IP，就说明分流规则的排除条目没有生效，不需要往下推进验证流程，先返回调整分流规则的应用匹配列表。
完全关闭刚才的公网应用，清空所有后台残留进程，再启动一个规则里指定走VPN隧道的应用，同样在这个应用内部访问公网IP查询的网页或者内置的网络诊断功能，记录返回的出口IP，正常情况下这里显示的应该是你连接的VPN节点的出口IP，而不是本地公网IP。
第二阶段：深度路径抓包核验
初验通过之后，为了避免应用本身内置代理绕过分流规则的特殊情况，需要分别在本地物理网卡和VPN虚拟网卡上开启抓包，同时运行待验证的走VPN的应用，查看VPN虚拟网卡的抓包记录里有没有对应应用的进程发出的出站数据包。
切换抓包对象到本地物理网卡，查看同一时段内，快喵这个指定走VPN的应用的数据包有没有出现在物理网卡的抓包记录里，正常完全生效的分流规则下，这类应用的所有对外数据包都只会出现在VPN虚拟网卡的抓包结果中，不会出现在本地物理网卡的出站记录里。
再用同样的抓包方式验证走本地公网的应用，这类应用的所有出站数据包都应该只出现在本地物理网卡的抓包记录里，快喵VPN虚拟网卡的抓包结果里不会出现对应应用的进程标识的数据包。
常见异常现象与故障定位
如果出现指定走VPN的应用部分流量走了本地公网，大概率是这个应用有多个独立的子进程，你之前的分流规则只匹配了主进程，没有覆盖到所有子进程，需要把应用相关的所有进程名都加入分流匹配列表再重新验证。
如果出现非指定应用的流量意外走了VPN，要检查你用的分流工具的匹配优先级，很多工具的默认规则是“除了列表里的应用都走VPN”，和你预期的“只有列表里的应用走VPN”逻辑完全相反，调整规则逻辑之后再重新做全流程验证。
这套VPN按应用分流访问路径验证方法只能确认当前配置下的分流访问路径生效状态，不能保证所有应用后续版本更新之后进程名变化还能继续匹配，每次应用大版本更新之后都要重新做一次路径验证，快喵VPN避免分流规则意外失效超出预设的隐私边界。
