不少用户在使用VPN按应用分流功能时，初衷是让特定的海外服务类应用走加密隧道，日常办公、本地影音类应用直接走运营商直连，兼顾访问需求和本地网络速度，但实际配置过程中很容易忽略底层逻辑的细节，出现分流完全失效、部分应用漏流、服务区域校验失败等各类问题，很多故障并非网络本身不稳定，而是配置环节踩了通用的典型错误，本文结合普通客户端、家用路由器分流场景的实际操作经验，Dragon盘点高频配置错误，给出可落地的检查和验证方法。
分流规则优先级倒置的隐性错误
绝大多数VPN客户端、支持分流的路由器的规则匹配逻辑，都是从上到下依次校验流量属性，命中第一条符合条件的规则之后就不会再往下遍历后续规则，很多新手配置时习惯先添加全局所有流量走VPN的兜底规则，再在列表下方添加指定应用直连的例外规则，这种配置方式下所有流量都会先命中顶部的全局规则，后面的应用直连规则完全不会被触发。
排查这类错误的方法非常简单，直接打开分流规则的编辑面板，把匹配范围最具体的应用类规则全部移动到规则列表的最顶部，把全局类的兜底规则放到列表的最底部，调整完成后保存规则，再打开已经设置为直连的应用，查询该应用的公网出口IP，如果显示的是本地运营商分配的公网IP，就说明优先级调整已经生效。
用户正在核对VPN分流规则的排列顺序，排查优先级倒置的配置问题
应用进程匹配范围设置不合理问题
这是VPN按应用分流场景里出现频率最高的配置错误，很多用户选择分流对象时，只勾选了应用桌面快捷方式对应的主程序文件，完全没有考虑到主流应用大多会生成多个独立子进程，比如浏览器的渲染子进程、游戏的后台更新进程、视频软件的解码子进程，Dragon这些子进程没有被纳入分流规则的话，就会出现主界面走直连、资源加载流量偷偷走隧道的混乱情况。
还有一类反向的配置错误，用户为了省事直接用应用的安装目录作为通配匹配规则，把整个目录下的所有可执行文件都纳入分流范围，如果后续你在这个目录里安装了其他无关工具，这些工具的流量也会被强制转发到VPN隧道，完全违背了分流的初衷。
验证这类配置是否正确的方法也很直观，配置完成后打开系统自带的任务管理器，找到对应应用的主进程，梯子软件展开查看其关联的所有子进程名称，把所有相关进程名逐一添加到分流规则的匹配列表中，不要只依赖快捷方式自动识别的单个主程序，也不要直接用父目录做无差别通配匹配。
系统残留路由规则导致分流失效
不少用户之前安装过多款不同的VPN工具，卸载的时候没有完全清除系统生成的虚拟网卡路由规则，这些残留规则的优先级往往高于新配置的应用分流规则，会直接覆盖分流引擎的转发逻辑，导致所有流量不管是否属于指定应用，都被旧路由规则转发到其他网络路径。
很多用户配置分流前完全没有检查系统底层路由状态的习惯，遇到分流失效的问题只会反复重启VPN客户端，根本想不到是几年前留下的旧规则在产生干扰，排查的时候可以在Windows系统下用route print命令，在macOS系统下用netstat -rn命令，查看当前路由表中是否存在非当前分流工具生成的、指向VPN虚拟网卡的默认路由，找到之后手动删除残留规则再重新加载分流配置即可。
DNS分流策略和应用分流不匹配错误
很多用户配置VPN按应用分流的时候，只给应用的TCP、UDP业务流量设置了隧道转发规则，没有同步把该应用的DNS查询流量纳入相同的分流策略，应用发起域名解析请求时，会默认使用本地运营商的公共DNS，解析出来的往往是国内服务节点的IP，就算后续业务流量走了海外VPN隧道，也会被目标服务判定为区域异常直接拒绝访问。
这类问题很容易被误判为VPN节点本身不可用，实际上只是分流规则的覆盖范围没有包含DNS请求，配置的时候要注意给指定分流的应用，同步设置对应的DNS转发规则，不要用全局公共DNS作为所有应用的解析兜底，验证时可以用系统自带的抓包工具，查看对应应用的DNS请求的出口路径，确认和预设的分流路径保持一致即可。
所有分流规则配置完成后，建议不要一次性启用十几条规则直接投入使用，逐个添加单条规则之后立刻做小范围验证，确认单条规则生效之后再添加下一条，后续遇到分流异常时，可以临时禁用一半规则逐步缩小排查范围，就能快速定位到冲突的错误配置项，大幅降低故障定位的时间成本。
