先确认现象与测试方法
在编写故障报告前，需明确“异常”的具体表现。请分别测试全限定域名（如 example.com）与依赖搜索后缀的短域名（如 intranet）的解析结果。使用 nslookup 或 dig 工具时，注意观察返回的 IP 地址是否指向预期网络。若短域名解析失败或指向公网错误地址，而全限定域名正常，则问题集中在 DNS 搜索域（Search Domain）的拼接逻辑或客户端对后缀的继承上，而非基础 DNS 服务中断。
在网络诊断中，使用命令行工具测试全限定域名与短域名的解析差异，是定位 DNS 搜索后缀异常的第一步。
检查操作系统 DNS 配置
在 Windows 系统中，通过 ipconfig /all 查看 “DNS Suffix for this connection” 和 “Primary DNS Suffix” 字段；在 macOS 或 Linux 中，检查 /etc/resolv.conf 文件中的 search 或 domain 行，以及 NetworkManager 或 systemd-resolved 的相关配置。这些只读检查能确认当前客户端试图追加哪些后缀。若此处缺失或未包含所需的企业内网域，则客户端无法生成正确的完整域名，这属于配置缺失而非 VPN 协议故障。
验证 VPN 隧道内的 DNS 路由
确认 VPN 协议是否支持 DNS 重定向。不同协议机制不同：WireGuard 通常依赖用户空间工具或网络命名空间隔离，OpenVPN 常通过推送 dhcp-option DNS 指令，IPsec 可能依赖 IKEv2 的 DNS 属性。检查 VPN 客户端日志，确认是否成功接收并应用了指定的 DNS 服务器 IP。若日志显示 DNS 服务器已更新，但系统仍使用公共 DNS，说明存在策略冲突或客户端驱动未正确劫持解析请求，火烧云需向供应商反馈具体的日志片段而非猜测。
区分解析失败与路由丢失
如果解析成功但连接超时，问题可能在于路由策略而非 DNS。执行 tracert 或 mtr 测试解析后的 IP，观察数据流量是否真正通过 VPN 隧道。若流量仍从物理网卡发出，说明 VPN 路由表未覆盖该目标 IP，或客户端路由优先级低于默认网关。在报告中应附带路由表截图（Windows 的 route print 或 Linux 的 ip route），网络加速器明确哪些网段被绑定到 VPN 接口，哪些被丢弃。这有助于区分是 DNS 返回了错误的内网 IP，还是内网 IP 在物理网络中不可达。
报告应包含的核心信息
提交报告时，请附上操作系统版本、VPN 客户端及协议版本、完整的 DNS 解析命令及输出结果（包括查询时间戳和服务器响应 IP）、以及关键的 OS 级 DNS 配置截图。不要仅描述“无法访问”，而应提供“查询 intranet.corp 返回 NXDOMAIN 或解析至 1.2.3.4，但预期为 10.x.x.x”的具体对比。明确这些边界，能帮助支持人员快速排除公网 DNS 污染或本地缓存污染等非 VPN 因素，避免盲目重置网络栈或重装驱动。
