很多用户调整VPN分流DNS规则之后，经常遇到看似配置保存成功，实际部分域名解析还是走了错误链路，云帆加速器手机版使用教程甚至出现隐性DNS泄露的问题，大部分故障都源于没有用正确的验证方法做全链路校验，本文从实际排查场景出发，完整梳理VPN分流DNS：调整后的验证方法全流程，从现象核对到故障定位全部采用可落地的实操步骤，不需要依赖特殊付费工具就能完成校验。
调整前的基础配置校验前提
正式启动验证之前，首先要确认你修改的分流规则已经完整保存，并且对应的VPN服务已经重启加载了新配置，不少用户刚修改完规则没有重启服务就直接测试，得到的结果还是旧配置的运行状态，完全不具备参考价值。
验证前需确认VPN服务已重启加载新配置，恢复系统默认运营商DNS避免测试结果偏差。
接下来要把设备系统层面的全局DNS恢复成运营商默认分配的地址，不要手动提前设置公共第三方DNS，否则手动指定的DNS优先级会高于分流规则里的链路DNS配置，直接覆盖分流规则的生效逻辑，导致后续所有测试结果都出现偏差。
最后还要临时关闭系统和浏览器自带的DNS over HTTPS、DNS over TLS这类加密解析功能，这类加密解析请求会绕过系统层面的分流路由规则，直接向加密DNS服务器发起请求，你后续的抓包校验根本看不到真实的DNS请求流向。
第一级验证：分流规则匹配性初检
初检阶段优先用系统自带的命令行解析工具完成测试，Windows系统可以打开命令提示符使用nslookup指令，MacOS和Linux系统可以直接用dig指令，不需要安装额外软件就能拿到最原生的解析请求结果。
首先测试你设定的走直连链路的域名或网段，比如国内常用的公共服务域名，发起解析请求之后，观察返回结果里的解析服务器地址，预期结果是该地址属于你本地运营商分配的默认DNS地址段，而非VPN节点侧分配的远端DNS地址。如果这里返回的是VPN侧的DNS，说明你分流规则里的直连网段匹配条目存在遗漏，对应的DNS请求没有被分配到直连链路。
接下来测试你设定的走VPN分流链路的域名或网段，同样用命令行工具发起解析请求，预期返回的解析服务器地址是你在VPN分流配置里手动指定的远端DNS地址，而非本地运营商的默认DNS。如果这里返回的是本地DNS，说明VPN分流的规则匹配条件设置错误，对应的域名没有被路由到VPN虚拟网卡。
第二级验证：链路DNS泄露深度排查
完成初检之后，还需要排查隐性的DNS泄露问题，不少用户在命令行测试正常，但打开浏览器访问页面时还是会出现DNS请求跨链路的问题，这是因为浏览器的预解析、历史缓存机制会发起额外的后台解析请求，干扰测试结果。
你需要先完全关闭所有浏览器进程，执行清空本地DNS缓存的系统指令，再使用轻量开源的抓包工具，分别对物理网卡和VPN虚拟网卡的53端口DNS请求做定向抓取。
观察抓包记录里的所有DNS请求流向，预期结果是所有命中直连分流规则的DNS请求，云帆只会出现在物理网卡的抓包记录里，所有命中VPN分流规则的DNS请求，只会出现在VPN虚拟网卡的抓包记录里，不存在跨网卡传输的异常DNS请求。
如果抓包过程中发现本该走直连的DNS请求出现在VPN虚拟网卡的记录里，大概率是分流规则的优先级排序设置错误，高优先级的VPN网段规则覆盖了低优先级的直连规则，调整规则排序之后重新加载配置再测试即可。
常见验证误区的避坑说明
很多用户习惯直接使用公网上的DNS泄露检测网站一键获取结果，这类网站的检测逻辑大多是基于境外服务器的回包做判断，只能识别全量DNS走VPN的场景，云帆没法精准区分你是全量走VPN还是分流走DNS，只能作为辅助参考，不能当做验证通过的唯一依据。
还有不少用户测试的时候只测一两个常用域名就判定配置完全生效，实际上如果你的分流规则是基于域名前缀匹配的，很可能只有你测试的这两个域名刚好命中规则，其他未命中规则的域名会走系统默认链路，必须覆盖直连和分流两类场景的多个不同域名做交叉验证，才能确认规则全量生效。
另外要注意每次调整完分流DNS配置之后，要等系统的全局路由表完全刷新完成之后再发起测试，不要刚点完保存配置就立刻发起解析请求，这时候路由表还处于更新的中间状态，解析请求会走临时链路，得到的测试结果无法反映真实的配置运行状态。
