DNS 与分流排查：从域名到出站逐层验证
不要先更换一串 DNS。通过解析、规则、连接三份证据，找出域名请求在哪一层偏离预期。
域名请求包含不止一次选择
输入网站域名后，设备需要得到地址，还要决定请求走直连还是代理，最后连接目标服务。这些阶段互相关联，却不应当混为一谈。比如名称解析失败和规则把请求发到错误出站，最后都可能表现为网页超时。
先固定设备、网络、客户端版本和一个样本域名。保存当前 DNS 与路由配置副本，不修改全局设置。用“名称是否得到结果—规则匹配什么—连接是否成功”三个问题组织记录。不要直接把别人配置里的 DNS 段覆盖进自己的配置。
- 记录样本域名、错误提示和当前模式。
- 备份配置，保留原有 DNS 和分流设置。
- 只使用一个代理客户端，对新请求观察日志。
先分清谁负责解析
系统、浏览器和代理客户端都可能处理 DNS。浏览器的安全 DNS 可能改变解析路径；TUN 与系统代理也可能让同一域名经过不同组件。因此，在系统工具里查到一个地址，并不自动证明浏览器请求使用了这个结果。
在客户端日志中寻找解析请求及错误。若系统解析正常、应用失败，检查应用自己的 DNS 或代理设置。若只在 TUN 下出错，核对该版本对 DNS 接管的要求。临时更改浏览器安全 DNS 前，记下原设置；测试结束后恢复。
- 在客户端日志中搜索样本域名，记录实际解析服务器与结果。
- 分别测试浏览器和另一个遵循相同代理设置的应用。
- 做一次单一设置对照，记录变化并恢复，避免同时改系统与客户端 DNS。
解析正常，再看规则命中
某个域名获得地址后，仍可能匹配直连、拒绝或未预期的代理组。域名规则、地址规则和最终规则的关系要按内核实际行为理解。记录命中的规则名称和出站，不能用“我选了代理节点”代替证据。
若更改规则，用测试副本添加范围最小的规则并验证优先级。不需要把整个地区都强制代理。对局域网、公司内部域名和私有地址，先理解本地网络条件，避免让内部请求绕到公网出站。
- 观察新请求的匹配规则、代理组和最终节点。
- 在副本中做最小规则调整，测试目标域名是否改变路径。
- 同时验证一个正常直连目标，确认修改没有扩大故障范围。
虚拟地址不等于解析失败
某些配置使用 fake-IP：客户端返回一个用于映射的地址，再在连接阶段找回对应域名。看到看似特殊的地址不能直接判定 DNS 被污染，也不应把它当作目标服务器的真实公网地址。判断仍要回到客户端是否正确完成映射与出站。
若某个应用与当前解析方式不兼容，查看日志和官方设置说明，用具体域名的兼容处理做对照。不要为了一个应用一次性禁用所有规则和全部 DNS 功能。sing-box 不同版本的配置字段会迁移；内核升级前先核对旧配置是否仍可使用。
- 确认当前解析模式，辨别真实解析结果与内部映射地址。
- 查找映射失败、解析超时或连接错误日志。
- 按对应版本文档处理具体域名，恢复其他已工作的设置。
IPv6、缓存与目标响应分别测试
IPv4 与 IPv6 路径可能不同，但“网页失败”并不足以证明 IPv6 是原因。缓存也可能让你反复观察旧结果。保持配置稳定，用新请求观察两类地址的尝试和错误；必要时做一次临时对照，结束后恢复。
清缓存是为了让下一次实验观察新结果，不是修复所有问题的万能按钮。目标网站即使解析成功，也可能因连接、证书、地区限制或维护返回错误。日志中如果已经建立连接并收到服务端响应，应把调查推进到目标服务。
- 观察样本请求是否尝试 IPv4、IPv6，以及失败在哪一种路径。
- 在保存设置后做一次有限对照，重复同一请求。
- 结束后恢复原设置，记录可重复的差异，不把偶然改善当作结论。
把结论写成一条完整链路
合格的排查记录可以这样组织：“域名已由客户端解析；规则命中代理组；该组节点连接超时；更换节点后正常，DNS 设置未改。”这说明问题更接近出站连接。另一种记录是“请求根本未进入客户端”，此时不应继续修改内核 DNS。
当记录无法判断某一层，明确写“未观察到”，不要补猜测。最终保留配置副本、版本与回退方法。未来升级内核或换网络时，用同一测试样本再次验证，比保存一堆无上下文的 DNS 地址更可靠。
- 汇总解析、规则与连接三项证据。
- 还原所有临时改动，再验证目标和正常直连资源。
- 保存已知可用配置，升级前重新核对官方迁移文档。
官方资料
功能与配置说明以官方资料为准。