Mihomo TUN 模式怎么设置？最小配置、开启验证与断网排查

更新于 2026-10-31 · glados.lat

简答：Mihomo TUN 模式的核心是：在已有可用配置和代理组的前提下启用顶层 `tun`，通常先保留 `stack: mixed`、`auto-route: true`、`auto-detect-interface: true`，再按系统权限开启客户端的 TUN 开关。开启后不要只看“已连接”，还要依次确认虚拟网卡、路由、日志、规则命中和目标应用是否真的经过 Mihomo；如果断网，先关闭 TUN 或使用客户端的网络恢复功能，再逐项回滚。

定义：Mihomo TUN 模式是一种在网络层接管系统流量的方式，区别于只接收应用代理设置的 HTTP、SOCKS 或 Mixed 代理端口；它本身不提供节点，仍需要可用的代理配置、代理组和规则。

先做这三步：不要直接复制整份配置

如果你的目标只是让系统中不支持手动代理的应用也经过 Mihomo，先按下面顺序操作。第一步，确认当前配置已经导入订阅或至少存在一个可用代理、代理组和规则；TUN 只负责接管流量，不会自动生成节点，也不会把配置中的 DIRECT 规则改成代理。第二步，备份当前配置文件或导出当前配置。第三步，只把下面的 tun 区块合并到现有配置的顶层，不要覆盖原有的代理、规则和 DNS 配置。

结构示例，不可单独运行：

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

这是低改动起点，不是所有设备的通用最终配置。当前 Mihomo 文档列出的 stack 值包括 system、gvisor、mixed 和 mips；其中 mips 是 Mihomo 自研协议栈，并不是默认值或必须选择的协议栈。若没有明确的兼容性问题，先不要盲目修改 stack。字段和平台限制应以Mihomo TUN 配置文档为准。

五层验证表：每一步都要看到什么

层级	检查内容	可观察结果	不能据此推断
配置	配置校验或重新加载	没有 YAML 缩进、未知字段或启动错误	不代表节点可用
权限	管理员、Helper、root 或 VPN 权限	TUN 开关保持开启	不代表已有流量被接管
接管	虚拟网卡、路由和 TUN 日志	网卡和路由出现，日志无启动失败	不代表规则选择了代理
出站	代理组、节点和连接日志	目标连接有实际出站记录	不代表所有应用都经过代理
应用	浏览器、终端或指定应用	目标应用能按预期访问	不代表长期速度或稳定性

配置项怎么选：先理解四个关键字段

enable 控制是否启用 TUN；auto-route 负责自动设置路由，使系统流量进入 TUN；auto-detect-interface 用于自动选择出口网卡，多网卡、虚拟机或同时连接有线和无线网络时，可能需要手动指定出口；dns-hijack 会把匹配的 DNS 连接导入 Mihomo 的 DNS 模块，未写协议时按文档说明处理。

auto-redirect 不能当作所有平台都可用的开关。当前文档说明它主要支持 Linux，并且要求同时启用 auto-route；Android、Windows 和 macOS 不应因为看到示例就直接照搬。strict-route 会加强路由约束，可能影响局域网访问、虚拟机或其他多宿主网络场景，所以先用默认或关闭状态完成基础验证，只有明确需要时再单独测试。

mtu 影响最大传输单元，普通用户建议先保留默认值。不要把修改 MTU 当作 TUN 的必需步骤；只有出现特定链路上的分片、连接建立后频繁中断等可复现现象时，才应一次只改一个值并记录结果。

DNS 也不要与 TUN 同时大幅改动。Windows 和 macOS 无法自动劫持发往局域网的 DNS 请求；Android 开启“私人 DNS”时，自动 DNS 劫持也可能不生效。相关限制可在MetaCubeX 的 TUN 字段说明中核对。

不同客户端和系统怎么开启

Windows：先解决服务或管理员权限

打开使用 Mihomo 内核的客户端，先激活或加载配置，再进入设置页查找 TUN Mode、TUN 模式或类似名称。
如果开关提示需要 Service Mode、Service 或 Admin Mode，先安装服务或以管理员权限运行客户端。Clash Verge Rev 的界面文案明确区分了 System Proxy 和 Tun Mode，并提示 TUN 需要 Service Mode 或 Admin Mode；其设置项可参考项目设置文案。
开启后等待虚拟网卡和路由建立，再测试一个原本不读取系统代理的应用。不要同时把“系统代理已开启”当成 TUN 已生效的证据。

如果 TUN 开关自动关闭，优先检查服务是否运行、内核是否启动、Windows 防火墙是否阻止内核，以及配置是否通过校验。防火墙放行、服务名称和菜单位置会随客户端版本变化，无法确认时以当前客户端页面和日志为准。

macOS：注意 Helper、utun 网卡和配置激活顺序

先激活配置，再开启 TUN。首次启用系统级网络接管时，客户端可能请求管理员授权或安装辅助组件。
如果配置中指定 device，macOS 网卡名称需要使用 utun 开头；不确定时先删除自定义设备名，让内核或客户端使用默认行为。
确认 TUN 开启后，检查是否出现 utun 接口，再测试终端或其他不会自动读取系统代理的应用。

如果 TUN 开启后立即断网，先关闭 TUN；若客户端提供“恢复网络”功能，优先使用它。官方 Mihomo Dashboard 项目说明，桌面端 TUN 需要系统级权限，并在 macOS、Windows、Linux 上使用不同的辅助服务；该项目也说明了异常退出后应重新打开应用并执行网络恢复。参见MetaCubeXD 官方项目说明。

Linux：检查 TUN 设备、权限和路由

确认系统存在 /dev/net/tun，并让运行 Mihomo 的服务具备创建 TUN 和设置路由所需的权限。
先启用 auto-route，不要一开始同时加入复杂的 auto-redirect、自定义路由排除和多出口规则。
如果使用 systemd，检查服务状态和日志；官方服务示例使用 CAP_NET_ADMIN 等能力，并提供了 systemctl status mihomo 与 journalctl -u mihomo 的检查方式，具体权限仍应按你的发行版和部署方式调整。

Linux 上的 auto-redirect 只在明确需要透明重定向时再测试。启用后若路由异常，不要直接删除系统路由；先停止 Mihomo 或关闭 TUN，再确认路由是否恢复。

Android：TUN 通常表现为 VPN 权限请求

在使用 Mihomo 内核的 Android 客户端中导入或激活配置，确认已有代理组和规则。
开启客户端的 TUN、VPN 或类似开关，接受系统 VPN 权限请求。
如果使用私人 DNS、热点共享或其他 VPN 类应用，先暂时关闭它们进行基础验证。当前 Mihomo 文档说明 Android 的 DNS 劫持会受私人 DNS 影响，TUN 的本地 IPv4 转发和热点共享也有平台边界。

Android 的具体菜单名、应用分流和 VPN 权限流程取决于客户端，不应把桌面端 YAML 字段直接当成手机界面开关。若客户端只提供图形开关而没有配置编辑器，优先使用客户端的默认 TUN 配置完成验证。

开启后怎么确认真的生效

看状态：确认 TUN 开关保持开启，且没有“服务不可用”“核心未运行”或启动失败提示。
看接口：Windows 检查网络适配器，macOS 检查 utun 接口，Linux 检查 TUN 设备和路由，Android 检查系统 VPN 状态。出现接口只说明设备创建成功，不等于代理出站成功。
看日志：打开连接日志，访问一个目标域名，确认是否有 DNS 查询、规则匹配和出站连接记录。
看规则：如果日志显示命中 DIRECT，网页直连可能是规则结果，不一定是 TUN 失效；先选择明确的代理规则或检查代理组。
分应用测试：分别测试浏览器、终端、开发工具或其他不读取系统代理的应用。浏览器能打开网页，只能证明浏览器这一条路径可用，不能覆盖所有应用。

建议每次只改变一个变量。例如先保持 DNS 和 MTU 不变，只验证 TUN；确认 TUN 能接管后，再测试 DNS；最后才考虑严格路由、路由排除或 MTU。这样出现问题时，才有可回退的对照。

四种常见现象：按顺序排查并安全回滚

1. TUN 开启后立即断网

先关闭 TUN，恢复系统代理或退出客户端，确认网络是否恢复。若恢复，优先检查配置是否缺少可用代理组、DNS 是否被劫持但没有正常响应、出口接口是否选错，以及其他 VPN 或虚拟网卡是否冲突。不要直接禁用未知网卡或手动删除全部路由。

2. 浏览器正常，但终端或游戏无法连接

这通常只能说明不同应用使用了不同的网络路径，不能直接判断原因。检查 TUN 是否真的启用、规则是否把目标域名分到了 DIRECT、应用是否使用独立 DNS，以及日志中是否出现该应用的连接记录。若客户端支持按进程或应用分流，再单独检查排除规则。

3. TUN 开关自动关闭

优先查看权限、服务、Helper 和内核启动日志，再检查 YAML 缩进和字段拼写。Mihomo 配置使用 YAML，缩进和键名会影响解析；可以参考官方语法说明中的配置格式要求。修改后重新加载配置，不要连续修改多个字段。

4. DNS 失败或局域网设备无法访问

先暂时关闭 dns-hijack 或恢复原 DNS 配置进行对照，确认是否只有局域网 DNS 受影响。Windows 和 macOS 对局域网 DNS 劫持存在限制，Android 的私人 DNS 也可能阻止自动劫持；严格路由还可能影响局域网或虚拟机访问。验证完成后，再按实际需求加入路由排除。

回滚顺序

关闭客户端 TUN 开关。
如果客户端提供“恢复网络”，先执行恢复。
重新加载备份配置，或把 tun.enable 改为 false。
确认系统代理、DNS、路由和目标应用恢复后，再逐项重新启用。

正常退出通常比强制结束进程更适合用于回滚；如果已经强制退出后断网，重新打开客户端，再使用关闭 TUN 或恢复网络功能。

常见问题

Mihomo TUN 模式和系统代理有什么区别？

TUN 在网络层接管流量，适合处理不读取 HTTP 或 SOCKS 代理设置的应用；系统代理只影响遵循操作系统代理设置的应用。两者可以因客户端实现而同时存在，但不要把系统代理开关亮起当成 TUN 已生效的证据。

stack 应该选 system、gvisor、mixed 还是 mips？

没有脱离平台和故障现象的“永远最佳”选项。当前官方文档列出四种可用值，并说明各自使用的协议栈不同。建议先使用客户端或现有配置的默认值；若没有明确问题，可从 mixed 开始测试，但不要把它写成所有设备的必选项。遇到防火墙、兼容性或性能问题时，再一次只切换一个值并记录结果。

只写 `tun.enable: true` 就够了吗？

不一定。是否能接管系统流量还取决于路由、权限、DNS、客户端服务和已有代理配置。最小配置可以从 enable、auto-route、auto-detect-interface 和必要的 DNS 设置开始，但每个平台的实际字段支持仍需按当前 Mihomo 版本和客户端验证。

TUN 开启后能不能保证所有软件都走代理？

不能保证。规则可能明确指定 DIRECT，应用也可能使用特殊网络栈、独立 VPN、局域网地址或被客户端排除。应通过连接日志和目标应用测试确认，不要只看 TUN 状态。

配置校验失败应该先改什么？

先检查 tun: 是否位于顶层、缩进是否只使用空格、字段名是否与当前文档一致，再删除最近新增的一个字段进行对照。不要把整份网上配置覆盖到现有订阅配置中；保留备份，逐项合并更容易定位问题。

常见问题