Mihomo TUN 模式怎么配置？

更新于 2026-10-30 · naiyovpn.top

简答：Mihomo TUN 模式的配置重点不是一次打开所有高级参数，而是先确认配置文件能启动，再启用 enable、stack、auto-route 和 DNS 劫持。普通用户建议先使用 system 协议栈与客户端默认参数，验证虚拟网卡、路由、日志和实际连接后，再调整 strict-route、MTU 或分应用规则。本文按 2026-10-30 可核对的 Mihomo 文档整理，字段仍应以当前安装版本的 --help 和对应版本官方文档为准。

定义：Mihomo TUN 模式是通过虚拟网卡和系统路由接收设备流量的工作方式，覆盖范围通常比只监听 HTTP、SOCKS 或 Mixed 代理端口更广。

先用最小配置：不要一开始修改 MTU、strict-route 和自定义路由

如果你的目标只是让 Mihomo 接管系统中未配置代理的应用，先从最小 TUN 配置开始。Mihomo 官方文档将顶层 tun 配置用于系统流量捕获、自动路由、DNS 劫持和按应用路由；普通用户优先使用顶层 TUN，而不是手动创建高级 Listener。可参考官方入口配置说明和官方 TUN 字段文档。

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

这段配置只适合在已有可用代理、代理组、规则和 DNS 配置的基础上追加。它不是完整的 Mihomo 配置文件；如果配置文件中没有合法的代理节点、代理组或规则，TUN 成功启动也不代表访问一定正常。

TUN 配置字段速查

字段	作用	新手建议
`enable`	启用或关闭 TUN	确认配置无误后设为 `true`
`stack`	选择 TUN 使用的协议栈	先用 `system`，遇到兼容问题再测试其他选项
`auto-route`	自动配置系统路由	桌面系统通常先保持 `true`
`auto-detect-interface`	自动识别出口网卡	多网卡、虚拟机或 VPN 环境出现路由错误时再核对
`dns-hijack`	接收指定目标的 DNS 请求	先按当前版本文档核对写法，遇到 53 端口冲突时先关闭验证
`mtu`	设置虚拟网卡最大传输单元	官方建议普通用户保留默认值，不要为“加速”盲目修改

官方文档说明，MTU 会影响特定条件下的传输表现，普通用户可以保留默认值；IPv6、GSO、路由集合、UID 和 Android 应用筛选等字段都有平台或前置条件，不建议在首次启动时一起加入。

开启前的准备：备份、核对版本和确认权限

备份原配置。复制当前 YAML 文件，保留一个可以正常使用的版本。首次修改只增加 tun 区块，不要同时重写 DNS、规则和代理组。
核对 Mihomo 版本。先在客户端关于页面或终端查看版本，并使用当前程序的 --help 检查命令选项。不同内核版本可能存在字段命名、默认值和弃用写法差异，尤其是旧式 strict_route、dns_hijack、inet4_route_address 等下划线写法。
确认订阅或配置本身可用。先关闭 TUN，用普通系统代理或 Mixed 端口确认至少有一个节点、代理组和规则能够正常工作。TUN 只改变流量接入方式，不能修复失效节点或错误的规则。
确认权限。Windows 通常需要管理员授权或客户端服务模式；macOS 可能需要允许系统网络扩展或相关权限；Linux 通常需要 root、网络管理权限或正确的服务权限；Android 则由客户端申请 VPN 权限。权限入口由具体客户端决定，页面名称可能不同。
记录回滚方法。准备关闭 TUN、恢复原配置、退出客户端并重新连接网络的步骤。不要在无法回滚的情况下直接开启 strict-route。

官方配置示例显示，TUN 配置支持 macOS、Linux 和 Windows，并包含内置 Wintun 说明；但不同客户端对内核、服务模式和界面的封装不同，不能把某个客户端的菜单名称当作所有客户端都具备。可对照MetaCubeX 官方配置示例。

Windows、macOS、Linux、Android 怎么开启

不同系统的推荐顺序

系统	建议操作顺序	重点检查
Windows	导入可用配置 → 激活配置 → 允许管理员授权或服务模式 → 打开 TUN	虚拟网卡、Windows 防火墙、管理员权限、其他 VPN 是否同时运行
macOS	导入配置 → 激活配置 → 授权网络扩展或 VPN → 打开 TUN	网络扩展权限、系统防火墙、Wi-Fi 与有线网卡切换
Linux	确认 TUN 设备和权限 → 校验配置 → 启动服务 → 查看路由和日志	`/dev/net/tun`、root 或能力权限、iptables/nftables、默认路由
Android	导入配置 → 允许 VPN 权限 → 选择 TUN 或 VPN 模式 → 需要时设置应用包含/排除	电池优化、应用分流、其他 VPN、系统私人 DNS

桌面客户端中，正确顺序通常是先激活配置，再启用 TUN。以官方桌面项目说明为例，TUN 的系统级路由需要管理员权限，并可能通过辅助服务完成网络设置；这说明“开关已打开”与“系统权限已经生效”不是同一件事。具体是否有服务模式、虚拟网卡检查或修复按钮，应以当前客户端界面为准，可参考MetaCubeX 官方桌面项目说明。

Android 的 include-package、exclude-package、include-android-user 等字段只适用于 Android，并且需要配合 auto-route；不应把这些字段复制到 Windows 或 macOS 配置中。

stack、auto-route、strict-route 和 DNS 怎么选

1. stack 先选 system

官方文档将 system 描述为使用系统协议栈，通常适合作为首个测试选项；gvisor 是用户空间协议栈，mixed 组合 TCP 与 UDP 的不同协议栈，mips 是 Mihomo 自研协议栈。不同系统、防火墙和应用类型下表现可能不同，因此不要仅凭名称判断优劣。先用 system 验证，失败后一次只改一个值。

2. auto-route 负责自动写入路由

auto-route: true 的目标是让系统流量进入 TUN。它并不决定最终使用哪个节点，也不保证所有流量都一定走代理，最终还要看规则命中结果。假如日志中显示某个域名命中了 DIRECT，这可能是规则选择，而不一定是 TUN 没有生效。

3. strict-route 不要作为第一步

strict-route 可用于更严格地把连接导向 TUN，但可能影响局域网设备访问、企业 VPN、虚拟机、WSL 或 Docker。先验证普通 TUN，再决定是否启用。启用后无法联网，应优先关闭它并恢复到上一个可用配置，而不是继续叠加 DNS、MTU 和自定义路由。

4. dns-hijack 与 53 端口冲突要分开排查

DNS 劫持只处理 DNS 请求，不等于所有网页连接都已通过代理。若设备已有本地 DNS 服务、其他 VPN、容器或安全软件占用 53 端口，开启 DNS 劫持后可能出现解析失败。排查时先把 dns-hijack 暂时移除，保留 TUN 和自动路由测试；如果网页恢复，再检查 DNS 监听、私人 DNS、系统防火墙和其他 VPN。

官方 TUN 文档列出了 dns-mode 的可选行为以及 dns-hijack 的写法；字段和默认行为会随版本变化，建议以当前官方 TUN 文档为准。

验证 TUN 是否真正生效：按网络层逐步检查

先看配置是否加载。客户端重新加载配置后，确认没有 YAML 缩进错误、未知字段或启动失败。若使用命令行或服务，先执行当前版本支持的配置检查命令；不要直接套用其他版本教程中的命令。
再看启动日志。重点关注 TUN 创建、路由、DNS、权限和端口错误。Linux 服务可按官方服务文档查看 systemd 状态与日志，例如使用 systemctl status mihomo 和 journalctl -u mihomo -o cat -e；命令是否适用取决于你的安装方式。
检查虚拟网卡。Windows 看网络适配器，macOS 看网络设置或系统接口，Linux 看网卡和路由表，Android 看 VPN 状态。虚拟网卡存在只是必要条件之一，不代表规则和出口一定正确。
检查连接记录与规则命中。访问一个普通网页或应用，观察连接是否进入 Mihomo，并确认规则组选择。若命中 DIRECT，不要马上判断 TUN 失败，先核对规则。
最后检查 DNS 和出口。先确认域名能解析，再观察实际连接是否成功。出口 IP、DNS 检测或测速只能证明某一个时刻、某一个请求的结果，不能替代完整的连接排查。

如果客户端启用了外部控制 API，官方 API 文档提供了获取版本、日志、运行配置和流量信息的接口，可用来辅助确认当前运行配置，而不是只看界面开关状态。参考Mihomo 官方 API 文档。

常见故障分流：先恢复可用，再做精细设置

TUN 故障快速定位

现象	优先检查	恢复动作
无法创建 TUN 或提示权限不足	管理员/root/VPN 权限、服务模式、网络扩展	关闭 TUN，重新授权后再启用
开启后完全断网	strict-route、DNS 劫持、默认路由、其他 VPN	先关闭 strict-route 和 dns-hijack，恢复最小配置
网页能开但部分应用不能用	应用是否遵守系统代理、规则是否命中、UDP 支持	查看连接日志，不要仅凭浏览器结果判断
DNS 解析失败	53 端口占用、私人 DNS、系统 DNS、DNS 配置	暂时移除 dns-hijack，确认基础连接后再加回
局域网设备无法访问	strict-route、局域网网段、企业 VPN 和防火墙	关闭 strict-route，核对局域网排除路由
订阅更新后 TUN 消失	订阅是否覆盖整个配置、客户端是否支持覆写	使用客户端的覆写/补丁功能，或把 TUN 配置放在不会被订阅替换的位置

排查时一次只改一个变量，并在每次修改后记录“配置、日志、网卡、路由、DNS、连接结果”。这样可以区分是 TUN 没启动、路由没有接管、DNS 失败，还是规则将请求分配到了 DIRECT。

如何关闭 TUN 并恢复网络

在客户端关闭 TUN 开关，等待网络状态恢复。
如果仍然无法联网，切换回备份配置并完全退出 Mihomo，再重新连接当前 Wi-Fi 或有线网络。
Windows 检查是否残留虚拟网卡或服务；macOS 检查网络扩展或 VPN 状态；Linux 检查路由表、服务状态和防火墙规则；Android 关闭对应 VPN 后检查系统私人 DNS 和其他 VPN。
恢复后不要立即重新启用全部高级参数。先只保留 enable、stack、auto-route 和 auto-detect-interface，验证成功后再逐项增加 DNS 劫持、应用筛选或排除路由。

需要注意，订阅更新可能覆盖手动编辑的 YAML。更稳妥的做法是使用客户端提供的覆写、补丁或配置合并功能，并在更新后检查实际运行配置，而不是只看本地文件。

结论：哪种配置方式适合你

如果你只需要让浏览器或少数支持代理的应用联网，系统代理或 Mixed 端口更容易回滚；如果你需要覆盖命令行、部分不支持代理设置的应用，或者希望由系统路由统一接管流量，可以尝试 TUN。第一次配置时，最重要的是使用最小字段、保留备份、确认权限，并按“配置加载 → 日志 → 虚拟网卡 → 路由 → DNS → 规则命中 → 实际连接”的顺序验证。

本文是第三方使用指南，不代表 Mihomo 或具体客户端官方；客户端菜单、内核版本和字段支持请以当前项目文档及客户端页面为准。

常见问题

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

系统代理通常只对遵守系统代理设置的应用有效；TUN 通过虚拟网卡和系统路由接收流量，覆盖范围可能更广。TUN 仍然受规则、DNS、权限和应用协议影响，不能理解为所有连接都会自动使用同一个节点。

TUN 开启后连接显示 DIRECT，是不是 TUN 失效？

不一定。TUN 负责接收和转发流量，最终走代理还是直连由规则决定。应先查看连接日志和规则命中结果；如果连接进入 Mihomo 但命中 DIRECT，优先检查规则，而不是立即修改协议栈或 MTU。

Mihomo TUN 开启后完全断网怎么办？

先关闭 TUN 并恢复备份配置，然后按顺序排查权限、strict-route、dns-hijack、53 端口占用、默认路由和其他 VPN。重新测试时只保留 enable、stack、auto-route 和 auto-detect-interface，确认基础连接后再逐个增加高级字段。

Mihomo TUN 的 stack 选 system、gvisor 还是 mixed？

没有适用于所有设备的固定答案。建议先使用 system 作为基线；若某个平台、应用或防火墙环境出现兼容问题，再一次只修改 stack 测试 gvisor 或 mixed，并记录日志和连接差异。具体可用值以当前版本官方文档为准。

订阅更新后，为什么 TUN 配置会消失？

如果客户端用订阅内容替换了完整配置，手动增加的 tun 区块可能被覆盖。应使用客户端提供的覆写、补丁或合并配置功能，并在更新后检查实际运行配置；如果客户端不支持这些功能，只能保留备份并重新核对配置。