当VPN分流模式下部分网站无法访问或响应异常时，DNS解析往往是首要排查对象。分流策略通常意味着部分流量走本地出口，部分走隧道，若DNS查询未正确指向隧道内的解析器，或本地DNS缓存了旧IP，就会引发连接失败。诊断核心在于区分：是“名字没解析对”，还是“解析对了但连不上”，猎豹或是“解析和连接都走了错误的通道”。
确认当前DNS服务器指向
在Windows中，可在命令提示符执行 ipconfig /all 查看当前网络接口的DNS服务器地址；在macOS或Linux中，可分别使用 scutil --dns 或 resolvectl status 获取系统级DNS配置。注意，VPN客户端安装后可能会动态覆盖默认DNS。若你使用的是WireGuard或OpenVPN这类支持分流的协议，请检查配置文件中的 dns 选项或路由表，确认是否已将DNS流量（通常目标为53端口的UDP/TCP）强制通过隧道。若配置未指定，部分流量可能仍走本地ISP的DNS，导致解析结果不受控。
区分解析成功与否
使用 nslookup 或 dig 工具直接查询目标域名。例如 nslookup example.com。若返回“服务器查询失败”或超时，说明DNS查询本身受阻，可能因隧道未建立、DNS端口被防火墙阻断，或客户端未正确推送DNS服务器。若返回IP地址，但随后网页仍打不开，则问题不在DNS解析阶段，而在于后续的TCP连接或TLS握手环节。此时需结合下一步检查，避免误判为DNS故障。
当部分流量无法穿透隧道时，深入检查路由表与本地DNS缓存是定位解析偏差的关键。
验证IP可达性与路由选择
拿到解析出的IP后，使用 ping 或 tracert（Windows）/ traceroute（macOS/Linux）测试连通性。重点观察第一跳或后续跳点是否属于你的VPN子网或网关。若 tracert 显示流量直接走向公网网关而未进入隧道，说明路由策略未生效——该IP未被匹配到分流规则中。若流量确实进入隧道但最后无法到达目标，可能是隧道内的出站限制或目标站点拒绝了来自VPN出口的请求。注意，某些加速服务可能通过NAT或中继改变出口IP，不能仅凭IP归属断定连接必然成功。
检查本地DNS缓存与客户端行为
操作系统会缓存DNS结果。Windows中可运行 ipconfig /flushdns 清除缓存（此操作低影响，仅重启解析器）；macOS可尝试重启网络服务。更隐蔽的问题是：某些浏览器或应用自带DNS over HTTPS（DoH）或DoT，会绕过系统DNS设置，直接连接公共解析器。若你启用了此类功能，需检查浏览器设置或应用日志，确认其DNS请求是否也被分流至隧道。若DoH请求直连公网，即使系统DNS正常，应用层仍可能解析到不可达的IP。优先使用系统级DNS测试，排除应用层干扰。
