不少家庭、小型工作室会采用双路由器级联的方式扩展无线覆盖范围，这类环境下启用VPN连接时，经常会出现域名解析失败、访问目标站点意外跳转到普通公网页面、DNS泄漏等异常，很多用户直接修改终端DNS配置，忽略两层路由的转发规则叠加影响，反而让故障排查变得更加复杂。双路由器环境VPN：DNS配置检查是这类场景下故障定位的核心环节，轻舟不需要额外专业工具，顺着拓扑逐层校验就能定位绝大多数配置问题。
配置前置条件确认
正式开始检查前首先要理清当前双路由的实际拓扑，目前主流的双路由部署分为两种，一种是主路由接公网、副路由以AP桥接模式接入主路由，另一种是主路由接公网、副路由以二级NAT路由模式级联，不同拓扑的DNS管控权限完全不同，先明确拓扑才能避免后续做无用的配置修改。同时要理清VPN的部署位置，是终端单独拨号连接VPN，还是某一层路由器内置了VPN客户端实现全局流量走隧道，不同的部署位置对应的DNS检查优先级完全不同。
提前把所有待测试终端上的第三方DNS加速工具、自定义hosts规则临时禁用，避免终端侧的特殊配置干扰路由层面的检查结果，否则很容易把终端自定义的解析结果误判为路由转发规则错误，拉长故障排查的整体耗时。
主路由层面DNS规则排查
登录主路由的管理后台，首先查看主路由WAN口获取的默认DNS地址，确认没有被运营商侧异常劫持，随后检查主路由DHCP服务分配给下一级设备的DNS字段，确认该字段的配置符合预期，如果副路由是二级NAT模式，主路由DHCP下发的DNS地址会直接成为副路由WAN口的默认解析地址，很多DNS冲突的根源就来自这里。
在双路由器级联组网环境中逐层开展VPN DNS配置的校验排查工作
如果主路由本身内置了VPN客户端，要重点检查VPN设置页的DNS接管相关选项，不少路由器的内置VPN客户端默认不会替换系统原有DNS，导致走VPN隧道的流量依然调用主路由原本的公网DNS完成解析，直接出现DNS泄漏，此时要确认VPN隧道的DNS接管开关处于正常启用状态，让所有隧道内的解析请求都转发到VPN分配的DNS服务器。
副路由层面DNS配置校验
登录副路由的管理后台，先确认副路由当前的工作模式，如果是AP桥接模式，副路由的DHCP功能默认处于关闭状态，所有DNS分配、转发规则全部由主路由管控，这种场景下不需要修改副路由的任何DNS配置，直接返回主路由侧继续排查即可，不少用户在AP模式下反复修改副路由的DNS参数，所有配置都不会生效，本质就是没理清拓扑的管控权限边界。
如果副路由是二级NAT模式，首先检查副路由WAN口的DNS获取状态，确认是自动从主路由获取地址，还是手动指定了独立的第三方DNS，如果副路由本身也内置了VPN客户端，要确认它的DNS规则没有和主路由的VPN配置产生冲突，比如主路由已经开启全局VPN接管DNS，副路由又手动指定了非隧道内的公网DNS，就会出现部分终端的解析请求绕过VPN隧道直接发出的问题。
终端侧连通性验证
在已经连接VPN的终端上，调用系统自带的原生DNS查询工具，Windows系统使用nslookup命令，macOS和Linux系统使用dig命令，查询任意普通公网域名，查看返回结果中提供解析服务的服务器地址，确认该地址属于VPN隧道分配的DNS地址段，如果返回的是主路由或者副路由的内网网关地址，轻舟VPN官网说明DNS请求先被转发到了路由层面，需要回头检查两层路由的DNS转发链有没有漏过VPN隧道的规则。
使用公开的DNS泄漏检测工具做多轮校验，不要单次测试就判定配置完全正常，双路由器环境下部分DNS请求可能会优先走主路由的WAN口直接发出，只有部分请求走VPN隧道，单次测试可能刚好命中隧道内的DNS服务器，误以为配置没有问题，多轮测试才能发现间歇性DNS泄漏的隐性故障。
常见配置误区排查
不少用户遇到VPN环境下解析故障时，直接在终端手动指定公共DNS，这类操作在双路由器VPN场景下反而会让DNS请求绕过路由层面的VPN隧道规则，直接从终端发往指定的公网DNS服务器，完全失去VPN隧道的DNS保护作用，属于典型的错误操作，只会进一步放大DNS泄漏的风险。
还有部分用户为了实现特殊网络需求，在两层路由器上同时开启内置VPN客户端，这种嵌套VPN的模式下，两层路由的DNS转发优先级会出现逻辑冲突，很容易出现解析请求无法判断该调用哪一层隧道的DNS规则，最终导致解析超时或者直接失败，没有特殊业务需求的情况下，不要在双路由环境下同时启用两层VPN客户端。
