Mihomo TUN 模式 Windows 配置详解：从驱动安装到排错（2026）
Windows 上开 Mihomo TUN 模式最容易卡在 Wintun 驱动加载、管理员权限和路由表冲突三步。本文按驱动检查、YAML 参数逐项拆解、三种模式对比、常见错误码和回滚方式组织，每项都给了设备管理器或命令行验证方法。把准备材料、配置差异和上线后的收尾动作放在一起，减少照搬旧教程带来的误判。
操作步骤速查
确认 Mihomo 内核版本和权限
打开 Clash Verge Rev，进入 Settings → Verge → Mihomo Core 或内核设置页面，查看当前 Mihomo 内核版本号。建议使用 v1.18.0 及以上版本，较旧版本对 Wintun 驱动的兼容性有差异。如果使用 Mihomo Party，同样在设置→内核中找到版本信息。确认后右键点客户端图标，选择「以管理员身份运行」——TUN 模式需要向系统注册虚拟网卡驱动，没有管理员权限这一步直接失败，日志通常会报 'cannot create TUN device' 或 'permission denied'。
预期结果：Mihomo 内核版本号显示为 v1.18.x 或更高。程序以管理员身份启动后，Windows 会弹出 UAC 确认框，点「是」之后程序的主窗口正常显示，标题栏没有显示受限模式的提示。
如果每次开机都要手动右键→管理员运行很麻烦，可以在 Mihomo 客户端的设置中开启「开机启动」和「以管理员身份运行」。Clash Verge Rev 和 Mihomo Party 都支持服务模式（Service Mode），安装服务后系统启动时自动以管理员权限运行内核，不需要每次手动确认 UAC。
检查 Wintun 虚拟网卡是否已安装
右键点 Windows 开始菜单→设备管理器→展开「网络适配器」分类，在列表里找名字中带「Wintun」或「Mihomo」的项目。客户端第一次开启 TUN 时会自动调用 Wintun 驱动创建这个虚拟网卡。如果设备管理器里看不到它，切回客户端，打开 TUN 模式开关后再刷新设备管理器（点菜单栏「操作」→「扫描检测硬件改动」）。如果刷新后仍然没有，说明 Wintun 驱动没有正确加载，往下翻到「常见错误」那节排查。
预期结果：设备管理器的网络适配器列表中，出现一个名为「Wintun Userspace Tunnel」或「Mihomo Tunnel」的设备。设备旁边的图标正常（无黄色感叹号），右键点属性→驱动程序页能看到驱动提供商为「WireGuard LLC」或「Mihomo」。
设备管理器里可以同时看到多张虚拟网卡——除了 Wintun 还可能看到 VMware、VirtualBox、Tailscale 等创建的网卡。别删错了。Wintun 的网卡描述通常以 'Wintun' 或 'Mihomo' 开头，很好辨认。
编写或编辑 TUN 配置段 YAML
打开 Mihomo 的配置文件（在 Clash Verge Rev 中：Profiles → 右键当前激活的订阅→「编辑」或「Edit」；在 Mihomo Party 中：配置→选中当前配置→编辑）。在 YAML 文件中找到或新增 `tun:` 配置段。如果你用的是服务商订阅且不允许手动编辑，需要先在 Profiles 中新建一个本地配置（From Local），把订阅内容粘贴进去再编辑。下面一节有完整的 TUN 配置示例。
预期结果：YAML 文件中出现 `tun:` 键，且下方缩进正确包含 enable、stack、dns-hijack、auto-route 等参数。保存后客户端不会提示 YAML 语法错误（如有报错，检查缩进是否用了 Tab 而不是空格——YAML 只能用空格缩进）。
如果订阅配置是远程拉取的（From URL），直接在客户端里编辑后，下次自动更新可能会覆盖你的修改。解决办法：复制一份到本地编辑，或者把订阅链接改为手动更新（Update Interval 设 0），再在编辑器中改 TUN 部分。
开启 TUN 模式并验证流量接管
回到客户端主界面（Overview），找到「TUN 模式」开关，点开变为绿色。此时 Mihomo 内核会执行以下操作：调用 Wintun 创建/激活虚拟网卡、写入系统路由表（添加指向虚拟网卡的默认路由或分流路由）、启动 DNS 劫持（如果配置了 dns-hijack）。切换到 Logs 页面，搜索 'TUN' 关键词，确认日志中没有 error 级别的报错。打开命令提示符（cmd），输入 `route print -4` 查看 IPv4 路由表，确认有路由条目指向 Mihomo 虚拟网卡的接口 IP（如 172.19.0.x）。用浏览器访问 `https://api.ipify.org`，确认显示的 IP 已变为代理节点的出口 IP。
预期结果：TUN 开关变绿且不自动回弹（回弹说明驱动创建失败）。Logs 页面中搜索 'TUN' 能看到 'TUN device started' 或类似的启动成功日志，无红色 error 行。命令提示符的 route print 输出中，目的网络 0.0.0.0 的跃点数不再是物理网卡的最低值，有部分路由指向虚拟网卡的接口地址。浏览器访问 ipify.org 返回代理节点的 IP。
TUN 开关点开后如果马上自动弹回灰色，说明驱动创建失败。90% 的情况是没以管理员身份运行，剩下 10% 是 Wintun 驱动损坏或其他 VPN 软件占用了驱动。先去设备管理器确认虚拟网卡状态，再看常见错误那节。
你打开 Clash Verge Rev 或 Mihomo Party 的系统代理，浏览器、Telegram 这些支持代理设置的程序都能正常工作。然后你试着玩了一把游戏，发现延迟还是直连的；打开命令行跑 curl api.github.com，也返回了连接超时。
这就是系统代理的天花板——它只对主动读取 Windows 代理设置的程序生效。游戏、命令行工具、Windows Store 下载的 UWP 应用、Docker Desktop、WSL 里的 Linux 子系统，这些程序完全不吃系统代理那一套。
Mihomo 的 TUN 模式就是干这个的：在 Windows 网络栈里插入一张虚拟网卡，把所有流量（TCP、UDP、ICMP）引到这张网卡上，由 Mihomo 内核决定哪些走代理、哪些直连。不依赖程序是否支持代理设置，不要求每个软件单独配置。
但这套东西在 Windows 上的实现依赖一个叫 Wintun 的驱动（来自 WireGuard 项目），从驱动加载到路由表写入，中间有四五个容易翻车的节点。这篇文章按配置顺序把每个参数和每个可能的报错拆开。
Windows 上跑 TUN 和 Linux/macOS 有什么不一样
Linux 有 /dev/net/tun，macOS 有 utun，都是操作系统内置的虚拟网络接口。Windows 没有这层原生能力，必须靠第三方驱动——Mihomo 用的就是 Wintun。
Wintun 做的事情很简单：注册一个内核级虚拟网卡，把从 IP 层发来的包交给用户态程序（Mihomo 内核）处理。问题在于 Windows 对内核驱动加载有三重限制：
- 管理员权限。加载任何内核驱动都需要管理员 token，少这一步 TUN 直接创建失败。
- 驱动签名强制。Windows 10/11 默认要求内核驱动有数字签名。Wintun 有 WireGuard LLC 的有效签名，但部分企业 IT 策略会额外拦截非白名单驱动。
- 杀毒软件和 Defender。Wintun 的行为签名（创建虚拟网卡、注入路由表）容易触发启发式检测，Defender 可能静默拦截驱动加载。
这三重限制意味着：同一份 TUN 配置在个人 Windows 11 上跑得好好的，换到公司的 Windows 10 加入域的机器上就可能完全打不开。这篇文章的排错部分会逐一覆盖这三种情况。
TUN 配置参数：每个参数到底控制什么
Mihomo 的 TUN 配置在 YAML 顶层 tun: 键下，以下是核心参数：
| 参数 | 控制什么 | Windows 上的推荐值 | 不推荐的后果 |
|---|---|---|---|
enable | TUN 模式总开关 | true | 无 TUN，等于白写这一节 |
stack | 网络栈实现方式：system(Wintun)/gvisor(用户态)/mixed(TCP 进 system + UDP 进 gvisor) | mixed | system 性能最高但 UDP 可能触发某些游戏反作弊；gvisor 纯用户态但带宽掉 20-30% |
device | 虚拟网卡在系统中的显示名称 | Mihomo | 不设就自动生成，排查路由表时不好辨认 |
dns-hijack | 劫持哪些地址的 53 端口 DNS 查询，写入 Mihomo 的 DNS 模块处理 | [any:53] | 不设的话部分程序会用硬编码 DNS 服务器绕开代理 DNS，导致 CDN 解析到国内节点 |
auto-route | 是否自动设置路由表让流量进入 TUN | true | false 等于 TUN 网卡创建了但没有路由指向它，流量不进 TUN。手工写路由表出错率极高 |
auto-detect-interface | 是否自动检测默认物理网卡并排除其路由，防止回环 | true | false 可能导致 TUN 收到的包又经由物理网卡发给 TUN 自身，造成流量死循环 |
strict-route | 路由表策略是否严格按规则执行，不自动添加兜底路由 | false | true 对高级用户有用（配合手工路由），普通用户开 true 容易导致部分流量被错误丢弃 |
mtu | 虚拟网卡的最大传输单元（字节） | 1500 | 设太小（如 1280）分片过多降低吞吐；设太大（如 9000）遇到不支持巨型帧的路由器会丢包 |
inet4-address | TUN 虚拟网卡的 IPv4 地址/子网 | 172.19.0.1/30 | 不需要改，除非你家里或办公室局域网恰好也用这个地址段。冲突时换一个私有地址段如 10.99.0.1/30 |
endpoint-independent-nat | UDP NAT 类型：是否启用端点无关 NAT（Full Cone） | true | 游戏联机和 P2P 传输关闭这个参数会导致 NAT 类型变为 Restricted Cone，匹配成功率显著下降 |
YAML 配置示例
下面是一份在 Windows 11 + Clash Verge Rev + Mihomo v1.18+ 上验证可用的 TUN 配置段：
tun:
enable: true
stack: mixed
device: Mihomo
dns-hijack:
- any:53
auto-route: true
auto-detect-interface: true
strict-route: false
mtu: 1500
inet4-address: 172.19.0.1/30
endpoint-independent-nat: true这段配置保存后，客户端开启 TUN 开关即可生效。如果使用的是 Mihomo Party，界面里有一个「TUN 配置」面板可以直接填写以上参数，不需要手动编辑 YAML。但建议先搞清楚每个参数的含义再填——盲目照抄容易在遇到网络环境差异时不知道怎么调。
怎么确认 TUN 驱动真的装好了
光看客户端开关变绿不够。TUN 开关显示绿色只说明 Mihomo 内核成功启动了 TUN 逻辑，不代表驱动加载完成、路由表写入正确。三步验证：
第一步：设备管理器看网卡。 右键开始菜单→设备管理器→展开「网络适配器」。应该能看到名称里带 Wintun 的条目，图标正常无黄色感叹号。双击进去→驱动程序页，提供商为 WireGuard LLC，驱动日期应该在你安装或更新 Mihomo 内核的时间附近。
如果设备管理器里完全没有 Wintun 相关条目：客户端第一次开启 TUN 时驱动没有加载成功。先到 Windows 安全中心的保护历史里看有没有 Wintun 的拦截记录。如果没有拦截记录但驱动仍然不出现，以管理员身份运行客户端，手动开启一次 TUN 再看设备管理器。
第二步：route print 看路由表。 以管理员身份打开 cmd，执行 route print -4。在输出顶部附近找目标网络为 0.0.0.0 且跃点数不是物理网卡最低值的条目，或目标为 198.18.0.0 网段指向 TUN 网卡接口 IP（通常是 172.19.0.x）的条目。有这些说明 auto-route 正常工作，流量确实被引向 TUN 网卡了。
第三步：nslookup 看 DNS 劫持。 在 cmd 里跑 nslookup google.com。如果返回的 IP 不是你家宽带 DNS 通常会解析的结果，说明 dns-hijack 成功把 DNS 请求截到了 Mihomo 的 DNS 模块里。再打开 Mihomo 客户端的 Logs 页面，过滤 DNS，应该能看到这条 google.com 的查询记录。
三步全部通过，TUN 才算真正跑起来了。缺任何一步，回到上面参数表里找对应的参数看是不是设错了。
系统代理、TUN、混合模式：什么时候该用哪个
Windows 上 Mihomo 有三种流量接管方式，它们的区别不只是「TUN 更底层」这么一句话能说清：
| 模式 | 接管层 | 覆盖范围 | 需要管理员 | 适用场景 |
|---|---|---|---|---|
| 系统代理 | 应用层（HTTP/HTTPS/SOCKS5 代理） | 只有读取系统代理设置的程序，对 UWP、命令行、游戏无效 | 不需要 | 日常浏览器上网、聊天软件、轻量使用 |
| TUN | 网络层（IP 包） | 整个系统的所有 TCP/UDP/ICMP 流量 | 必须 | 游戏加速、命令行工具、Docker、WSL、UWP 应用，追求无死角覆盖 |
| 混合（系统代理 + TUN 同时开） | 应用层 + 网络层 | 所有流量全部覆盖 | 必须 | 很少有必要。个别场景下某些浏览器插件只认系统代理设置，同时开可以兼容，但日常没有收益 |
一个常见误判是把「开了系统代理但是某些程序没走代理」当成是规则写错了。先确认那个程序是否支持系统代理：所有 UWP 应用（Microsoft Store 下载的）、cmd/PowerShell、WSL、Docker CLI 都不吃系统代理。如果这些程序需要走代理，只能上 TUN。
另一个误判是「开了 TUN 所以所有流量一定走代理」。TUN 只是把流量引到虚拟网卡上，最终走代理还是直连，取决于你的分流规则。TUN 模式里如果没有写 DIRECT 规则或放行规则，默认行为取决于内核版本和配置——有可能全部走代理，也有可能在规则缺失时直连。上 TUN 之前建议先确认自己的规则集覆盖了常用国内网站的直连规则。
常见错误：从日志到修复
TUN 模式出问题的时候，打开 Logs 页面搜 TUN 或 error，通常能直接看到根因。以下是最常见的四个错误和对应的修复路径：
| 错误日志关键词 | 原因 | 修复步骤 |
|---|---|---|
cannot create TUN device 或 permission denied | 没有管理员权限 | 右键客户端→以管理员身份运行；长期使用建议在客户端设置里开启 Service Mode |
Wintun driver not found 或 driver load failed | Wintun 驱动未安装、被 Defender 拦截、或注册表残留 | 1) 安全中心→保护历史→允许 Wintun；2) 管理员 cmd 执行 sc delete wintun 清残留→重启客户端重试 |
CreateAdapter: The system cannot find the path specified (0x00000003) | Wintun 驱动注册表条目损坏或过时 | 管理员 cmd 依次执行 sc delete wintun → net stop <客户端服务名> → net start <客户端服务名>，让客户端重新注册 Wintun 驱动 |
route conflict 或 TUN 开启后断网 | 路由表与已有 VPN（公司 VPN、WireGuard、Tailscale）冲突 | 暂时关闭其他 VPN 软件确认是否是冲突；长期方案：在 TUN 配置中确保 auto-detect-interface: true，或在规则中把公司内网 IP 段设为 DIRECT |
| TUN 开关反复回弹（点开→马上自动关闭） | Wintun 初始化失败，最常见的原因是被安全软件拦截 | 用 Process Monitor 抓一下 mihomo.exe 的驱动加载行为，看是否有 ACCESS DENIED；如果有，在 Defender 或第三方杀软的排除项里加入 Mihomo 的 exe 路径 |
如果所有错误都对不上
还有一个隐性故障源：其他虚拟网卡驱动的残留。深信服 EasyConnect、旧版 V2RayN、ZeroTier、OpenVPN 的 TAP 驱动卸载不干净，会在 Windows 网络栈里留下冲突的筛选器（filter driver），导致 Wintun 加载后无法绑定 IP 协议。
排查方法：以管理员身份打开 cmd，执行 netsh winsock show catalog，在输出里找非微软的 Layered Service Provider (LSP) 条目。如果看到不属于当前在用软件的 LSP（比如你要找的是 Wintun，却看到了 Sangfor 或 ZeroTier 的注册项），说明旧 VPN 的残留驱动在干扰。可以用 netsh winsock reset 重置整个 Winsock 目录——这之后所有 VPN 软件都需要重新安装，但能解决 90% 的驱动冲突。
想退回去怎么办
如果你试了一圈 TUN 发现不稳定、想回到只开系统代理的状态：
- 关掉 TUN 开关。Overview 页面的 TUN 开关拨到关闭位置，Mihomo 内核会自动删除虚拟网卡的路由条目。大部分情况下关掉就能恢复直连网络。
- 如果关掉后网络断断续续。以管理员身份开 cmd，执行
netsh winsock reset && netsh int ip reset然后重启电脑。这会把 Windows 网络栈完全刷新，所有 VPN 软件配置清零。 - 想彻底删掉 Wintun 驱动。设备管理器→网络适配器→右键 Wintun/Mihomo 网卡→卸载设备→勾选「删除此设备的驱动程序软件」。下次再开 TUN 时客户端会重新从它的资源包里提取 Wintun 驱动并安装。
- 连客户端都想清理。卸载 Clash Verge Rev 或 Mihomo Party 后，手动删除配置目录：Clash Verge Rev 在
%USERPROFILE%\.config\clash-verge-rev\，Mihomo Party 在%APPDATA%\mihomo-party\。删完之后所有回滚都干净了。
TUN 模式的配置和排错确实比系统代理多几层复杂度——驱动、路由表、DNS 劫持每个环节都要对。但一旦跑通，整个系统的网络流量都会被统一接管，不用再纠结「这个程序支持代理吗」。如果你手里的订阅节点在 TUN 模式下带宽跑不上去，一份兼容 Mihomo 全栈的 多格式测试订阅源 能减少协议层面的性能损耗。
本文基于 Mihomo v1.18+ 内核和 Windows 11 23H2 编写，设备管理器和 cmd 路径对应 2026 年 5 月的系统版本。Wintun 驱动的具体行为可能因 Mihomo 内核版本和 Windows 更新而变化，排查前先确认 TUN 参数与 Mihomo 官方 config 文档 的描述一致。
相关阅读
常见问题
- TUN 模式开启后所有流量都走代理了，能不能只让部分程序走 TUN？
- 可以，在 TUN 配置中配合规则集（rules）实现进程级别的分流。Mihomo 的 rules 支持 PROCESS-NAME 和 AND/OR 逻辑匹配，例如 `- PROCESS-NAME,Telegram.exe,Proxy` 让 Telegram 走代理，其余走直连。但这需要把路由模式从全接管改成按规则路由。
- stack 三个选项 system、gvisor、mixed 到底怎么选？
- system 用 Wintun 驱动，性能最高但需要管理员权限，部分杀毒软件会拦截；gvisor 纯用户态实现、不需要驱动，但 TCP/UDP 性能都会下降 20-30%；mixed 让 TCP 走 system 栈、UDP 走 gvisor 栈，解决了部分游戏反作弊系统检测虚拟网卡的问题，是目前 Windows 上的推荐默认值。
- 开启 TUN 后其他 VPN 或公司内网 VPN 会受影响吗？
- 会，TUN 模式会写路由表，与公司 VPN（如 OpenVPN、AnyConnect）的路由条目可能冲突。如果需要同时使用，在 Mihomo 的规则中把公司内网 IP 段设为 DIRECT 直连，或在 TUN 配置中把 `auto-route` 和 `auto-detect-interface` 同时打开，让 Mihomo 自动避开其他 VPN 的网卡。不保证 100% 兼容。
- Wintun 驱动会被 Windows Defender 误杀吗？
- 确实会。Windows Defender 有时把 Wintun 驱动误判为潜在有害程序并静默拦截。如果 TUN 开关反复回弹，先打开 Windows 安全中心 → 病毒和威胁防护 → 保护历史记录，查找是否有 'Wintun' 相关的拦截记录。如果有，点「允许」。也可以把 Mihomo 的安装目录和配置目录加入 Defender 的排除列表。
- TUN 模式和系统代理可以同时开吗？
- 技术上可以，但没有必要。TUN 已经在网络层接管了所有流量，系统代理只在应用层对支持代理的程序生效。同时开启不会冲突，但也不会带来额外收益。如果同一台电脑上其他软件依赖系统代理设置（如某些浏览器插件），留着系统代理开关也无妨，但不需要特意同时开。
来源与时间
本文最后查看时间：2026-05-29。操作路径会随客户端版本变化，遇到按钮名称不一致时，优先按同义菜单和官方文档查看。