糖果云 Mihomo DNS 怎么设置？先不改订阅，按症状覆写

更新于 2026-10-27 · candytally.buzz

简答：如果糖果云订阅已经能更新、节点也能连接，先不要直接修改 DNS；只有出现节点域名解析失败、TUN 下应用打不开或局域网异常时，才通过覆写配置处理。最快的安全做法是：备份当前配置，只添加一个 dns 段，校验 YAML，重新载入核心，查看日志，再分别验证节点、普通域名和原本出问题的应用。本文是第三方使用指南，不代表糖果云官方；订阅入口、域名和客户端适配情况请以当前后台或官方公告为准。

定义：Mihomo DNS 是核心内置的域名解析模块，负责解析普通域名、代理节点域名以及 TUN 接管的 DNS 请求；Fake-IP 与 Redir-Host 是两种不同的解析处理模式。

先试这一步：不要直接改订阅文件

糖果云订阅导入 Mihomo 后，先测试现有配置是否已经满足需求。能更新订阅、能连接节点、浏览器和常用应用都正常时，没有必要为了“防泄漏”或“优化速度”一次性替换 DNS。自动更新的订阅文件也不适合直接编辑，建议使用客户端的配置覆写、Merge、Override 或本地配置功能，并先保存一份原配置。

不要把订阅地址、访问令牌、节点密码或 Cookie 写入公开文章、截图和共享配置。本文只提供 DNS 字段示例，不包含任何订阅地址或敏感信息。

Mihomo DNS 字段怎么选

Mihomo 官方文档提供了 DNS 字段、默认行为和示例配置。Mihomo 官方 DNS 配置文档中说明，enhanced-mode 可选 fake-ip 或 redir-host，而 default-nameserver 用于解析 DNS 服务器域名。

• enable：是否启用 Mihomo 内置 DNS；关闭后使用系统 DNS 解析。
• enhanced-mode：fake-ip 返回 Fake-IP 映射，redir-host 尽量保留真实解析结果。
• default-nameserver：解析 DoH、DoT 等 DNS 服务器域名的引导 DNS，通常应填写 IP 或符合文档要求的加密 DNS 地址。
• nameserver：普通域名的主要解析服务器。
• fallback：备用解析服务器，启用后会与 fallback-filter 一起影响结果选择。
• nameserver-policy：按域名或规则集合指定解析服务器，优先级高于普通 nameserver 和 fallback。
• proxy-server-nameserver：仅用于解析代理节点域名。节点名称显示但无法连接时，优先检查这个字段。
• fake-ip-filter：指定不返回 Fake-IP 的域名，例如已确认的局域网域名或设备发现域名。

要区分三种失败：订阅地址无法下载，通常是订阅地址、网络或 TLS 问题；节点域名无法解析，重点是节点域名解析路径；目标网站打不开，则还要检查规则、代理连接和应用自身 DNS。Mihomo 官方明确说明，proxy-server-nameserver只用于代理节点域名解析，不能把它当作所有 DNS 请求的代理通道。

最小可用 YAML：只覆写 DNS，不改节点和规则

下面模板适合“订阅已经导入，但需要明确指定 DNS”的场景。它只包含 dns: 段，不覆盖代理组、节点、规则和订阅地址。使用前确认当前客户端支持配置覆写，并确认最终配置中没有第二个同级 dns: 段。

带注释版：

无注释版：

模板中的 fake-ip、fake-ip-range、fake-ip-filter、nameserver 和 proxy-server-nameserver 均可在 Mihomo 官方 DNS 文档中核对。查看字段和示例

这份模板没有加入 fallback、nameserver-policy、respect-rules 和 direct-nameserver，因为这些字段会进一步改变解析路径。先让最小配置通过校验并完成业务验证，再根据日志一次增加一个字段，排错会更容易。

Fake-IP 和 Redir-Host 怎么选

Fake-IP 不是“速度更快”的通用开关，也不能单独证明 DNS 没有泄漏。Mihomo 官方文档将两者列为不同的 DNS 处理模式，默认模式为 Redir-Host；实际选择应结合客户端模式、TUN 状态、局域网需求和应用结果。参考 Mihomo 官方模式说明

如果切换到 Fake-IP 后局域网打印机、NAS、设备发现或系统检测异常，先把明确的内网域名加入 fake-ip-filter，并保留原配置作为回退。不要把大量未知域名加入过滤列表，否则可能让排查结果变得不清晰。

按客户端找到配置覆写入口

不同版本客户端的菜单名称可能变化，优先在应用内搜索这些关键词：配置覆写、Merge、Override、编辑配置、Profiles。无论使用哪一个兼容客户端，都按照“编辑配置—保存—校验—重新载入—查看日志—验证业务”的顺序执行。

1. Clash Verge Rev：导入订阅并确认原配置可用，在配置或 Profiles 页面寻找 Merge、Override 或编辑配置入口，添加 DNS 段，保存后重新载入当前配置。
2. Mihomo Party：进入配置管理或当前配置的编辑、覆写区域，添加同一份最小 DNS 段；先确认核心配置生效，再决定是否开启 TUN。
3. FlClash：进入当前配置的编辑或覆写功能，添加 DNS 段。如果当前版本没有独立覆写入口，先导出备份，确认客户端是否支持本地配置后再修改。

不要直接改自动更新的订阅缓存文件。找不到菜单时，使用客户端内搜索功能查找上述关键词，或查看对应版本的配置说明；不要凭猜测重复创建多个 dns: 段。

TUN 模式下 dns-hijack 该不该开启

TUN 会接管系统流量，但 DNS 行为还取决于 dns-mode、dns-hijack、路由和系统设置。Mihomo 官方文档说明，dns-mode包括 disabled、native 和 hijack；其中 hijack 还会拦截其他接口发往 53 端口的流量。Windows 使用该模式时还涉及 strict-route。Mihomo 官方 TUN 配置文档

• 只使用系统代理时，不要因为 DNS 问题自动开启 TUN，先确认浏览器代理是否正常。
• 只有当应用绕过系统代理、需要透明接管时，才检查 TUN 的 dns-mode 和 dns-hijack。
• Windows 出现局域网访问异常时，同时检查严格路由、局域网放行和 Fake-IP 过滤。
• Android 开启 Private DNS 时，DNS 请求可能无法被自动劫持，应先检查系统 Private DNS。
• 只解决节点域名解析失败时，先检查 proxy-server-nameserver，不要先改 TUN。

Mihomo 官方快速配置示例同时展示了 TUN、dns-hijack 和 Fake-IP，但示例不能直接视为所有设备的通用配置。查看官方快速配置示例

配置完成后的六步验证闭环

1. 备份：保存修改前的订阅配置或覆写内容。
2. 编辑：只添加一个同级 dns: 段，使用空格缩进，不要混用 Tab。
3. 校验：点击客户端的检查配置、测试配置或重新加载功能；重复字段、缩进和列表短横线是常见错误。
4. 重新载入核心：不要只刷新界面，确认运行中的 Mihomo 核心已经应用新配置。
5. 查看日志：搜索 dns、resolve、no such host、timeout 和 proxy-server-nameserver，判断失败对象是订阅域名、节点域名还是目标网站域名。
6. 验证业务：先打开普通网页，再测试节点连接和延迟，最后测试原本出问题的应用；Fake-IP 下出现 198.18.0.0/16 映射地址本身不等于节点故障。

如果怀疑 IPv6 影响连接，可暂时将 ipv6 设为 false 做单变量测试。官方文档说明，关闭该选项时，AAAA 查询会返回空解析；如果问题消失，再继续检查网络是否提供可用 IPv6，而不要直接把所有问题归因于 DNS。核对 IPv6 行为

按症状分层排查

如果启用 respect-rules，Mihomo 官方文档要求同时配置 proxy-server-nameserver，并不建议与 prefer-h3 一起使用。没有明确需求时，先不要开启这些附加选项，以免出现循环解析或难以定位的失败。

常见问题

糖果云 Mihomo 一定要改 DNS 吗？

不一定。判断标准不是“别人用了什么 DNS”，而是当前配置是否出现可复现的问题：订阅能否正常更新、节点能否连接、普通网页能否打开、原本异常的应用是否恢复。如果这些项目都正常，保留订阅原有 DNS 通常更容易维护。只有出现节点域名解析失败、TUN 接管异常、局域网域名异常或明确的 DNS 报错时，才建议使用覆写配置。

Fake-IP 和 Redir-Host 哪个更好？

没有适用于所有设备的唯一答案。Fake-IP 更适合需要统一接管解析、规则和 TUN 流量的场景，但可能要求为局域网或特殊应用增加过滤；Redir-Host 更接近真实解析结果，适合先观察真实地址和兼容性。切换前应备份配置，切换后至少验证普通网页、节点连接、局域网资源和原本出问题的应用。

为什么节点解析失败要先看 proxy-server-nameserver？

因为 Mihomo 官方将这个字段限定为代理节点域名解析用途。普通网站能打开但节点连不上时，问题可能发生在“节点域名解析”这一层，而不是普通网站的 nameserver。先在日志中确认失败对象，再单独检查该字段，可以避免改动过多配置。

配置后出现 YAML 错误怎么办？

先停用覆写并恢复备份，不要继续叠加字段。然后检查是否存在两个同级 dns:、Tab 缩进、列表短横线缺失、冒号后没有空格，或把带特殊字符的地址写成了错误格式。确认最小模板能够载入后，再每次只增加一个字段，并在每次修改后重新校验。

开启 TUN 后浏览器能用，但应用仍然打不开，怎么查？

先确认该应用是否绕过系统代理；如果是，检查 TUN 是否启用、系统是否授予权限、dns-mode 是否合适，以及 dns-hijack 是否实际生效。Windows 还要检查严格路由和防火墙，Android 则要检查 Private DNS。不要先反复切换 Fake-IP 和 Redir-Host，先通过日志确认请求是否进入 Mihomo。

198.18.0.0/16 出现在连接信息里，是不是 DNS 配错了？

不一定。Fake-IP 模式会使用配置中的 Fake-IP 地址范围建立域名到映射地址的关系，因此看到该范围可能是正常现象。真正需要确认的是规则是否命中、节点是否建立连接、目标应用是否返回正常结果。如果日志显示解析失败或应用无法访问，再检查过滤列表、DNS 上游和 TUN 接管状态。

DNS 泄漏测试通过，就能证明配置完全正确吗？

不能。DNS 泄漏测试只能观察某一时刻的解析出口，不能替代 Mihomo 日志、规则命中、节点连接、TUN 状态、IPv6 行为和应用结果检查。浏览器 Secure DNS、Android Private DNS 或应用内置 DNS 也可能形成独立的解析路径，因此应分别关闭、核对或测试这些设置。

配置失败后如何恢复？

先关闭配置覆写或删除新增的 dns: 段，重新载入原订阅配置，再确认核心日志恢复正常。如果仍然无法联网，退出客户端后恢复修改前的本地配置备份，并清理客户端保存的 Fake-IP 缓存；恢复后先验证原配置，再重新进行单变量修改。

常见问题

糖果云 Mihomo 一定要改 DNS 吗？

不一定。只要订阅能更新、节点能连接、普通网页和常用应用都正常，就可以保留原配置。只有出现节点域名解析失败、TUN 接管异常、局域网域名异常或明确 DNS 报错时，才建议通过覆写配置处理。

Fake-IP 和 Redir-Host 哪个更好？

没有适用于所有设备的唯一答案。Fake-IP 更适合统一接管解析和 TUN 流量，但可能需要为局域网或特殊应用增加过滤；Redir-Host 更接近真实解析结果，适合优先观察兼容性。切换前请备份配置，并验证网页、节点、局域网和异常应用。

为什么节点解析失败要先看 proxy-server-nameserver？

因为该字段专门用于代理节点域名解析。普通网站能打开但节点无法连接时，故障可能发生在节点域名解析层。先从日志确认失败对象，再检查该字段，比直接替换全部 nameserver 更容易定位问题。

TUN 开启后应用打不开怎么办？

先确认应用是否绕过系统代理，再检查 TUN 权限、dns-mode、dns-hijack 和系统 Private DNS。Windows 还要检查严格路由与防火墙，Android 要检查 Private DNS。确认请求是否进入 Mihomo 后，再决定是否切换 Fake-IP 或 Redir-Host。

198.18.0.0/16 出现是不是 DNS 配错？

不一定。Fake-IP 模式会使用配置的地址范围建立映射，看到该范围可能是正常现象。应结合规则命中、节点连接、日志和应用结果判断，不能只凭地址范围判定故障。

配置失败后怎样恢复？

关闭配置覆写或删除新增 DNS 段，重新载入原订阅配置；如果仍然异常，退出客户端并恢复修改前的备份。恢复后先验证原配置，再一次只修改一个字段。

相关阅读

• 继续看 Mihomo TUN 模式的权限、DNS 与断网排查
• 如果订阅还没导入成功，先看 Clash Verge Rev 导入排查
• 节点连接失败时，按超时、DNS 和客户端配置分层定位
• 遇到 timeout 或 DNS 报错，可对照节点报错快速定位

参考资料

1. Mihomo 官方文档：DNS configuration
2. Mihomo 官方文档：TUN 配置
3. Mihomo 官方文档：Quick configuration