Mihomo Party DNS设置教程：界面与YAML双路径排查解析失败
简答：先关闭TUN，用最小DNS配置确认域名能正常解析；再根据版本选择简易模式或Profile YAML，保存后重载核心。若仍怀疑DNS泄漏，需联合检查最终配置、客户端日志、系统DNS、浏览器安全DNS和TUN状态，不能只看一次nslookup结果。
定义：Mihomo Party的DNS设置，是对Mihomo内核的域名解析服务器、Fake-IP或redir-host模式、域名例外以及TUN接管方式进行配置。
三步速查：先判断入口，再验证是否生效
本文是第三方使用指南，不代表客户端官方。不同版本的界面名称可能不同；截至2026年10月27日，官方发布页列出的2.0.4版本新增了简易模式，可视化编辑DNS和域名嗅探配置，同时提供DNS覆写保护开关。查看2.0.4官方发布说明
| 你看到的界面 | 优先使用的路径 | 先做什么 |
|---|---|---|
| 能看到简易模式或DNS卡片 | 界面配置 | 先关闭TUN，设置redir-host和一个可达的DNS服务器 |
| 只有Profile编辑器 | YAML配置 | 备份当前Profile，只合并一个顶层dns区块 |
| 修改后重启又恢复 | 最终配置排查 | 检查DNS覆写、订阅更新和配置合并顺序 |
| 网页正常但怀疑DNS泄漏 | 联合验证 | 同时检查系统DNS、浏览器安全DNS、日志和TUN状态 |
- 先降低变量：关闭TUN、浏览器自定义安全DNS和系统级私人DNS，只保留客户端内置DNS进行基线测试。
- 再做最小配置：优先选择
redir-host，确认普通域名、局域网域名和原先失败的域名都能解析。 - 最后逐项恢复：先启用TUN，再测试Fake-IP，最后恢复浏览器安全DNS或Android私人DNS；每次只改一项。
Mihomo Party DNS、Fake-IP和redir-host怎么选
DNS负责把域名解析为地址；redir-host保留真实解析结果；Fake-IP则为域名分配虚拟地址，便于内核继续按域名和规则处理流量。Mihomo官方文档列出的增强模式是fake-ip和redir-host，默认增强模式为redir-host。查看Mihomo官方DNS字段说明
| 场景 | 建议起点 | 原因 |
|---|---|---|
| 正在排查解析失败 | redir-host | 变量较少，便于先判断基础DNS是否正常 |
| 普通网页和域名规则分流 | 确认基础解析后再试fake-ip | 可观察Fake-IP与规则处理之间的兼容性 |
| NAS、打印机、路由器管理页 | redir-host或Fake-IP加过滤 | 本地设备和局域网域名可能不适合虚拟地址 |
| 旧程序、游戏或硬编码地址应用 | 先用redir-host | 减少应用无法识别虚拟地址的变量 |
这不是固定的优劣排名，而是排查顺序：先用更简单的模式确认DNS，再按实际应用需要切换。DoH和DoT只是DNS传输方式，不等于Fake-IP模式；DoH通常使用https://地址，DoT通常使用tls://地址，是否可达仍取决于当前网络和服务器。
路径一：通过界面设置DNS
- 备份配置：导出当前Profile或复制原始YAML，记录原来的DNS、TUN和覆写设置。
- 判断版本入口：如果能看到简易模式、DNS卡片或DNS覆写保护，优先使用界面；如果只有配置编辑器，转到下一节的YAML路径。
- 设置最小变量：开启内置DNS，增强模式选择
redir-host，填写一个当前网络可达的DNS服务器，暂时不启用复杂的Fallback、DoH、域名策略和Fake-IP规则。 - 保存并重载：执行重新载入配置或重启核心。只关闭设置窗口，不代表内核已经使用新配置。
- 查看最终配置：确认当前激活Profile中存在一个有效的
dns:区块，并检查核心日志是否出现配置校验失败、DNS启动失败或请求解析失败。
如果找不到DNS卡片，不要直接断定客户端不支持DNS设置。版本、简易模式开关、当前内核和配置管理方式都会影响入口；先查看当前版本，再决定是否编辑Profile YAML。
路径二：用Profile YAML写入最小可用配置
下面是用于排查的最小片段，不是完整生产配置。请放入当前Profile的顶层dns:区块；如果原文件已经有dns:，应合并字段，不能重复创建两个顶层区块。
dns:
enable: true
ipv6: false
enhanced-mode: redir-host
default-nameserver:
- 223.5.5.5
nameserver:
- 223.5.5.5
direct-nameserver:
- system
fake-ip-filter:
- '*.lan'
- '*.local'
- 'localhost'
缩进必须保留：dns:下的字段缩进两个空格，列表项继续缩进。粘贴后先执行客户端的配置校验，再保存和重载。Mihomo官方示例中，default-nameserver用于解析DNS服务器地址，nameserver是默认域名解析服务器，proxy-server-nameserver只用于解析代理节点域名，direct-nameserver用于直连出口解析。对照官方字段定义
这里使用IP形式的DNS服务器，是为了减少DoH或DoT自身需要先解析域名而产生的自举问题。223.5.5.5并不保证在所有地区、网络或企业环境中都可达；如果日志显示连接不到该服务器，应替换为当前网络实际可访问的解析器，不要同时更换多个字段。
default-nameserver、nameserver和节点解析怎么区分
| 字段 | 作用 | 排查建议 |
|---|---|---|
default-nameserver | 解析DNS服务器地址本身 | 优先填写IP，避免加密DNS地址无法自举 |
nameserver | 普通域名的默认解析服务器 | 先配置一个可达地址，不要一开始堆很多服务器 |
proxy-server-nameserver | 只解析代理节点域名 | 节点域名解析失败时再单独配置 |
direct-nameserver | 直连出口使用的解析服务器 | 需要区分直连解析路径时再加入 |
nameserver-policy | 按域名或规则指定解析服务器 | 基础DNS未验证前暂时不要加入复杂策略 |
DoH和DoT不是必须项。若使用DoH，地址的主机名仍需要先被解析；若使用DoT，还涉及TLS连接和证书校验。遇到“改成加密DNS后反而无法解析”，先回退到一个可达的IP型nameserver，确认基础链路，再逐项启用加密解析。
Fake-IP过滤列表：局域网、NAS和本地发现怎么排查
fake-ip-filter用于指定不返回Fake-IP映射的域名，官方文档支持域名通配符。查看fake-ip-filter官方说明
*.lan：适合常见的局域网域名后缀。*.local：可能涉及本地发现、mDNS或Bonjour，但加入该项并不能保证所有局域网发现功能恢复。localhost：用于本机回环名称。
如果NAS或打印机仍找不到，按以下顺序处理：先切回redir-host；再确认设备使用的是IP地址、局域网域名还是mDNS名称；最后只为实际出现问题的域名增加例外。不要一开始把大量公共域名加入过滤列表，否则会改变原有解析路径，增加判断难度。
TUN模式下DNS不生效：Windows、macOS和Android分别检查什么
Mihomo官方文档说明，TUN的dns-mode可为disabled、native或hijack；hijack会在系统DNS设置基础上拦截发往53端口的请求。Windows使用相关接管能力时需要留意strict-route，macOS和Windows无法自动劫持发往局域网的DNS请求，Android开启私人DNS时也无法自动劫持这类请求。查看Mihomo官方TUN文档
| 系统 | 入口或状态 | 复测动作 |
|---|---|---|
| Windows | 检查客户端管理员权限、TUN状态和严格路由相关设置 | 关闭TUN后测试，再开启TUN对比；必要时用管理员命令提示符执行ipconfig /flushdns |
| macOS | 检查客户端是否获准创建虚拟网络接口，并在系统设置的网络详情中查看DNS | 系统设置路径为“网络→当前网络→详情→DNS”；先记录原值，再重载客户端 |
| Android | 设置中的“网络和互联网→私人DNS” | 测试TUN接管时临时选择“关闭”或“自动”，保存后重新打开客户端测试；完成排查后按需要恢复原设置 |
Windows的系统DNS可在网络设置中查看；macOS可在“系统设置→网络→当前服务→详情→DNS”查看。Android的私人DNS只影响DNS问答，不会替代其他流量接管方式。查看Windows官方网络设置说明 查看macOS官方DNS设置说明 查看Android私人DNS说明
DNS泄漏怎么验证：不要只看一次nslookup
- 建立基线：关闭TUN，记录系统DNS；在命令行执行
nslookup example.com，只把它当作“当前查询能否返回结果”的检查。 - 检查客户端：重新开启内置DNS和TUN，确认当前Profile已激活，查看日志中是否出现DNS模块启动、查询失败或连接指定解析器失败等信息。日志用词会随版本变化，不要只按某个固定报错文本判断。
- 检查系统：Windows使用
ipconfig /all查看网卡列出的DNS服务器；macOS在网络详情的DNS页面查看；Android检查私人DNS状态。系统显示的DNS与客户端预期不一致时，先关闭TUN或私人DNS重新对比。 - 检查浏览器：Chrome路径为“设置→隐私和安全→安全→使用安全DNS”。如果浏览器启用了自定义安全DNS，浏览器可能单独发起加密DNS查询，不能仅凭系统DNS推断浏览器路径。查看Chrome官方安全DNS说明
- 辅助测试：在同一网络、同一浏览器、同一客户端状态下使用公开DNS泄漏测试页面，对比关闭TUN、开启TUN、关闭浏览器安全DNS三组结果。第三方测试站点只能作为辅助证据，不能替代最终配置和客户端日志。
- 判读结果：如果网页可打开但测试仍显示系统或浏览器解析器，优先检查浏览器安全DNS、Android私人DNS、系统代理和TUN接管；如果所有域名都无法解析，先回滚到
redir-host和单一可达的nameserver。
“改了但不生效”：覆写、订阅更新和版本逻辑
官方发布说明显示，2.0.4加入了DNS覆写保护开关，并修复了已有DNS配置时dns-hijack未保留等问题。这些内容只代表对应版本的发布说明，不应泛化为所有历史版本的行为。查看对应版本变更
- 确认编辑的是当前正在使用的Profile，而不是旧订阅或未激活文件。
- 搜索配置中是否出现多个顶层
dns:区块。 - 检查简易模式、DNS覆写保护、应用控制配置和其他覆写项。
- 保存后重新载入核心，再查看最终激活配置，而不是只看编辑器源文件。
- 暂时关闭复杂覆写，只保留最小DNS字段进行验证。
- 手动更新订阅后重新检查，确认订阅生成内容没有覆盖本地修改。
回滚时恢复备份Profile，关闭TUN，删除最后加入的DNS策略，再重新载入核心。不要同时修改DNS、MTU、规则、路由和代理组，否则无法判断故障来自哪一项。
常见问题
Mihomo Party找不到DNS设置入口怎么办？
先查看当前版本是否有简易模式或DNS卡片；没有时编辑当前Profile YAML，并确认配置校验通过、核心已重载。不要把“没有侧边栏”直接等同于“不支持DNS”。
Fake-IP和redir-host应该选哪个？
排查解析失败时先用redir-host；普通网页和规则分流确认正常后，再尝试Fake-IP。局域网设备异常时，先检查过滤列表或切回redir-host。
为什么开启TUN后DNS仍然走系统？
检查dns-mode、dns-hijack、系统权限和平台限制。Windows、macOS的局域网DNS请求，以及Android开启私人DNS时的请求，不能假设都会被自动接管。
为什么nslookup显示正常，浏览器仍然解析失败？
浏览器可能启用了独立的安全DNS，也可能使用了缓存。先关闭浏览器自定义安全DNS，清理浏览器缓存或重启浏览器，再与客户端日志和TUN状态对照。
加入*.local后，局域网发现还是不正常怎么办？
*.local只处理匹配到的DNS名称，不能替代所有mDNS或Bonjour发现机制。请改用设备IP或实际局域网域名测试，并在确认具体域名后增加例外。
DNS配置保存后订阅更新又恢复怎么办？
查看最终激活配置，检查覆写保护、合并顺序和订阅更新内容。把测试字段放到真正生效的配置层，或暂时关闭覆写后重新验证。
可以直接复制网上的完整DNS YAML吗？
不建议。完整配置可能覆盖原有DNS、规则或TUN设置。先备份，再只合并必要字段，并在重载后检查最终配置。
常见问题
Mihomo Party找不到DNS设置入口怎么办？
先检查版本和简易模式；没有可视化入口时编辑当前Profile YAML，校验通过后重新载入核心。
Fake-IP和redir-host选哪个？
排查时先用redir-host，确认基础解析后再尝试Fake-IP；局域网异常时优先检查过滤列表。
开启TUN后DNS仍走系统怎么办？
检查dns-mode、dns-hijack、系统权限及浏览器或Android私人DNS，先关闭TUN建立基线再逐项恢复。
nslookup正常但浏览器仍打不开怎么办？
检查Chrome安全DNS、浏览器缓存和客户端日志；nslookup只证明一次查询返回结果，不能证明浏览器使用同一路径。
DNS配置为什么会被订阅覆盖？
检查最终激活配置、DNS覆写保护、合并顺序和订阅更新内容，不要只查看源文件。