不少家用用户在自行编译OpenWrt固件、完成VPN隧道搭建后，默认以为所有内网设备的流量都会走加密隧道传输，实际使用时却可能出现DNS请求漏出、本地运营商能获取到所有域名访问记录的问题，本文针对OpenWrt VPN场景下的DNS配置检查全流程给出可落地的操作步骤，覆盖从路由器后台配置到端侧验证的全环节，帮用户定位大部分常见的DNS泄漏故障。
配置前的前置确认条件
正式开展OpenWrt VPN的DNS配置检查前，首先要确认VPN隧道本身处于正常连通状态，登录OpenWrt后台的网络-接口页面，找到对应的VPN虚拟接口条目，确认接口已经成功获取到远端分配的虚拟IP地址，隧道握手状态显示为已连接，不要刚点击VPN连接按钮就立刻开展DNS检查，部分VPN协议的密钥协商、路由下发流程需要一定时间，未完成全流程的隧道会默认 fallback 到本地WAN口转发流量。
家用用户在书房桌面操作设备，排查OpenWrt VPN场景下的DNS配置泄漏问题
同时要确认你当前的VPN运行模式符合全流量走隧道的前提，如果你本身配置的是域名分流、仅指定流量走VPN的规则，那部分DNS请求走本地运营商链路属于预期设计行为，不属于DNS泄漏的排查范畴，不要混淆配置目标导致不必要的调试操作。
OpenWrt本地侧DNS配置逐项检查
首先回到OpenWrt的网络-接口页面，点击VPN虚拟接口的编辑按钮，在高级设置分类下找到DNS服务器字段，免费vpn确认这里已经自动填充了VPN服务商分配的DNS地址，或者你手动填入了指定的上游DNS地址，如果这个字段完全为空，OpenWrt会默认复用WAN口获取的运营商DNS服务器地址，哪怕后续所有流量都走VPN隧道，DNS请求也会优先发往本地运营商的服务器。
接下来进入网络-DHCP/DNS设置页面，找到DNS转发配置项，排查这里有没有手动填入非VPN侧的公共DNS地址，很多用户之前为了实现去广告、防DNS污染需求，会在这里提前填入公共DNS服务器地址，这类配置的优先级高于虚拟接口自动获取的DNS，会直接绕过VPN隧道转发DNS请求。
最后打开DHCP服务器的高级设置界面，确认已经勾选“强制DHCP发布的DNS为上游DNS”选项，如果没有开启这个选项，内网下接的手机、电脑等客户端，可能会复用之前网络场景下缓存的运营商DNS配置，哪怕路由器侧的DNS规则全部配置正确，也会出现客户端层面的DNS泄漏问题。
端到端DNS有效性验证步骤
不要直接用客户端浏览器的网页检测工具直接下结论，先在OpenWrt后台的系统-软件包界面安装tcpdump抓包工具，指定抓取VPN虚拟接口的53端口DNS请求，观察所有发出去的DNS请求的目标IP，protonvpn是不是你之前配置的VPN侧DNS地址，如果抓包结果里看到有DNS请求发往运营商的公网DNS地址，就说明路由器侧的转发规则存在异常。
再找一台通过有线方式接入OpenWrt LAN口的测试设备，断开所有其他WiFi连接，先清空设备本地的DNS缓存，再打开专业的DNS泄漏检测网页，注意勾选IPv4和IPv6的双栈检测选项，免费vpn不要用普通测速网站附带的简化版DNS检测功能，这类检测的请求样本数量不足，很容易漏过部分隐蔽的泄漏点。
如果检测结果里出现了不属于VPN服务商分配的DNS归属信息，先不要直接判定VPN配置出错，先临时断开VPN连接，单独测试本地直连网络的DNS结果，对比两次检测的DNS服务器IP有没有重合，如果IP完全重合，就说明确实有DNS请求漏出了加密隧道。单次测试的结果只能提示可能存在泄漏，不能直接排除所有其他偶发因素的影响。
常见泄漏问题的定位修复思路
最常见的配置误区是很多用户开启VPN之后，还同时运行了OpenWrt自带的广告过滤插件，这类插件默认会劫持所有内网DNS请求到本地缓存，部分旧版本的插件没有适配VPN转发规则，免费vpn不会把DNS请求走VPN隧道，需要单独在插件的出口规则里指定所有DNS请求走VPN虚拟接口。
还有部分启用IPv6的用户，只配置了IPv4维度的VPN流量转发规则，忘记给IPv6的DNS请求添加隧道转发规则，会出现IPv6的DNS请求直接走本地运营商链路的问题，这类泄漏普通的IPv4检测工具完全无法识别，必须开启双栈检测才能发现。
最后要注意，就算OpenWrt侧的所有配置都完全正确，也不能覆盖所有场景下的DNS请求，比如部分客户端自带的安全DNS功能，会绕过路由器DHCP分配的DNS地址，直接向硬编码的公共DNS服务器发送请求，这类情况不属于OpenWrt VPN层面的配置问题，需要单独在客户端侧关闭对应的安全DNS选项。
