TUN 模式是什么:虚拟网卡与三层接管
TUN 是操作系统提供的虚拟网络设备,工作在网络层(第三层),进出它的都是标准 IP 包。开启 TUN 模式后,客户端按顺序做三件事:
- 向系统注册一张虚拟网卡。Windows 上多显示为 Mihomo 或 utun 字样的适配器,macOS 与 Linux 上则是新增的 utun 设备。
- 改写路由表,把默认路由指向这张网卡,整机发出的 IP 包先落到内核手里。
- 内核(mihomo)在网卡上读包,解析目标域名与端口,按配置里的规则决定直连还是交给节点,最后从真实网卡发出。
关键在层级。系统代理是应用层协议,应用必须主动读取并遵守系统设置才生效;TUN 在网络层截包,应用根本不知道代理的存在,自然无所谓遵守不遵守。这就是 TUN 能接管终端命令、游戏流量、UWP 应用的原因。
代价是权限:创建虚拟网卡、改写路由表都需要管理员(Windows / macOS)或 root(Linux)权限,所以首次开启时系统会弹授权,属于正常现象。
TUN 模式与系统代理的区别
| 对比项 | 系统代理 | TUN 模式 |
|---|---|---|
| 工作层级 | 应用层(HTTP / SOCKS) | 网络层(IP 包) |
| 生效前提 | 应用主动读取系统代理设置 | 无需应用配合,整机接管 |
| 覆盖范围 | 浏览器及遵守设置的应用 | 全部 TCP / UDP 流量 |
| UDP 支持 | 基本不支持 | 支持(取决于节点) |
| 权限要求 | 普通用户即可 | 管理员 / root |
| 典型盲区 | 终端、游戏、UWP 应用 | 与其他 VPN 类软件抢路由 |
两条经验:日常浏览网页,系统代理足够,开销最小;需要终端走代理、给游戏加速、或某个应用死活不读系统代理时,开 TUN。两者可以同时开,不冲突——TUN 接管后,系统代理那条路基本闲置。但排查问题时建议只留一个,变量太多不好定位。
开启前的准备:内核、权限与配置
内核必须是 mihomo
TUN 由内核实现。原版 Clash 已停止维护,TUN 支持不完整;要使用稳定的 TUN 模式,客户端内核需为 mihomo(Clash Meta)。本站收录的 Clash Verge Rev、Clash Nyanpasu、FlClash、Clash Plus 等均为 mihomo 内核。
配置层面,mihomo 的 TUN 段写法如下。图形客户端一般只需拨开关,这些字段由客户端自动填写,了解含义即可:
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53stack:协议栈实现。system走系统协议栈,兼容性最好;gvisor是用户态协议栈,UDP 与游戏场景更稳;mixed让 TCP 走 system、UDP 走 gvisor,日常推荐。auto-route:自动写路由表,接管整机流量。关掉则网卡建了但流量不进来,等于没开。auto-detect-interface:自动探测真实出口网卡,多网卡机器建议保持开启。dns-hijack:劫持发往 53 端口的 DNS 查询,交给内核内置 DNS 处理,防止 DNS 泄漏导致分流判断出错。
DNS 建议配合 fake-ip 模式,TUN 下分流最干净:
dns:
enable: true
enhanced-mode: fake-ip各平台开启 TUN 的步骤
Windows(以 Clash Verge Rev 为例)
- 打开设置页,先安装「服务模式」。它是一个常驻小助手,装好后 TUN 模式不需要每次用管理员身份启动客户端。
- 回到设置页,打开「TUN 模式」开关。
- 系统弹出防火墙提示时选择允许;网络连接列表里会多出一张虚拟网卡。
- 不装服务模式也能用,但每次启动客户端都要右键「以管理员身份运行」。
macOS
- 在 Clash Verge Rev 或 ClashX Meta 的设置里开启 TUN(部分客户端叫增强模式)。
- 首次开启会要求输入开机密码,用于安装特权帮助程序,输入一次即可。
- 终端执行
ifconfig,能看到新增的 utun 设备即开启成功。
Linux
- 图形客户端直接打开 TUN 开关;命令行运行 mihomo 则需 root,或给二进制授予
cap_net_admin能力。 - 桌面环境若装了多个 VPN 工具,注意路由表只能有一个赢家,多余的先停掉。
Android 与 iOS
- Android 上的 Clash 客户端(Clash for Android、FlClash、Clash Plus)基于系统 VpnService 工作,本质就是 TUN,没有单独开关。点启动,系统弹出「连接请求」,确认后状态栏出现钥匙图标,即已全局接管。
- 建议把客户端加入电池优化白名单,防止后台被系统清理导致断流。
- iOS 同理:客户端通过系统网络扩展(Packet Tunnel)接管流量,首次启动授权添加 VPN 配置即可。
验证 TUN 接管是否生效
三步确认:
- 看网卡。Windows 运行
ipconfig,能找到名称含 Mihomo 或 utun 的适配器;macOS 与 Linux 用ifconfig或ip addr查看 utun 设备。 - 用不读系统代理的工具测出口。终端执行:
curl ip.sbcurl 默认不读系统代理设置。开启 TUN 前执行一次,返回本机真实 IP;开启后再执行,返回节点出口 IP,说明流量已被虚拟网卡接管。这是区分「系统代理生效」与「TUN 生效」最干脆的办法。
- 看连接页。客户端的连接(Connections)面板里应能看到 curl 对应进程产生的连接记录,规则链一栏显示它命中了哪条规则。
如果 curl 返回的还是本机 IP,优先检查 auto-route 是否开启、路由表是否被其他 VPN 软件改写。
常见问题与避坑
与其他 VPN 类软件冲突
企业 VPN、网游加速器、WSL2 虚拟交换机都会改路由表。多个软件同时抢默认路由,结果是都不通。同一时间只保留一个接管者。
网页能开,终端没走代理
多半是 auto-route 未生效,或路由表被其他软件改写。先关掉其他 VPN 类工具,再重开 TUN;多网卡机器确认 auto-detect-interface 处于开启状态。
DNS 异常:代理连通但域名解析出错
检查 dns-hijack 是否配置、enhanced-mode 是否为 fake-ip;系统 DNS 被写死成不可达地址时也会出现同样症状。
游戏 UDP 不通
TUN 只是管道,UDP 能不能转发取决于节点本身是否支持 UDP。节点支持却仍不通,把 stack 从 system 换成 gvisor 或 mixed 再试。
最后一点:TUN 让整机流量多过一遍协议栈,有轻微的性能与电量开销。不需要全局接管的场景,关掉 TUN、只留系统代理,更省。