很多用户在启用VPN分流模式时，经常遇到DNS解析异常问题，FAN加速器比如分流指定走直连的域名出现DNS泄露、走隧道的域名解析失败跳转到错误页面，不少人提交故障报告时只笼统描述“DNS用不了”，导致技术支持反复核对信息拉长排查周期。这份清单整理了VPN分流DNS故障提交报告需要的全部有效信息，覆盖从现象记录到配置验证的全维度内容，帮用户快速定位根因，减少无效沟通成本。
故障发生的基础场景与现象记录
首先需要明确故障触发的具体操作路径，不要模糊描述故障状态，要说明是开启VPN分流模式之后立刻出现异常，还是VPN运行了特定时长之后才复现问题，故障影响的是分流规则指定走VPN隧道的域名，还是走本地直连的域名，故障发生时有没有同时运行其他代理类工具，比如浏览器代理插件、系统级全局代理软件。
其次要记录故障的可复现性特征，说明问题是每次开启分流都100%触发，还是随机偶发没有固定规律，有没有特定的前置条件才会触发异常，比如切换不同的分流规则组、FAN切换不同的VPN节点时才会出现解析错误，同时要记录故障出现时的具体解析表现，是返回域名不存在的NXDOMAIN提示，还是跳转到完全无关的错误IP地址，还是解析请求直接超时无响应。
本地网络与设备配置相关信息
提交报告时需要同步当前设备的基础网络状态，包括设备本身的操作系统及具体版本号，当前接入的网络类型是家用宽带WiFi、企业办公内网还是移动运营商数据网络，当前局域网内有没有部署额外的DNS过滤设备，比如带广告拦截功能的定制路由器、FAN加速器企业内部的统一DNS网关。
用户逐项记录VPN分流DNS故障相关特征，准备提交完整的故障排查报告
需要明确标注当前VPN分流功能的具体配置参数，对应VPN分流DNS的核心配置逻辑，比如当前启用的分流模式是“全局走VPN仅指定域名直连”还是“仅指定域名走VPN其余全部直连”，使用的分流规则是手动编写导入的自定义规则，还是VPN软件默认自带的公共规则集，分流配置里有没有针对DNS请求的单独定向转发规则，VPN设置里指定的隧道内DNS地址、直连侧使用的DNS地址分别是什么。
故障复现阶段可以在本地执行命令获取系统DNS状态，Windows设备运行ipconfig /all、macOS设备运行scutil --dns、Linux设备运行cat /etc/resolv.conf，把输出的当前系统活跃DNS服务器列表截图附在报告里，确认分流模式运行时，走直连的请求有没有被错误替换成VPN隧道的DNS地址，走隧道的请求有没有仍然调用本地运营商的DNS地址。
前置对比排查的验证结果
提交报告前可以自行完成几个简单的对比测试，把测试结果同步给技术支持，首先测试关闭VPN分流功能切换成全局VPN模式时，当前的DNS故障是否还存在，再测试完全退出VPN软件回到普通直连网络时，之前出问题的相同域名解析是否恢复正常，这些对比结果可以直接帮技术人员排除是分流模块专属的问题，还是整体VPN连接的底层问题。
其次可以使用系统自带的nslookup或者dig工具做定向解析测试，分别测试分流规则里标记走VPN隧道的域名、标记走本地直连的域名，分别记录两个域名返回的解析IP地址，和正常状态下的预期解析结果做对比，确认是哪一侧的分流DNS规则没有生效，有没有出现分流规则本该放行直连的域名，却被隧道侧DNS解析出非预期地址的情况。
容易遗漏的关联环境信息
很多用户容易忽略系统级的其他DNS相关配置，需要同步说明当前设备有没有运行其他本地DNS服务，比如广告过滤工具、DNS加密代理类软件，这类工具的端口劫持逻辑很容易干扰VPN分流的DNS定向转发路径，导致预设的分流DNS路由规则被第三方工具覆盖，出现预期外的解析结果。
最后要补充故障发生前后的操作变更记录，比如故障出现前有没有升级过VPN客户端版本，有没有新增或者修改过分流规则的条目，有没有更换过当前连接的VPN节点，有没有手动调整过本地网络的默认DNS设置，这些变更点往往是故障的直接诱因，比零散的故障现象更能大幅缩短故障定位的周期。
完整提交所有相关的VPN分流DNS故障信息，不需要用户提前完成复杂的深度技术排查，只需要如实记录对应状态即可，既可以避免技术支持反复索要信息拉长故障处理时间，也能避免因为信息不全导致定位到错误的故障点，把简单的分流配置冲突问题当成底层网络连接问题处理，大幅提升故障处理的整体效率。
