Mihomo v1.19.33 新功能怎么用：dns-mode 设置步骤与示例

更新于 2026-10-24 · efancloud.cyou

简答：开了 TUN 但 DNS 仍从物理网卡发出？Mihomo v1.19.33 新增的 tun.dns-mode 正是解决这个配置问题。先备份配置并确认实际核心版本，再按系统选择 native 或 hijack，用 API 和 nslookup、dig 做对照验证。

定义：tun.dns-mode 是 Mihomo v1.19.33 新增的 TUN DNS 配置模式，用于决定是否设置系统 DNS，以及是否拦截其他网卡发往 53 端口的请求。

30 秒速查卡：先选模式，再做一次对照测试

开了 TUN 但 DNS 仍从物理网卡发出、浏览器解析结果不符合预期？Mihomo v1.19.33 新增的 tun.dns-mode 就是针对这个场景提供的配置项。本文是第三方使用指南，不代表 Mihomo 或其他客户端官方页面；版本变化以 v1.19.33 Release和当前 TUN 文档为准。

对照标准：使用 enhanced-mode: fake-ip 时，Windows 或 Linux 的 hijack 测试若返回 198.18.x.x，说明发往指定 DNS 的 53 端口请求被导入 Mihomo DNS；若返回真实 IP，说明这次请求没有被拦截，需继续检查路由、权限和防火墙。macOS 和局域网 DNS 请求可能受系统限制，不能把同一结果直接套用到所有平台。

v1.19.33 到底新增了什么：dns-mode 不等于 fake-ip

截至 2026-10-24，v1.19.33 Release 页面明确列出的功能变更包括为 TUN 增加 dns-mode；同时还列出若干修复和维护项。修复项较多，具体内容应直接对照 Release 页面，不要把某一项修复推断成所有网络问题都会消失。

TUN 文档说明，disabled 不设置系统 DNS，native 将 TUN 地址设置为系统 DNS，hijack则在此基础上拦截其他接口发往 53 端口的流量。Windows 使用 hijack 时需要 strict-route，Linux 使用时需要 auto-redirect。DNS 文档则说明，fake-ip 与 redir-host属于另一层设置，不能用修改 enhanced-mode 代替 dns-mode。

升级前准备：确认实际核心、备份文件并保留回滚版本

1. 确认当前运行的核心。不要只看客户端名称或配置文件名。按实际文件名执行版本命令，例如 Linux 使用：

./mihomo-linux-amd64 -v

Windows 需要在管理员终端中按实际文件名执行，例如：

.\mihomo-windows-amd64.exe -v

预期结果应包含 v1.19.33。如果你使用 Clash Verge Rev、Clash Meta for Android 或其他图形客户端，客户端配置升级不等于内置 Mihomo 核心升级；应在客户端的内核管理、核心版本或运行日志入口确认实际版本，具体菜单以当前客户端界面为准。

1. 备份完整配置。Linux 或 macOS 可执行：

cp "config.yaml" "config.yaml.bak"

Windows 可在文件管理器中复制为 config.yaml.bak。配置中可能包含订阅地址、节点密码和 API 密钥，不要公开上传。

1. 保留旧核心文件。不要直接覆盖原二进制文件。将旧版本改名为类似 mihomo-old，新版本使用独立文件名；升级后若启动失败，先停止新核心，再恢复旧核心文件和备份配置。

1. 选择匹配平台和架构的 Release 文件。Windows、Linux、macOS 以及 amd64、arm64 文件不能混用。文件选择可参考 Mihomo FAQ；如果图形客户端内置旧核心，需要在客户端内核管理入口切换或替换核心，而不是只导入新配置。

可复制的完整测试配置：先用本地 DNS 和 DIRECT 验证 TUN

下面配置用于验证 TUN 与 DNS，不包含真实节点。它使用本地回环 DNS 监听、fake-ip、本地 API 和 DIRECT，便于先排除节点参数干扰。端口统一使用 7890 和 9090，实际使用时以客户端设置页为准。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

external-controller: 127.0.0.1:9090
secret: "replace-with-a-local-secret"

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-mode: native
  dns-hijack:
    - any:53
    - tcp://any:53
  strict-route: false

proxies: []

proxy-groups:
  - name: DIRECT-GROUP
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,DIRECT

dns.listen 使用 127.0.0.1:1053，是为了避免在 allow-lan: false 时把 DNS 服务暴露给局域网。default-nameserver 使用 IP 地址，避免解析 DoH 域名时再次依赖尚未稳定的域名解析。真正接入订阅后，再把节点和规则替换回原配置，不要同时修改 DNS、TUN、代理组和规则。

Windows

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-mode: native
  dns-hijack:
    - any:53
    - tcp://any:53
  strict-route: false

先用 native确认 TUN 能启动，再只把两处改为 dns-mode: hijack 和 strict-route: true。如果 VirtualBox、局域网软件或多网卡应用异常，回退到 native；文档说明 Windows 的严格路由会增加防止多网卡 DNS 泄漏的防火墙规则，也可能影响部分应用。

Linux

tun:
  enable: true
  stack: system
  auto-route: true
  auto-redirect: true
  auto-detect-interface: true
  dns-mode: hijack
  dns-hijack:
    - any:53
    - tcp://any:53
  strict-route: false

Linux 的 auto-redirect 用于配置 iptables 或 nftables 的 TCP 重定向，并要求 auto-route 已启用。若 TUN 出现但连接失败，先检查运行权限、防火墙规则和路由表，不要先修改 MTU。

macOS

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-mode: native
  strict-route: false

macOS 的 TUN 设备名需要以 utun 开头。建议省略 device 让核心自动分配；不要把 device: utun0 写死，因为该编号可能已被 VPN 或系统网络服务占用。若系统 DNS 或局域网访问异常，可将 dns-mode 改为 disabled 做对照。

校验、启动、API 重载：不要用启动动作代替配置检查

1. 只校验配置，不启动实例。按实际二进制路径执行：

./mihomo-linux-amd64 -t -f "config.yaml"

Windows 示例：

.\mihomo-windows-amd64.exe -t -f "config.yaml"

预期结果是配置测试成功；若失败，先修复 YAML 缩进、字段拼写、端口占用或代理组引用。校验通过不代表节点一定可用，它只说明配置能被当前核心读取。

1. 用 API 确认实际核心版本。配置中的 external-controller 只监听本机，secret用于保护 API。Mihomo API 文档说明，/version用于获取版本，/configs用于查看运行配置：

curl -H "Authorization: Bearer replace-with-a-local-secret" http://127.0.0.1:9090/version
curl -H "Authorization: Bearer replace-with-a-local-secret" http://127.0.0.1:9090/configs

预期结果：第一个响应包含 version；第二个响应中能看到 tun对象及当前 dns-mode。如果没有设置 secret，可删除 Authorization头，但不建议把 API 监听到公网。

1. 重载配置。修改正在运行的配置后，可在客户端使用“重载配置”入口；也可以通过 API：

curl -X PUT "http://127.0.0.1:9090/configs?force=true" \
  -H "Authorization: Bearer replace-with-a-local-secret"

API 文档将 PUT /configs?force=true定义为重新加载基本配置。重载失败时，恢复备份配置；如果新核心本身启动失败，则停止新二进制并换回保留的旧核心文件。

DNS 对照实验：区分 native、hijack 和出站连接问题

先固定节点、代理组、enhanced-mode 和上游 DNS，只修改 tun.dns-mode。在 Windows 或 Linux 上分别执行：

nslookup example.com 8.8.8.8
dig @8.8.8.8 example.com

这里的 198.18.x.x不是固定网站 IP，而是示例配置中的 Fake IP 地址范围。若返回真实 IP，优先检查 strict-route、auto-redirect、防火墙和实际运行核心；若 DNS 已返回 Fake IP 但网页仍打不开，问题更可能在规则、代理组或出站节点。

再分别测试代理端口和 TUN：带 -x的是经 HTTP 代理端口，不带 -x且 TUN 开启的是经 TUN，关闭 TUN 后执行同一条不带 -x命令才是基线。

curl -I -x http://127.0.0.1:7890 https://example.com
curl -I https://example.com

如果第一条成功、第二条失败，优先排查 TUN、权限和路由；如果两条都失败，再排查节点、端口、TLS 参数和网络路径。经 HTTP 代理时，不要用 curl -4 或 curl -6判断最终出口地址族。

常见问题与回滚顺序

旧核心为什么没有报错，但 dns-mode 不生效？

旧核心可能忽略未知字段并继续启动，因此不能把“没有报错”当成字段已生效。用实际二进制的 -v或 API /version确认版本，再用 API /configs查看运行配置。

为什么 nslookup 没有返回 198.18.x.x？

先确认配置使用了 enhanced-mode: fake-ip，再检查 Windows 的 strict-route或 Linux 的 auto-redirect。如果是 macOS、局域网 DNS 或系统服务发起的请求，自动拦截能力可能不同，不能只依据这一条命令下结论。

为什么客户端升级后仍然没有 dns-mode？

客户端配置升级和内核升级是两件事。查看客户端的内核管理或运行日志，确认实际调用的二进制是否为 v1.19.33；如果仍是旧核心，需要切换或替换内核，再重新加载配置。

改成 hijack 后无法联网，怎么回滚？

先停止运行实例，把 dns-mode恢复为 native或恢复完整的 config.yaml.bak；如果问题仍在，再停止新版本二进制，换回保留的旧核心文件。恢复后只改一个变量，先重新执行 -t -f配置校验，再启动。

常见问题

Mihomo v1.19.33 新增的主要功能是什么？

Release 页面列出的主要功能是为 TUN 增加 <code>dns-mode</code>，提供 <code>disabled</code>、<code>native</code> 和 <code>hijack</code> 三种系统 DNS 处理模式。

Windows 应该直接使用 hijack 吗？

建议先使用 <code>native</code>确认 TUN 和 DNS 正常，再切换到 <code>hijack</code>并启用 <code>strict-route: true</code>。如果虚拟机或局域网软件异常，先回退到 <code>native</code>。

旧核心为什么没有提示 dns-mode 字段错误？

旧核心可能忽略未知字段并继续运行，因此应使用实际二进制的 <code>-v</code>或 API <code>/version</code>确认版本，再通过 API <code>/configs</code>查看运行配置。

如何判断 hijack 是否真的拦截了 DNS？

在 Windows 或 Linux 上执行 <code>nslookup example.com 8.8.8.8</code>或 <code>dig @8.8.8.8 example.com</code>。使用 <code>fake-ip</code>时返回 <code>198.18.x.x</code>说明请求进入 Mihomo DNS 模块；返回真实 IP 则需检查严格路由、自动重定向和防火墙。

相关阅读

• 继续排查 Mihomo TProxy 连接异常
• 查看 Clash Verge Rev 的配置导入和代理排查步骤
• 检查订阅格式与客户端导入问题

参考资料

1. MetaCubeX/mihomo v1.19.33 Release
2. mihomo 文档：TUN 配置
3. mihomo 文档：DNS 配置
4. mihomo 文档：API
5. mihomo 文档：通用配置与 External Controller
6. MetaCubeX/mihomo Wiki：FAQ