狮子云 - 加速你的每一秒

Mihomo TUN 模式配置教程:开启、验证与故障排查

更新于 2026-10-31 · shizi.buzz

简答:Mihomo TUN 模式的最短路径是:备份配置,确认当前内核版本和权限,在 tun 下启用 enable、auto-route 与 auto-detect-interface,再按需配置 dns-hijack,重载配置后检查 TUN 网卡、核心日志和连接记录。当前 Mihomo 文档列出的 stack 可用值包括 system、gvisor、mixed 和 mips;不要把示例 DNS、fake-ip 或 stack 直接当成所有系统的通用最佳配置。本文讲的是 Mihomo 内核配置,并补充桌面图形客户端首次启用时的权限与配置加载检查。

定义:Mihomo TUN 模式是通过虚拟网卡和系统路由接管网络层流量,使不支持系统代理的应用也能进入 Mihomo 规则处理流程。

先试这一步:最小配置与验证顺序

本文是狮子云的第三方使用指南,不代表 Mihomo 或任何图形客户端的官方页面。先不要一次加入 fake-ip、复杂 DNS 规则、IPv6、路由排除和自定义 MTU;先用最小配置确认 TUN 能启动,再逐项增加设置。

Mihomo TUN 配置速查
项目建议动作验证边界
tun.enable先设为 true只能说明核心尝试创建 TUN,不能证明网页已经可用。
stack优先使用官方文档列出的 mixed、gvisor、system 或 mips,具体以当前内核校验结果为准。协议栈改变的是 TUN 转发实现,不等于自动提升速度。
auto-route需要接管系统流量时设为 true要同时检查系统路由、TUN 网卡和连接记录。
auto-detect-interface单网卡设备可先设为 true多网卡、企业 VPN、虚拟机环境可能需要手动指定出口。
dns-hijack先使用官方示例形式,确认 DNS 模块已启用后再调整。浏览器能打开不代表所有 DNS 请求都经过 Mihomo。

官方 TUN 文档目前列出 system、gvisor、mixed 和 mips 四种协议栈,并说明不同协议栈的实现方式存在差异。此前常见的“mips 一定是错误值”说法与当前文档不一致;但不同版本、不同构建标签和不同客户端可能存在字段差异,因此应以当前内核配置校验和启动日志为准。参考:Mihomo 官方 TUN 配置文档。

  1. 备份:复制当前配置文件,记录 Mihomo 版本、系统版本和使用的客户端。
  2. 最小化:暂时关闭其他代理客户端、系统 VPN 和可能创建虚拟网卡的工具。
  3. 配置:只加入 TUN 基础字段,保留原有代理、规则和 DNS 配置,不要覆盖整份订阅文件。
  4. 重载:通过客户端的重新加载配置功能,或按独立内核的启动方式重启。
  5. 验证:依次观察核心日志、虚拟网卡、连接记录和实际应用;任一步失败就停止扩展配置。

Mihomo TUN 的最小 YAML 怎么写

下面只展示 TUN 相关字段,不能单独作为完整可运行配置。stack: mixed 是一个可核对的起点;如果当前版本不接受该值,先查看启动日志和配置校验结果,不要把字段改成未经文档支持的拼写。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

字段含义可以这样理解:

  • enable:是否启用 TUN。
  • stack:TUN 使用的网络协议栈。官方文档列出的可用值为 system、gvisor、mixed 和 mips;文档还说明默认值与推荐选择可能随文档版本变化,不能凭旧教程判断。
  • auto-route:自动设置路由,将符合范围的流量导入 TUN。
  • auto-detect-interface:自动识别流量出口接口。设备同时连接有线、无线、VPN 或虚拟网卡时,自动识别结果需要结合日志核对。
  • dns-hijack:把匹配到的 DNS 连接导入 Mihomo 内部 DNS 模块。官方文档提醒,Windows 和 macOS 不能自动劫持发往本地网络的部分 DNS 请求;Android 开启 Private DNS 时也可能无法自动劫持。

不要直接把固定 DoH 地址、fake-ip、自定义 MTU 或 IPv6 路由复制到所有环境。DNS 服务器是否可达、内网域名是否需要保留、订阅是否会覆盖本地修改,都应先单独核对。

Windows 图形客户端与独立内核的开启路径

不同图形客户端的菜单名称可能变化,所以这里区分“内核配置”和“客户端开关”。如果使用桌面图形客户端,先导入或激活一个配置,再打开该客户端的 TUN 开关;首次启用系统级路由通常需要管理员授权。官方 Dashboard 项目说明,桌面 TUN 需要特权辅助服务执行系统级网络设置,首次启用可能出现系统授权提示,可参考 MetaCubeX Dashboard 官方说明。

  1. 打开客户端,确认当前配置已经激活,且配置文件中存在可用代理、规则和 DNS 基础设置。
  2. 进入设置或内核设置,找到 TUN 开关;如果界面提供协议栈选项,先选择与配置文件一致的值,不要同时在界面和 YAML 中设置相互冲突的值。
  3. 按系统提示允许管理员权限或安装特权辅助组件。出现权限失败时,先停止,不要手动删除系统路由或禁用物理网卡。
  4. 打开 TUN 后,检查 Windows 网络适配器中是否出现对应虚拟网卡,再查看核心日志是否出现 TUN 启动、地址和路由信息。
  5. 先测试一个普通网页和一个明确命中规则的应用,再检查连接记录中的目标、规则和出站结果。

停止条件:如果 TUN 开关自动关闭、配置重新加载失败或出现持续断网,立即关闭 TUN并恢复备份配置。端口能监听只说明本地服务存在,不等于 TUN 路由已经生效。

macOS、Linux 和 Android 的差异怎么处理

不要用 Windows 的命令或菜单路径替代其他系统的操作。Mihomo 官方文档明确写出了部分平台差异:macOS 的 TUN 设备名称需要以 utun 开头;Linux 的 auto-redirect 只适用于 Linux,并且需要与 auto-route 配合;Android 只转发本地 IPv4 连接,热点或网络共享场景还需要单独核对客户端和系统能力。详情以 Mihomo 官方英文 TUN 文档为准。

  • macOS:重点检查系统网络扩展或客户端授权、TUN 设备名称、DNS 解析是否真正进入核心。若系统应用解析异常,即使核心日志没有明显报错,也应先关闭 fake-ip 和复杂 DNS 规则做最小复现。
  • Linux:重点检查 TUN 设备、路由表、iptables 或 nftables,以及 NetworkManager、systemd-resolved 是否改写 DNS 状态。只在确认需要时启用 auto-redirect,不要把 Linux 的重定向字段照搬到 Windows 或 macOS。
  • Android:先检查客户端 VPN 权限、Private DNS、应用分流和是否开启了其他 VPN。Android 的应用包名包含或排除规则需要在支持该字段的客户端和内核版本中验证。

按现象排查:连接失败、DNS 异常与仍然直连

TUN 开启后的现象分流
现象先看哪里下一步
开关自动关闭客户端权限提示、核心启动日志、配置校验错误确认当前版本支持字段,删除最近新增的字段后重新加载。
开启后完全断网TUN 网卡、路由表、核心日志、其他 VPN关闭 TUN 回滚;逐项停用其他虚拟网卡和复杂 DNS 设置。
网页能开但某应用仍直连应用是否使用自己的代理或 DNS、连接记录是否出现确认该应用是否绕过系统路由,检查规则命中和应用分流设置。
域名解析失败DNS 模块日志、dns-hijack、Private DNS 或 systemd-resolved先关闭 fake-ip 或自定义 DoH,使用最小 DNS 配置复现。
局域网设备不可访问strict-route、路由排除、局域网网段先关闭严格路由验证是否恢复,再按实际网段配置排除项。

“浏览器可以打开网页”只能证明某个应用的某次连接成功;“连接列表有记录”只能证明流量被核心看见;“端口正在监听”也不能证明 DNS、路由和规则链完整。验证 TUN 至少应同时观察:核心是否成功创建 TUN、系统是否出现虚拟网卡、目标连接是否出现在连接记录、规则是否命中预期策略,以及应用是否能完成实际请求。

如果企业 VPN、WSL2、Docker、虚拟机或其他安全软件同时运行,先关闭其中一个变量做复现。它们都可能改变路由、DNS 或虚拟网卡行为;在没有日志和可重复步骤前,不要直接断言是 Mihomo 内核故障。

DNS、fake-ip、MTU 与 stack 的安全调整顺序

建议按照“基础 TUN→DNS→规则→fake-ip→性能参数”的顺序调整。先确认 tun.enable、auto-route 和网卡正常,再启用 dns-hijack;DNS 稳定后再评估 fake-ip、Sniffer、IPv6 和路由排除。这样出现问题时,能更快判断是 TUN、DNS 还是规则导致。

  • stack:当前官方文档列出四种值。system 使用系统协议栈,gvisor 使用用户态协议栈,mixed 混合 TCP 与 UDP 的处理方式,mips 是 Mihomo 自研 IP 协议栈。不要仅按“速度最快”选择;应以当前版本、系统、防火墙和实际日志为依据。
  • MTU:官方文档指出 MTU 会影响极端条件下的传输速率,普通用户可以先保留默认值。只有出现可复现的分片、握手或特定链路问题时,才逐步调整。
  • DNS:示例 DNS 地址不是通用最佳实践。需要考虑网络可达性、内网域名、现有 VPN 和客户端自带 DNS。
  • fake-ip:启用后,某些内网、认证、游戏平台或特殊应用可能需要加入过滤项;没有明确现象时,不建议把大段 fake-ip 例外规则直接复制。

如何关闭 TUN 并恢复网络

  1. 先在客户端关闭 TUN,并等待核心日志显示 TUN 已停止或配置已回滚。
  2. 关闭其他代理客户端和 VPN,重新启用系统原有网络连接。
  3. 检查浏览器、终端和目标应用是否恢复基础联网;不要先判断线路或节点质量。
  4. 如果仍无法联网,恢复备份配置并重启对应客户端;Windows、macOS、Linux 的残留路由和 DNS 状态应使用系统网络设置或客户端提供的恢复功能处理。
  5. 记录恢复前后的 Mihomo 版本、系统、配置片段和日志,再决定是否重新启用单个字段。

不要直接删除路由表、禁用物理网卡或手动执行来源不明的网络修复命令。不同系统的路由和 DNS 管理方式不同,错误操作可能让问题变得更难定位。

补充说明:版本与配置覆盖

Mihomo TUN 字段会随内核和客户端版本变化。本文以 2026 年 10 月 31 日检索到的 Mihomo 官方文档为依据,但不把某一版本的默认行为扩展成所有版本的保证。特别是图形客户端可能在启动时生成运行时配置,订阅更新也可能覆盖本地修改。

实际排查时,请同时记录:Mihomo 版本、客户端名称与版本、操作系统、当前生效配置中的 TUN 字段、启动日志、TUN 网卡名称以及失败连接的规则命中结果。缺少这些信息时,只能把结论降级为排查方向,不能确认是 DNS、路由、协议栈还是订阅覆盖导致。

常见问题

Mihomo TUN 的 stack 应该填什么?

当前 Mihomo 官方 TUN 文档列出的可用值包括 system、gvisor、mixed 和 mips。不能使用拼写错误或来源不明的值;具体选择应结合当前内核版本、系统、防火墙和实际日志。若无明确问题,可先使用官方文档示例中的值,再通过启动日志确认。

Mihomo TUN 开启后断网,应该先改 DNS 还是先关 TUN?

先关闭 TUN并恢复网络,再备份日志和配置。之后用最小配置复现:保留基础 TUN 字段,暂时移除 fake-ip、自定义 DoH、复杂规则和额外虚拟网卡,逐项恢复。不要在持续断网时同时修改多个字段。

开启 TUN 后浏览器能上网,是否说明配置完全正确?

不能。浏览器成功只代表某次应用连接可用。还应检查核心是否创建 TUN、系统是否出现虚拟网卡、连接记录是否出现、规则是否命中预期策略,以及 DNS 请求是否按照当前配置处理。

为什么 TUN 开启后某个应用仍然直连?

可能是应用使用独立代理、独立 DNS、应用分流或没有经过系统路由。先看 Mihomo 连接记录中是否出现该应用的目标连接,再核对规则命中和客户端的应用排除设置;如果连接记录完全没有出现,问题可能在应用或系统路由层。

dns-hijack、fake-ip 和 TUN 是否必须一起开启?

不是。TUN、DNS 劫持和 fake-ip 是不同层面的设置,不应默认全部启用。建议先验证基础 TUN,再逐步加入 DNS 劫持和 fake-ip;内网域名、Private DNS、企业 VPN 和 systemd-resolved 都可能改变实际行为。

相关阅读

参考资料

  1. Mihomo 官方 TUN 配置文档(中文)
  2. Mihomo 官方 TUN 配置文档(英文)
  3. MetaCubeX Dashboard 官方仓库:桌面 TUN 与权限说明