Mihomo TUN 开了却没接管流量？Windows 配置与验证方法

更新于 2026-11-14 · 3i.mom

简答：如果 Windows 上 Mihomo 的 TUN 开关显示开启，但终端、游戏或其他不读取系统代理的应用仍未被接管，先不要反复切换协议栈。判定 TUN 真正生效，至少要同时看到虚拟网卡处于 Up、路由表发生对应变化、Mihomo 日志出现连接记录，并用绕过代理设置的 IPv4/IPv6 请求完成对照验证。

定义：Mihomo TUN 模式是通过虚拟网卡和系统路由接管流量的方式，覆盖范围通常比只修改 Windows 系统代理更广，但开关显示开启不等于应用流量已经进入 Mihomo。

先试这一步：备份后使用最小 TUN 配置

本文是第三方使用指南，范围限定为 Windows 上 Mihomo 核心的 TUN 配置与验证。本文核对日期：2026-11-14。

最快判断标准：虚拟网卡为 Up，路由表出现与 TUN 相关的变化，日志能看到目标连接，并且使用不读取代理设置的请求进行 IPv4 与 IPv6 对照后，结果符合你的规则预期。只看到客户端开关开启，不能单独证明 TUN 已经接管流量。

Mihomo 官方文档建议普通用户优先使用顶层 tun 配置，而不是高级的 listeners 形式。官方当前列出的 stack 值包括 system、gvisor、mixed 和 mips，并注明默认值为 mips、无使用问题时可继续使用。字段和取值请以mihomo TUN 官方字段文档为准。

先备份现有配置，再在 YAML 顶层合并下面的基础片段。若文件已有 tun:，只修改其中字段，不要创建第二个同名顶层字段：

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

这个示例没有强行加入 dns-mode。官方文档虽然列出了顶层 TUN 的 dns-mode，但不同客户端可能把配置字段重新包装；首次排障时先保持默认行为，确认基础 TUN 生效后再单独测试 DNS。Windows 使用 dns-mode: hijack 时，官方文档要求配合 strict-route；Windows 仍不能自动劫持发往局域网的 DNS 请求。

Windows 配置与开启：7 步完成基础验证

确认配置文件和内核，再创建备份。
先在当前客户端中确认使用的是 Mihomo 核心、当前激活的配置文件和日志位置。不要直接覆盖原文件。下面命令中的路径必须替换成你已经确认的实际路径：
```
New-Item -ItemType Directory -Force "$env:USERPROFILE\Desktop\mihomo-backup"
Copy-Item "C:\path\to\config.yaml" "$env:USERPROFILE\Desktop\mihomo-backup\config-2026-11-14.yaml"
```
预期结果是桌面出现 mihomo-backup\config-2026-11-14.yaml。如果出现 Cannot find path，说明配置路径不对，应回到客户端的配置目录或“打开配置目录”功能确认，不要继续修改。
检查当前是否有其他 VPN、虚拟网卡或网络过滤软件。
先记录当前适配器：
```
Get-NetAdapter | Sort-Object ifIndex | Format-Table ifIndex,Name,Status,MacAddress,LinkSpeed
```
记录正在使用的公司 VPN、虚拟机网络、其他 VPN 和安全软件。首次测试时可以临时退出冲突软件，但不要删除系统适配器。若退出某软件后问题消失，再逐个恢复并记录哪个组件改变了路由或防火墙。
以管理员权限启动，或使用客户端的服务模式。
TUN 需要创建虚拟网卡并设置系统路由。普通权限失败时，常见现象是开关回弹、没有虚拟适配器或日志出现 permission denied。若直接运行 Mihomo，必须明确指定工作目录和配置文件，避免加载默认目录中的其他配置：
```
Start-Process "C:\path\to\mihomo.exe" -ArgumentList "-d","C:\path\to\mihomo-data","-f","C:\path\to\config.yaml" -Verb RunAs
```
实际参数格式以当前 Mihomo 构建支持的命令行帮助为准，可先执行：
```
& "C:\path\to\mihomo.exe" -h
```
如果使用带图形界面的客户端，应优先使用客户端提供的“服务模式”或 TUN 授权流程，不要同时手动启动第二个 Mihomo 内核。以 MetaCubeXD 为例，官方项目说明桌面 TUN 首次启用会请求管理员授权，Windows helper 会作为自动启动服务运行；其说明还提到 Windows 构建会随内核提供 wintun.dll。这部分仅适用于该项目的桌面构建，其他客户端仍应以自身说明为准。参考MetaCubeX 官方面板项目说明。
保存 YAML 并先做配置校验。
保存后重载或重启 Mihomo。若出现 unknown field，先检查字段是否位于顶层 tun，并确认当前核心确实是 Mihomo；不要把高级 listeners 下的字段随意复制到顶层。若客户端或核心提供配置校验功能，先通过校验再重启。YAML 同级字段使用两个空格缩进，不能把 enable 写成顶层字段。
如果出现 yaml: unmarshal errors、mapping values are not allowed here 或类似解析错误，优先检查缩进、冒号、重复的 tun: 和不可见字符。回滚时把备份文件复制回原路径，再重新加载配置。
检查虚拟网卡是否出现并处于 Up。
按 Win+R 输入：
```
ncpa.cpl
```
也可以使用 PowerShell：
```
Get-NetAdapter | Sort-Object ifIndex | Format-Table ifIndex,Name,Status,MacAddress,LinkSpeed
```
预期结果是出现由客户端创建或使用的虚拟适配器，状态通常为 Up。适配器名称不一定固定，不能只按“某个名称”判断。没有虚拟适配器时，优先查看管理员授权、客户端服务状态和 Mihomo 日志。
检查路由表和日志，不要只看开关。
先保存 TUN 开启前后的路由输出：
```
route print > "$env:USERPROFILE\Desktop\route-after-tun.txt"
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric,DestinationPrefix | Format-Table ifIndex,DestinationPrefix,NextHop,RouteMetric
```
预期不是某一个固定数字，而是启用 TUN 后与虚拟接口有关的路由或接口关系发生变化，并且日志没有持续出现路由创建失败、权限失败或 DNS 初始化失败。Windows 多网卡、公司 VPN、虚拟机网卡会改变结果，所以应比较开启前后的接口编号、默认路由和相关目标路由。
日志中应重点查找 TUN 初始化成功、路由设置成功、连接建立和 DNS 请求等信息。不要把不同客户端的界面提示当成 Mihomo 固定文案。
用绕过代理设置、但仍受 TUN 路由影响的请求完成验证。
--noproxy "*" 的含义是让 curl 不读取代理设置；它不会绕过 TUN 的系统路由。TUN 开启时，请求仍可能被虚拟网卡接管，这正是测试目标。分别记录关闭和开启 TUN 后的结果：
```
curl.exe -4 --noproxy "*" https://api.ipify.org
curl.exe -6 --noproxy "*" https://api64.ipify.org
```
同时在 Mihomo 日志或控制面板的连接列表中查找对应请求。通过标准应至少包括：请求能够完成；Mihomo 有对应连接记录；IPv4 和 IPv6 路径没有出现与你的规则预期相反的绕行。出口 IP 变化本身不能单独证明 TUN 成功，因为节点、规则、IPv4/IPv6 和目标服务都可能造成差异。
如果出现 Could not resolve host，先排查 DNS；如果出现 Failed to connect 或超时，分别区分本机直连、节点连接、路由和防火墙问题。IPv6 请求失败不一定代表 IPv4 TUN 失败，但说明需要单独检查 IPv6 是否启用、是否存在 IPv6 路由以及规则是否覆盖 IPv6。

五层验证速查表：开关开启不等于流量接管

Windows 上 Mihomo TUN 的分层验证标准

验证层级	检查位置或命令	通过标准	不通过先查什么
配置层	YAML、客户端配置校验	`tun.enable` 被接受，没有解析错误或 `unknown field`	缩进、重复字段、字段层级、核心版本差异
权限层	管理员启动、UAC、服务状态	没有 `permission denied`，开关不回弹	管理员授权、服务模式、其他内核进程
接口层	`Get-NetAdapter`、`ncpa.cpl`	虚拟适配器存在且状态为 `Up`	helper、虚拟网卡、杀毒软件或 VPN 冲突
路由与日志层	`route print`、Mihomo 日志	路由关系发生变化，日志出现 TUN 初始化和连接记录	`auto-route`、多网卡、公司 VPN、防火墙
真实流量层	`curl.exe -4/-6 --noproxy "*"`、控制面板连接列表	请求完成，日志或连接列表能对应到目标流量，IPv4/IPv6 结果符合规则预期	DNS、节点、规则、IPv6 路由和应用自身网络行为

如果你使用 MetaCubeXD 这类带控制面板的桌面构建，还可以在连接或数据观察页面查看实时连接记录。面板只能帮助观察连接，不能替代虚拟网卡、路由和实际应用测试。其官方项目将面板、Mihomo 后端和桌面 TUN 辅助组件区分说明，具体能力取决于当前连接的运行时。

字段选择与 DNS 排查：先少改，再逐项增加

字段	官方文档说明	首次配置建议
`enable`	启用或关闭 TUN	设为 `true`
`stack`	可用值包括 `system`、`gvisor`、`mixed`、`mips`；官方当前文档注明默认值为 `mips`	先保留官方默认或当前配置，不要照抄旧教程强行更换
`auto-route`	自动设置全局路由，将全局流量导入 TUN	需要系统级接管时设为 `true`
`auto-detect-interface`	自动检测出站网卡；多出口设备建议手动指定	单网卡先保持 `true`
`strict-route`	启用严格路由；Windows 会增加用于阻止普通多宿主 DNS 泄漏的防火墙规则	需要 DNS hijack 时保留为 `true`，出现 VirtualBox 等异常再排查
`dns-mode`	可选 `disabled`、`native`、`hijack`；`hijack` 在 Windows 上需要 `strict-route`	基础 TUN 未验证前先不额外改动
`dns-hijack`	将匹配的 DNS 连接导入内部 DNS 模块；Windows 不能自动劫持发往局域网的 DNS	只在确认当前 DNS 方案和字段位置后添加
`mtu`	影响极端条件下的传输表现，普通用户可保持默认	出现可复现的分片或丢包现象后再单独测试

官方文档还提醒，顶层 TUN 配置适合大多数用户，高级 TUN listener 适合特殊场景。不要把 listeners 下的配置片段与顶层 tun 混合使用。需要核对完整字段归属时，参考mihomo 入站配置说明和TUN Listener 文档。

常见故障与完整回滚方法

开关开启后立即关闭：先停止 TUN，恢复备份配置，再以管理员权限启动。重点检查 permission denied、重复的 tun:、字段缩进和是否同时运行了多个核心进程。
虚拟网卡存在但网页打不开：执行 curl.exe -4 --noproxy "*" https://api.ipify.org，再查看日志是否有对应连接。没有连接记录时先查路由和核心状态；有记录但失败时再查规则、节点和 DNS。
IPv4 正常但 IPv6 失败或绕过：执行 curl.exe -6 --noproxy "*" https://api64.ipify.org，再检查 Windows IPv6 路由和 Mihomo 的 IPv6 配置。不要仅凭 IPv4 成功就判断双栈流量都已接管。
开启 TUN 后局域网或 VirtualBox 异常：官方文档说明 Windows 的 strict-route 在特定场景可能影响 VirtualBox 等应用。先关闭 TUN 确认是否恢复，再按实际网段配置排除地址；不要一次删除所有路由。
DNS 解析失败：执行 Resolve-DnsName example.com，记录返回的 DNS 服务器和错误信息。DNS name does not exist 可能是域名或 DNS 响应问题，不等于 TUN 必然失败；超时则重点检查 dns-mode、strict-route、防火墙和其他 VPN。
需要撤销本次修改：先关闭 TUN，再将备份复制回原配置路径，然后重新加载核心：

Copy-Item "$env:USERPROFILE\Desktop\mihomo-backup\config-2026-11-14.yaml" "C:\path\to\config.yaml" -Force

恢复后执行：

route print
Get-NetAdapter | Sort-Object ifIndex | Format-Table ifIndex,Name,Status

预期是 TUN 相关路由不再继续接管流量，虚拟适配器可能仍保留，也可能由客户端服务继续管理。若虚拟适配器仍在但网络已恢复，不要直接删除；先正常退出客户端或停止其服务，再按当前客户端提供的“恢复网络”功能处理。若路由仍残留，重启客户端或 Windows 前先记录 route print 输出，并确认没有其他 VPN 正在使用同一接口。

给图形界面用户的说明

如果你不是直接编辑 YAML，而是使用图形客户端，优先在客户端的 TUN 开关、服务模式或虚拟网卡设置中完成授权，再按照本文的接口、路由、日志和真实流量四类命令验证。不同客户端的菜单名称和服务机制可能随版本变化，无法从 Mihomo 核心字段文档固定出一条通用菜单路径。

Clash Verge Rev 的具体开关和断网恢复可参考站内的Clash Verge Rev TUN 模式开启与验证；不要把该客户端的界面路径直接当作所有 Mihomo 图形客户端的通用路径。

常见问题

Mihomo TUN 开启后，还需要开启 Windows 系统代理吗？

不一定。系统代理修改的是当前用户的代理设置，TUN 则通过虚拟网卡和路由接管流量。验证时应使用不读取代理设置的请求或应用，并查看 Mihomo 日志；是否同时开启系统代理，要以客户端规则和实际应用测试结果为准。

为什么最小配置没有直接加入 dns-mode: hijack？

因为首次排障应先验证基础 TUN、虚拟网卡和路由，避免同时修改多个变量。官方文档确实列出顶层 TUN 的 dns-mode，并说明 Windows 使用 hijack 时需要 strict-route；但不同客户端可能重新包装字段，所以建议确认当前配置层级后再单独测试 DNS。

stack: mips 是不是写错了？

根据当前 mihomo 官方 TUN 文档，mips 是列出的有效协议栈取值，文档同时将 system、gvisor、mixed、mips 列为可用值，并注明默认值为 mips。若当前内核提示 unknown field 或不支持该值，应以实际内核校验结果和对应版本文档为准，不要强行套用示例。

只看到虚拟网卡，就能证明 TUN 成功了吗？

不能。虚拟网卡只能说明接口创建或启用，不能证明应用流量已进入 Mihomo。至少还要结合路由表、核心日志，以及 curl.exe 使用 --noproxy "*" 发起的 IPv4/IPv6 实际请求进行判断。

Mihomo TUN 开启后断网，应该先删掉虚拟网卡吗？

不建议直接删除。先关闭 TUN，正常退出客户端或使用客户端的网络恢复功能，再检查 route print 是否仍有残留路由。若问题仍在，恢复配置备份并重启客户端；虚拟网卡由服务或客户端管理时，应按其卸载或恢复流程处理。