FlClash DNS 排查：从域名打不开到定位解析链路
先区分解析与连接故障，再检查系统设置、节点域名解析与配置覆写。
先描述故障发生在哪一步
网页打不开并不一定是 DNS 问题。先记录是所有域名异常、某个域名异常，还是应用只在一种网络下异常；再查看日志中有没有明确的解析失败或连接失败提示。
选择一个已知在当前网络可用的目标作为对照。不要仅用陌生目标判断整套配置失效，也不要因一次超时就立即更换所有解析设置。
同时观察系统和客户端
解析请求可能受到系统设置、应用自身设置与 FlClash 配置共同影响。检查当前接管方式和连接记录，再看系统是否启用了私人 DNS 或其他解析工具。
启用 TUN 后仍需要关注平台限制。mihomo 文档指出，Android 私人 DNS 会影响自动接管解析请求；若需验证这一因素，记录原设置后临时对照，完成后按需求恢复。
区分网站域名与节点域名
mihomo 配置区分普通域名解析与代理节点域名解析。即使网页使用某个解析服务，节点自身的地址仍需要先得到有效结果；这两个环节的故障表现可能不同。
如果所有节点都无法建立连接，查看错误是否首先指向节点域名。反之，节点连接正常而单个网页异常，则进一步检查该域名的解析结果与分流路径。
检查覆写是否改变了原配置
排查时保存当前配置，再查看有没有额外的 DNS 覆写或手动修改。某个曾为旧网络加入的设置，可能在换网络后产生不同效果。先临时回到清楚的原始配置做对照。
不要把网上整段解析示例直接覆盖到自己的配置。示例可能包含专用规则、代理组名称或不同前提，缺少对应内容时会引入新的依赖问题。
一次只调整一个环节
需要修改时，每次只调整一个明确环节，例如某项解析来源或某个域名策略，随后使用相同目标复测。保存修改前后结果，避免多次修改后无法判断有效的是哪一项。
假地址与真实地址解析方式各有配置前提。不能因为返回了一个不熟悉的地址就认定出错，应结合当前模式和连接结果理解其作用。
用证据决定下一步
复测后若错误仍在，记录时间、网络、域名、接管方式和相关日志。向他人提供信息时隐藏订阅地址、节点凭据与账户标识，只保留定位所需内容。
如果问题开始于升级或换网络，查阅官方变更说明并进行相同条件对照。解析问题需要沿链路定位，保持清晰记录通常比频繁替换服务器更有效。
参考资料与使用说明
本文按官方公开资料整理操作思路，界面名称与行为可能随版本变化。配置来自不同服务商时也可能存在差异，请结合当前客户端及对应发布说明确认。