DNS 覆写与网络设置
DNS 先保留默认
从「工具 → 进阶配置 → DNS」查看设置。「覆写 DNS」开启后，客户端设置会覆盖配置文件中的 DNS 选项；只修改字段但未启用覆写时，实际仍可能跟随原配置
- 先记录当前配置和覆写状态
- 只调整需要验证的一项，使用可从当前网络访问的解析器
- 重新应用配置，再对同一域名测试
- 没有改善时恢复原设置，再检查节点或规则
Fake-IP 与真实地址
DNS 模式会影响内核如何识别和路由域名。某些局域网或特定应用可能需要兼容设置；不要把所有域名加入例外，只调整已确认有问题的范围
本地端口与 DNS 劫持
混合端口在「工具 → 常规 → 端口」中查看；TUN 相关选项位于「工具 → 进阶配置 → 网络」。端口被其他程序占用时更换为未使用的端口，并同步更新手动配置代理的应用
DNS 劫持、追加系统 DNS、自动设置系统 DNS 分属不同环节。公司内网解析失败时，确认公司 DNS 的可达性及域名路由，不能只换一个公共 DNS 服务器
节点域名解析失败
核对系统时间、客户端版本、当前配置与网络状态。Windows / macOS 的网络自检会区分系统 DNS、内核 DNS 与托管节点 DNS；单个解析失败不能直接认定令牌失效
先区分需要修改的字段
| 字段或开关 | 处理的环节 |
|---|---|
| 域名服务器 | 普通目标域名的解析 |
| 代理域名服务器 | 代理节点自身地址的域名解析 |
| 遵守规则 | DNS 连接按规则选择出站，需要避免解析与代理互相依赖 |
| 覆写 DNS | 决定客户端这组 DNS 选项是否覆盖原配置 |
节点域名都解析失败时，先检查代理域名服务器；公司内网域名失败时，先检查内网 DNS 与网络可达性。不要通过反复切换 fake-ip 和真实地址模式代替判断问题所在
更改前记录原值，用同一个域名和同一节点测试。开启 TUN 时，所谓「系统路径」也可能经过 TUN，自检对照结果需要结合当前接管状态阅读
DNS 泄漏：先检查托管配置和接管方式
当前维护版本的服务端为 FlClash for oixCloud 生成的托管配置，将普通目标域名的默认 DNS 设为经 Proxy 组发送的 DoH，并为节点启动解析、直连目标保留独立解析器。特定域名策略仍可能优先于默认 DNS；本地旧配置、自定义订阅、脚本和 DNS 覆写也可能改变行为，不能只凭“已连接”认定生效
- 在账户页执行「同步」，确认托管配置更新成功，并选中这份配置
- 在「工具 → 进阶配置 → DNS」保持「覆写 DNS」关闭，先验证托管设置；在「工具 → 常规」关闭「追加系统DNS」，避免给普通 DNS 上游额外加入系统解析器
- 在代理页确认
Proxy组最终选中可用代理节点，没有落到DIRECT。组名区分大小写，其他订阅未必有这个组 - 桌面端开启「虚拟网卡」，确认授权与路由生效；Android 同意 VPN 授权，并确认测试应用未被访问控制排除。仅开启系统 HTTP / HTTPS 代理不能保证接管系统 DNS 或所有应用
- 重新打开目标应用，用新的测试域名验证解析器和实际出口；更新配置后仍异常时检查个人覆写与脚本
按平台补充检查
| 平台 | 操作与限制 |
|---|---|
| macOS | 「工具 → 进阶配置 → 网络」中保留「自动设置系统 DNS」开启，并启用 TUN；检查系统 DNS 修改是否成功。发往局域网路由器的 DNS 可能绕过 TUN，不要只检查公共 DNS |
| Windows | 启用 TUN，并检查多网卡、其他 VPN 和系统 DNS；需要严格路由时可通过可信覆写脚本设置 tun.strict-route: true，见下方说明 |
| Android | 在「工具 → 进阶配置 → 网络」开启「DNS 劫持」，关闭「允许绕过」，确认应用未被排除；排查时将系统「私人 DNS」设为关闭。常驻 VPN 与断线阻止连接由 Android 系统另行配置，并受系统版本支持情况限制 |
| Linux | 检查 TUN 自动路由、系统解析器与其他网络管理服务是否冲突；确认查询真正进入内核，而不只是本地代理端口可用 |
浏览器安全 DNS、应用内置 DoH / DoT 不会被普通端口 53 接管。排查时先记录并停用这些独立设置；如需保留，应让其连接通过预期代理，并单独验证 IPv4 / IPv6。关闭 DNS 的 IPv6 解析只影响 AAAA 回答，不等于关闭系统 IPv6
Windows 严格路由
当前界面没有独立的「严格路由」开关。熟悉配置的用户可在「工具 → 进阶配置 → 脚本」的现有 main(config) 中加入以下设置，保留原脚本逻辑，并返回 config：
config.tun = config.tun || {};
config.tun['strict-route'] = true;这段代码不是完整脚本，也不会替你开启 TUN。保存并应用后，用「虚拟网卡」建立连接，再检查生效配置与 DNS 路径。Windows 下该选项用于抑制多网卡 DNS 泄漏，可能影响 VirtualBox 等网络；出现兼容问题时撤回新增设置并重新应用。它不改变 DNS 上游的代理选择，也不等于客户端退出后的系统断网保护，详见 mihomo TUN 文档
自定义 DNS 时，必须同时确定出站
https:// 或 tls:// 只说明 DNS 传输加密。若要求普通域名解析经过代理，需要显式选择 DNS 连接的出口，例如当前托管配置使用的 https://1.1.1.1/dns-query#Proxy；这个后缀要求配置中确实存在 Proxy 组，且最终选择代理节点
respect-rules: true 表示 DNS 连接按路由规则选择出站，规则仍可能选中直连，并不是“防泄漏”开关。不要盲目开启，也不要把代理节点自身的解析指向一个必须先连接该节点才能访问的 DNS，否则会形成循环依赖
同时检查 nameserver-policy、fallback、direct-nameserver 和 proxy-server-nameserver：域名策略可以优先于默认解析器，后备查询也可能额外发出，直连和节点启动解析各有用途。只更换 nameserver 不能证明全部查询都经过代理；不要删除托管节点专用解析策略。字段含义见 mihomo DNS 文档
怎样判断是否仍有泄漏
DNS 测试显示的是解析器，解析器国家或 IP 与节点不同不一定是泄漏。应结合测试域名、规则和实际出站判断：直连目标使用本地 DNS 可能符合分流设置，但应代理的目标被交给本地运营商解析器就需要继续排查
使用生成随机新域名的测试避免缓存影响，依次对比 VPN / TUN 接管、DNS 覆写、应用自带 DNS 和 IPv6；通过 连接记录与网络自检 核对出站。有条件时在自己的物理网卡或路由器抓包，分别检查 UDP / TCP 53、加密 DNS 的直接连接，并在切换网络、重连后复测。一次网页测试通过不能证明所有应用和断线期间都受保护