很多用户在配置VPN服务时，为了避免本地运营商DNS泄露访问记录，会手动调整VPN DNS优先级，把VPN指定的DNS服务器放在系统解析队列的最高位，但多数用户调整完之后只靠访问IP查询站点的结果判断是否生效，很容易出现“显示IP是VPN出口但DNS请求实际走本地链路”的隐蔽问题，本文的全流程实操验证方法可以帮你逐层确认VPN DNS优先级调整的实际效果，避免出现配置偏差。
调整前的基础配置前提确认
在启动VPN DNS优先级：调整后的验证方法之前，你需要先排除系统层面的基础配置错误，避免后续测试出现无效结果。Windows系统用户要先进入VPN连接的属性面板，在IPv4设置页确认已经勾选“使用远程网络的默认网关”，同时手动指定的VPN DNS服务器地址，在网卡DNS排序列表中的位置要高于物理网卡的DNS地址，否则系统会默认优先调用本地链路的DNS服务。
调整VPN DNS优先级后按全流程逐层验证，可避开隐蔽的DNS泄露问题
macOS用户需要进入网络设置面板，点击左下角的齿轮图标选择“设定服务顺序”，把当前配置的VPN服务条目拖拽到Wi-Fi或者以太网等物理网络服务的上方，macOS的系统DNS解析队列是严格按照网络服务的排序优先级调取的，如果VPN服务排在物理网卡后面，就算VPN连接成功，DNS请求也会优先走本地链路，之前的优先级调整操作完全不会生效。
第一层验证：本地系统DNS路由表排查
这一步验证不需要访问任何外部公共站点，可以完全避免外部测试站点的缓存干扰，是VPN DNS优先级：调整后的验证方法里最基础的本地校验环节。Windows用户打开管理员权限的命令提示符，输入路由打印指令查看IPv4路由表，在永久路由段查看你指定的VPN DNS服务器IP对应的下一跳地址，确认指向的是VPN虚拟网卡的网关地址，clash verge官网而不是本地物理网卡的网关。
macOS用户可以在终端输入网络配置查询指令，查看输出的DNS服务器列表，排在第一位的IP应该是你在VPN配置里指定的优先DNS地址，Linux用户可以查看系统DNS配置文件的输出内容，确认指定的VPN DNS条目出现在列表最前端。这里要注意一个常见误区，很多用户以为配置文件里排在第一位的DNS就一定生效，实际上如果系统开启了本地DNS缓存服务，实际调用的DNS顺序是由网络服务优先级决定的，不能只看文件表面内容就下结论。
第二层验证：实际DNS请求出口溯源
本地路由确认没有问题之后，就可以发起实际的DNS请求测试，这是VPN DNS优先级：调整后的验证方法里确认实际链路的核心步骤。最稳妥的方式是用系统自带的nslookup工具，分别指定不同的网卡DNS地址发起请求，先输入指令调用本地物理网卡的DNS地址解析自定义测试域名，再调用VPN指定的优先DNS地址解析同一个域名，对比两次返回结果的差异。
这里要注意不要用百度、腾讯这类公共互联网服务域名做测试，clash verge官网这类域名的全球缓存节点数量极多，不同DNS服务器返回的结果差异很小，你根本没法准确判断请求是从哪个DNS服务器返回的，最好使用你自己临时搭建的、没有公共缓存的自定义测试域名，两次返回结果的差异会非常清晰。
你还可以用网络抓包工具分别监听物理网卡和VPN虚拟网卡的53端口，也就是DNS服务的默认通信端口，观察所有你主动发起的DNS请求报文，是不是全部出现在VPN虚拟网卡的抓包结果里，没有出现在物理网卡的DNS报文序列中，如果符合这个特征，就说明DNS请求完全走了VPN链路，优先级调整确实生效。
常见优先级不匹配的故障定位场景
很多用户调整完VPN DNS优先级之后，测试发现一部分请求走本地链路、一部分请求走VPN链路，大概率是系统里安装了本地DNS加速类工具，这类工具会在后台全局劫持所有DNS请求，无视系统网卡的优先级排序，直接把请求发给预设的公共DNS服务器，这时候你完全退出这类工具之后再重新验证，大部分优先级异常问题都会自动恢复。
还有一种隐蔽的异常场景是VPN服务端已经配置了正确的DNS推送规则，但客户端系统的第三方防火墙自定义规则，拦截了发往VPN DNS服务器的53端口请求，系统就会自动降级调用下一个优先级的DNS服务器，这时候你临时关闭系统防火墙的自定义规则再重新测试，就能快速确认是不是这个原因导致的优先级失效。
最后要注意，单次测试的结果只能对应当前的系统运行状态，如果你后续安装了新的网络代理工具、修改了网卡配置，clash都有可能覆盖之前的VPN DNS优先级规则，定期重复这套验证流程，可以避免出现隐蔽的DNS链路泄露问题。
