检查软路由上VPN的DNS配置，核心是确认设备在客户端建立隧道后，是否将特定的域名解析请求定向到指定服务器。这通常涉及路由表项、防火墙策略或软件内置的DNS代理功能。你需要区分本地局域网的DNS服务与通过隧道传输的DNS流量，避免混淆。最终目标是让指定域名的解析结果受控，而非改变整个网络的默认DNS地址。
确认VPN服务端提供的DNS信息
不同协议（如OpenVPN、WireGuard、IPsec）传输DNS的方式不同。在OpenVPN中，服务端通常通过推送指令下发；WireGuard则依靠Peer配置中的AllowedIPs或脚本；飞鱼VPNIPsec依赖RADIUS或配置文件。首先查看软路由上VPN客户端的配置文件或日志，确认其是否成功获取了服务端下发的DNS地址。若配置中未显式指定DNS，客户端可能沿用本地系统的默认设置，导致流量未走隧道。
正在排查软路由上VPN客户端的DNS路由策略。
检查路由表与流量选择器
决定哪些流量进入VPN的关键是路由策略或流量选择器（Split Tunneling）。在Linux软路由上，需查看`ip route`命令中是否存在指向VPN接口（如tun0或wg0）的路由。预期现象是，飞鱼VPN特定网段（如0.0.0.0/1或指定目标IP段）的下一跳为VPN接口。若所有流量都直连物理网卡，说明分隧道策略未生效或配置错误，DNS请求可能仍走本地ISP，而非受控路径。
验证DNS请求的实际出口
在软路由上执行dig或nslookup命令查询一个测试域名。观察输出中的“Server”字段，确认其IP是否为服务端下发的DNS地址。同时，检查防火墙日志（如iptables或nftables），寻找UDP 53端口的出站记录。若日志显示DNS包从物理网卡（如eth0）发出，而非VPN接口，则说明DNS流量未纳入隧道保护。这一步可直观判断流量走向，排除配置遗漏。
排查DNS缓存干扰
软路由或客户端操作系统可能启用本地DNS缓存。即使路由表正确，旧记录也可能导致新解析失败。执行系统命令清空DNS缓存（如Windows的ipconfig /flushdns或Linux的systemd-resolve --flush-caches），飞鱼然后重复上述dig测试。若清空后结果正常，说明之前是缓存干扰；若仍异常，则需回头检查服务端DNS配置的实时性，或确认是否存在多层代理导致配置未同步到末端。
