Mihomo TUN 模式有什么用？

更新于 2026-10-28 · amyclash.top

简答：Mihomo TUN 模式的作用，是通过虚拟网卡和系统路由接收更多应用的网络流量，不再只依赖系统代理设置。它适合浏览器能用、但游戏、命令行、启动器或部分 UDP 应用不走代理的情况；开启后仍要依靠规则、策略组、DNS 和路由决定流量最终直连还是经代理。

定义：Mihomo TUN 模式是一种基于虚拟网卡的网络层接入方式，用系统路由把符合条件的流量交给 Mihomo 处理。

先判断：你是否真的需要开启 TUN

如果只是浏览器或支持系统代理的应用无法连接，先检查系统代理地址、端口、规则模式和策略组，不要直接开启 TUN。TUN 更适合解决“部分应用不遵循系统代理”的问题。

常见现象与建议

现象	优先处理方式	是否考虑 TUN
浏览器和普通桌面应用都能使用	继续使用系统代理，先确认规则和节点	通常不需要
浏览器正常，但命令行、游戏或启动器不走代理	确认这些应用是否支持手动代理	可以考虑
应用使用 UDP，系统代理无法覆盖	检查客户端和核心对 UDP 的支持	可以考虑，但需单独验证
开启后整机断网或 DNS 异常	先关闭 TUN、恢复网络，再检查路由和 DNS	暂时不要继续改高级参数
电脑同时运行其他 VPN、虚拟机或容器网络	先停用其他网络接管工具做对照测试	谨慎开启

官方文档将顶层 tun 配置定位为接收系统流量，并用于自动路由、DNS 劫持和按应用路由；桌面控制面板文档也说明，TUN 在网络层工作，可覆盖不遵循单独代理设置的应用。可参考 mihomo 入站配置文档和 MetaCubeX 控制面板说明。

Mihomo TUN 模式具体有什么用

1. 让更多应用接入 Mihomo

系统代理通常要求应用主动读取系统代理设置，或手动填写 HTTP、SOCKS 等代理地址。TUN 则创建虚拟网络接口，并通过路由把符合条件的流量送入 Mihomo，因此对不读取系统代理的应用更有帮助。

但“接入 TUN”不等于“所有流量都自动走代理”。流量进入 Mihomo 后，还会受到规则、策略组、直连规则、排除地址、DNS 解析方式和应用自身网络行为影响。

2. 配合自动路由处理系统流量

auto-route: true 用于自动设置路由，使符合条件的流量进入 TUN。官方文档同时说明，自动路由的实际范围还会受到路由地址、排除地址、接口、UID、Android 应用包名等配置影响。

3. 在需要时处理 DNS 请求

dns-mode 可控制系统 DNS 的处理方式，官方文档列出了 disabled、native 和 hijack。其中 hijack 会额外拦截发往 53 端口的 DNS 流量，但不同平台有边界：Windows 和 macOS 无法自动劫持发往局域网的 DNS 请求，Android 开启 Private DNS 时也可能无法自动劫持。

4. 覆盖部分 UDP 场景，但不能替代兼容性验证

TUN 可以接收比普通系统代理更多的网络流量，但某个游戏、启动器或实时通信应用是否能正常工作，还取决于规则、DNS、UDP 支持、节点能力和应用自身连接方式。不要仅凭 TUN 已启用，就断定某个应用一定可用。

TUN 与系统代理、应用内代理有什么区别

三种接入方式对比

方式	主要工作层级	优点	限制
系统代理	应用代理设置层	改动少，便于按应用自行决定	不支持读取系统代理的应用可能不生效
Mihomo TUN	虚拟网卡和系统路由层	可覆盖更多不遵循系统代理的应用	需要更高权限，可能与 VPN、虚拟机、容器或防火墙冲突
应用内代理	单个应用内部	范围清晰，排查相对简单	需要逐个配置，不能覆盖其他应用

三者可以同时存在，但同时开启多个网络接管工具会增加路由冲突和 DNS 异常的排查难度。首次验证时，建议只保留一个 TUN 接管者，并先关闭其他 VPN 或虚拟网卡工具。

另外，TUN 只是流量入口，不提供节点、订阅或出口线路。Mihomo 仍需要有效的代理配置、策略组和可用的出站连接；没有这些条件时，开启 TUN 只会改变流量进入方式，不会自动产生代理能力。

最小开启流程：先备份，再逐项验证

备份当前配置。复制一份正在使用的配置文件，记录当前系统代理、DNS 和其他 VPN 状态。不要一开始就同时修改 TUN、DNS、Fake-IP、路由排除项和 MTU。
确认已有可用配置。先在不开启 TUN 的情况下确认 Mihomo 本身能启动，并且至少有一个策略组或出站可以正常建立连接。
先使用最少字段。在配置中加入以下骨架，先不要手动改 MTU、路由地址、UID、接口排除项等高级字段：

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

这是用于理解和逐项验证的配置骨架，不是脱离现有配置即可运行的完整成品。stack 可选值、自动路由、DNS 劫持和严格路由的行为，应以当前核心对应的 mihomo TUN 官方字段文档为准。

按系统授予权限。Windows、macOS 和 Linux 的 TUN 路由通常需要管理员或 root 权限；Android 还涉及系统 VPN 权限和应用范围选择。客户端菜单名称可能不同，找不到选项时应先确认客户端是否真的启用了 Mihomo 核心和 TUN 功能。
启动后只测试一个现象。先测试普通网页或一个明确的 TCP 连接，再测试原本不走系统代理的应用。不要同时更换节点、模式、DNS 和规则，否则无法判断问题来自哪里。

开启后的校验顺序

看 TUN 状态。确认客户端显示 TUN 已启用，系统中出现对应虚拟网卡或网络接口。
看 Mihomo 日志。重点观察配置加载失败、权限不足、DNS 监听失败、路由设置失败和连接循环等信息。
看连接记录。确认目标应用的连接是否进入 Mihomo，再观察它匹配了哪个规则和策略组。仅看到连接记录，不代表最终访问一定成功。
分开测试 DNS 和代理。先确认域名能否解析，再确认连接是否建立，最后判断目标应用的协议是否被正确处理。不要把单次 DNS 成功、ping 成功或测速结果当成完整可用性证明。
对比 TUN 开关。关闭 TUN 后重复同一测试。如果关闭后恢复，问题范围通常集中在路由、DNS、权限、虚拟网卡或与其他网络工具的冲突。

如果客户端提供配置检查功能，先使用客户端的检查入口；使用命令行核心时，应以当前版本支持的校验命令和退出结果为准，不要把其他版本的命令直接套用。

常见问题：为什么开了 TUN 仍然不通

规则把流量设为 DIRECT

TUN 只负责把流量送进 Mihomo，最终走代理还是直连由规则和策略组决定。检查连接记录中的匹配规则与最终策略，不要只看 TUN 开关。

DNS 解析路径不一致

DNS 可能仍由系统、局域网设备或客户端内部模块处理。检查 dns-mode、dns-hijack、Fake-IP 以及局域网域名排除项；修改前先记录原配置，避免一次改动太多。

权限不足或虚拟网卡没有正常建立

如果日志出现权限、驱动、接口或路由错误，先退出并重新以所需权限启动客户端，确认虚拟网卡状态，再考虑修改配置。不要在没有日志依据时反复更换协议栈。

其他 VPN、虚拟机或容器抢占路由

企业 VPN、虚拟机网卡、容器网络和其他代理客户端都可能改变路由或 DNS。关闭其他接管工具后复测；若恢复，再逐个开启以定位冲突来源。

严格路由造成局域网或虚拟化异常

strict-route 可用于强化路由约束和 DNS 防泄漏，但官方文档也提示，Windows 某些应用如 VirtualBox 可能因此出现异常。遇到局域网、虚拟机或共享网络问题时，应记录原值，临时关闭后立即复测，并在确认影响范围后决定是否恢复。

不同系统的注意事项

Windows：首次启用 TUN 可能需要管理员授权；严格路由与系统 DNS 行为有关，局域网、虚拟机和多网卡环境应优先做对照测试。
macOS：设备名如果手动填写，官方文档要求 macOS 接口名称使用 utun 开头；不要照搬 Windows 的网卡名称。
Linux：auto-redirect 只适用于 Linux，并且要求同时启用 auto-route；部分高级功能还依赖 nftables、权限和系统网络环境。
Android：应用范围、用户范围和 Private DNS 会影响结果；如果只想让某些应用进入 TUN，应优先使用客户端提供的应用选择，而不是盲目修改全局路由。

具体菜单、权限提示和网卡名称属于客户端实现，可能随客户端版本变化。本文只说明 Mihomo 核心 TUN 的工作逻辑，实际操作时应以所用客户端界面和当前核心字段为准。

断网时的恢复顺序

在客户端关闭 TUN，等待网络恢复。
如果仍无法联网，退出客户端并检查系统代理是否还处于开启状态。
关闭其他 VPN、虚拟网卡或网络共享工具后重新测试。
恢复备份配置，优先回到“仅启用 TUN、自动路由和自动识别网卡”的状态。
确认普通网络恢复后，再一次只改一个字段，并观察日志和连接记录。

如果客户端提供“恢复网络”按钮，应优先使用该功能。不要在网络异常时连续执行来源不明的清理脚本，也不要直接删除系统路由或 DNS 配置。

常见问题