很多用户部署完OpenVPN服务端配置了DNS推送规则之后，经常遇到明明配置了推送参数，客户端实际走的还是本地运营商DNS的情况，不仅容易出现域名解析泄露，还没法正常访问VPN内网的自定义域名资源，这篇全攻略就围绕OpenVPN DNS推送的日常检查方法，从配置前提、分系统验证、链路排查到误区规避一步步拆解，帮普通运维和个人用户快速定位推送是否生效。
OpenVPN DNS推送生效的前置配置校验
很多人跳过服务端配置检查直接去客户端测试，最后绕了大弯，首先要先确认OpenVPN服务端的配置文件里确实写对了推送DNS的指令，不是写错了参数名，比如很多新手会把push "dhcp-option DNS 10.8.0.1"写成push "dhcp-option DNS 10.8.0"少了一位，或者漏了push前缀，相当于根本没把DNS规则放进推送队列里。
还要确认服务端没有开其他覆盖DNS配置的参数，比如部分自定义的up脚本会在连接建立后强制覆盖客户端DNS，这类脚本如果和推送规则冲突，就算配置了正确的推送指令也不会生效，这一步是所有后续检查的基础，不要等客户端折腾半天再回头改服务端配置。
不同客户端系统的直接验证操作方法
Windows系统下的检查非常直观，连接上OpenVPN之后，不要直接用浏览器查IP就以为完事，先打开命令提示符输入ipconfig /all，找到对应OpenVPN生成的虚拟网卡条目，看DNS服务器那一行的列表，是不是优先显示你推送的DNS地址，而不是本地网卡的运营商DNS排在最前面。
macOS和Linux系统下可以用scutil --dns（macOS）或者resolvectl status（主流Systemd发行版）查看当前DNS解析器的优先级，很多用户会遇到推送的DNS排在本地公共DNS后面的情况，这时候系统默认还是用靠前的DNS做解析，相当于推送没有达到预期效果，这时候要检查OpenVPN客户端的权限配置，是不是没有获得修改系统DNS的足够权限。
移动端的OpenVPN Connect客户端检查要注意，部分安卓系统的省电模式会限制VPN应用修改系统DNS的权限，连上VPN之后可以直接在客户端的详情页查看分配的DNS字段，确认显示的地址和你服务端推送的地址一致，不要直接用第三方测速工具的DNS检测页就下结论，很多这类工具的检测逻辑会绕过系统默认解析器。
端到端解析链路的生效验证方式
基础验证可以直接用nslookup或者dig命令，指定一个只有推送的DNS才能解析的内网域名，比如你在VPN侧的DNS里配置了把内部服务名vpn.internal指向内网网关，直接解析这个域名，如果返回的是正确的内网IP，就说明推送的DNS确实在工作。
进阶的防泄露验证可以连续解析几个不同顶级域的公网域名，然后查看解析请求的来源IP，确认所有解析请求的发起方都是你推送的DNS地址，没有出现本地运营商DNS的请求记录，这一步可以排除部分浏览器自带的DNS over HTTPS功能绕过系统DNS的问题，很多用户以为是OpenVPN推送失效，实际是浏览器自己的安全设置跳过了系统配置的DNS。
日常检查的常见误区规避
很多新手遇到推送不生效就直接改服务端配置重启，忽略了客户端的配置文件里有pull-filter ignore "dhcp-option DNS"这类参数，这类参数会直接让客户端主动丢弃服务端发来的DNS推送指令，相当于服务端发的包客户端直接拒收，怎么改服务端都不会有效果。
还有部分场景下用户同时开了多个VPN客户端，或者系统里装了代理工具，这类工具的DNS接管优先级比OpenVPN更高，就算OpenVPN的DNS推送完全生效，系统的解析请求也会被其他工具劫持，这时候要先关闭其他网络工具再单独测试OpenVPN连接的DNS状态，单次测试的结果只能说明当前环境下的状态，不能直接判定OpenVPN服务端配置有问题。
日常运维的时候可以把DNS推送检查加入OpenVPN连接后的自动校验脚本，每次客户端连接成功之后自动返回当前生效的DNS地址给用户提示，不用每次手动一步步排查，能大幅降低日常故障定位的时间成本。
