很多自行部署OpenVPN的用户都会遇到一类典型问题：VPN连接状态完全正常，内网资源也能正常访问，但域名解析请求依然走本地运营商链路，甚至出现DNS泄漏的情况，绝大多数这类问题都不是推送指令写错了语法，而是配置前的各项必备前提没有全部满足，哪怕漏了一个环节，后续的配置指令都不会正常生效。下面就从服务端、路由逻辑、客户端权限、验证方式几个维度，逐一拆解OpenVPN DNS推送配置的所有必备前提，帮大家避开常见的配置误区。
运维人员正在OpenVPN服务端核查DNS推送相关的运行权限配置。
服务端运行环境的基础权限前提
很多新手部署OpenVPN时为了安全，会特意用nobody这类低权限用户启动服务，却忽略了这类默认权限的用户没有修改系统网络配置的权限，自然也没法正常向客户端下发DNS推送相关的网络指令。
你可以先在OpenVPN服务端的命令行界面执行进程查询指令，小火箭VPN查看当前OpenVPN进程的运行属主，如果既不是root用户，也没有为专属运行用户预先配置CAP_NET_ADMIN网络管理权限，后续写入的所有DNS推送相关配置都不会被系统内核识别。
除此之外还要确认服务端的tun/tap虚拟网卡模块已经正常加载，不少精简版的云服务器镜像默认会禁用虚拟网卡模块，没有虚拟网卡的封装转发支撑，DNS推送的控制指令根本没法被封装进VPN隧道传输到客户端。
推送指令与路由规则的匹配前提
不少用户直接从网上复制push "dhcp-option DNS 8.8.8.8"这类配置行粘贴到服务端配置文件里，却完全没注意这类指令的生效前提是服务端已经提前开启了系统IP转发功能，不然客户端发往推送DNS地址的请求就算进入VPN隧道，也没法从服务端的物理网卡正常转发出去。
你可以先在服务端执行sysctl参数查询指令，确认net.ipv4.ip_forward的返回值为1，这才代表系统级的IP转发功能已经正常开启，如果返回值为0，就算写入多条DNS推送规则，客户端的DNS请求也只会被服务端直接丢弃。
还有个很容易被忽略的细节是，你推送的DNS服务器地址必须能被VPN客户端通过隧道正常路由到达，如果你推送的是服务端内网环境下的私有DNS地址，却没有把这个DNS所属的网段路由也同步推送给客户端，shadowrocket客户端发起DNS查询请求时根本不知道要走VPN隧道，自然还是会通过本地网关发起解析请求。
客户端侧的权限与拦截规则排查前提
不少Windows平台的OpenVPN用户反馈所有服务端配置都完全正确，但DNS推送就是不生效，本质原因是OpenVPN客户端程序没有拿到修改系统网络配置的管理员权限，Windows系统下普通权限运行的程序没有改写本地物理网卡IPv4属性中DNS地址的权限，推送的指令自然没法落地。
在macOS和Linux平台下还要注意系统自带的本地DNS缓存服务的锁机制，systemd-resolved这类默认服务会优先绑定物理网卡的DNS配置，哪怕OpenVPN推送了新的DNS地址，也会被本地缓存服务的默认规则覆盖，shadowrocket你需要提前在客户端配置中添加对应的放行脚本参数，允许OpenVPN修改本地DNS缓存服务的绑定规则。
部分部署了终端安全管理软件的办公设备，会默认强制锁定系统DNS地址防止恶意篡改，shadowrocket这类场景下哪怕所有配置项都完全合规，OpenVPN的DNS推送指令也没法修改被安全规则锁定的DNS参数，需要提前在终端安全的白名单中加入OpenVPN程序的放行权限。
配置完成后的有效性验证逻辑
所有前提项都确认完成之后，不要只看到VPN连接成功就判定DNS推送生效，你可以在连接VPN之后打开系统命令行工具，执行nslookup或者dig命令查询任意公网域名，看返回的响应DNS服务器地址是不是你预先配置推送的目标地址。
如果查询结果中依然出现本地运营商的DNS地址，你可以按照从服务端权限、转发规则、客户端权限的顺序逐一回溯排查，不要上来就反复修改推送指令的语法内容，绝大多数这类故障都不是指令拼写错误导致的。
还要注意区分DNS推送生效和全流量走隧道的差异，部分场景下你只配置了DNS推送规则，没有配置重定向所有流量的相关参数，此时只有DNS查询请求会走VPN隧道，普通的网页访问流量依然走本地网络，这属于正常的运行状态，不属于配置故障。
