Clash TUN 模式是什么:虚拟网卡接管全局流量的原理与开启步骤

DOC-01

系统代理模式的覆盖边界

多数用户第一次接触 Clash 时,使用的是系统代理模式。这种模式的工作方式是:客户端启动一个本地 HTTP/SOCKS5 端口,操作系统或浏览器把该端口写入代理设置,应用发起请求时读取这份设置,把流量转发到本地端口,再由 Clash 处理。这条路径依赖两个前提——应用支持读取系统代理设置,应用使用的协议在代理支持范围内。

问题恰恰出在这两个前提上。部分命令行工具、部分游戏客户端、部分内置了自定义网络栈的应用,不读取系统代理配置,或者只支持 HTTP 协议、不支持 UDP。这些流量会绕开 Clash,直接走物理网卡出站。结果是:浏览器分流正常,但某个客户端始终连接失败,或者始终走的是本机真实 IP,这类问题的根源大多在这里。

系统代理模式的覆盖盲区可以归纳为三类:不遵循系统代理设置的进程、依赖 UDP 且代理协议不支持转发的场景、以及在应用层之下发起连接的系统服务或驱动。TUN 模式正是为了填补这三类盲区而存在。

DOC-02

TUN 模式的工作原理

TUN 是一种虚拟网络设备,工作在操作系统内核网络栈的接口层。Clash Meta(内核 mihomo)开启 TUN 模式后,会在系统里创建一块虚拟网卡,并通过修改系统路由表,把默认路由或指定网段的流量导向这块虚拟网卡。此时,流量的拦截点从应用层的代理设置,下移到了网络层的路由规则。

这个区别决定了覆盖范围的差异。系统代理模式是"应用主动配合才能被代理",TUN 模式是"只要走系统路由就会被截获"。不管发起连接的是浏览器、命令行工具还是某个后台服务,只要它的数据包经过系统网络栈,就会被路由到虚拟网卡,交给 Clash 内核按规则处理——直连、走代理、还是拒绝,判定逻辑和普通代理模式完全一致,只是流量入口变了。

具体流程大致如下:

1. Clash 内核创建虚拟网卡(如 Meta 或 utun 设备),分配虚拟 IP 段。
2. 内核在系统路由表中插入规则,把需要接管的流量指向该虚拟网卡。
3. 应用发出的数据包经过系统路由判断,进入虚拟网卡而不是物理网卡。
4. Clash 内核在用户态读取虚拟网卡的数据,还原出原始的 TCP/UDP 连接请求。
5. 按规则列表判定该连接走直连还是某个代理节点,再由对应出口转发出去。

这套机制要求客户端具备创建虚拟网卡与修改路由表的系统权限,这也是为什么 TUN 模式在各平台都需要额外授权,而不是像系统代理模式那样点开关就能用。

DOC-03

两种模式的关键差异对照

把系统代理模式和 TUN 模式放在同一张表里比较,更容易判断该在什么场景下用哪一种。

简单结论:如果只是让浏览器分流,系统代理模式已经足够,配置也更简单。如果目标是让全部本机流量(包括不配合代理设置的进程)都纳入规则管控,TUN 模式是必要选项。

DOC-04

分平台开启步骤

各平台底层虚拟网卡实现不同,授权方式也不同,以下按平台分别说明。

Windows

Windows 上的 TUN 实现依赖 Wintun 驱动,主流客户端(如 Clash Verge Rev、Clash for Windows 系桌面客户端)安装包内已经集成该驱动,首次开启时通常会触发系统的驱动安装确认或 UAC 提权弹窗,需要以管理员身份运行客户端,并允许该驱动安装请求,否则虚拟网卡无法创建。

1. 关闭系统代理模式(避免两种模式的路由规则相互干扰)。
2. 以管理员身份重新启动客户端。
3. 在设置中找到 TUN 模式开关并开启,确认驱动安装提示后点击允许。
4. 打开"网络连接"面板,确认出现一块名为 Meta 或类似标识的虚拟网卡,状态为已连接。
5. 用浏览器访问 IP 查询页面,核对出口 IP 是否变为代理节点所在地区。

macOS

macOS 使用系统自带的 utun 接口族,客户端创建虚拟网卡本身不需要额外驱动,但需要辅助进程权限。桌面客户端(如 Clash Verge Rev、ClashX 系)首次开启 TUN 时会请求安装一个特权辅助工具,系统会弹出密码输入框,输入当前用户密码完成授权。

1. 在设置中开启 TUN 模式开关。
2. 系统弹出授权提示时,输入 macOS 登录密码确认。
3. 如果客户端提示需要安装或更新辅助服务,按提示完成一次性安装。
4. 用系统的"网络"设置面板查看是否新增一个虚拟接口。

较新版本的 macOS 对系统扩展和网络扩展的权限收紧较多,如果授权弹窗没有出现或点击后无响应,可以在"系统设置 - 隐私与安全性"里检查是否有被阻止的后台组件,手动允许后重启客户端再试。

Android

Android 上的 TUN 模式通过系统的 VPNService 接口实现,这是系统开放给应用做全局代理的标准方式,不需要 root 权限。开启方式与授权一个普通 VPN 应用类似。

1. 在客户端(如 Clash Meta for Android)里打开 TUN 或"虚拟网卡"开关。
2. 系统弹出"连接请求"对话框,提示该应用将建立一个 VPN 连接,点击确定。
3. 状态栏出现 VPN 图标,表示虚拟网卡已生效。
4. 如果需要排除某些本地应用不走代理,可在应用的分应用代理设置中单独勾除。

需要注意的是,系统层面同一时间只能有一个 VPNService 生效,如果设备上还安装并开启了其他 VPN 类应用,两者会互相抢占,需要先关闭另一个。

iOS

iOS 上的等效机制是 NetworkExtension 框架下的个人 VPN 配置,客户端在首次开启对应模式时会请求安装一个 VPN 配置描述文件,需要在系统提示中确认信任。

1. 在客户端设置中开启全局流量接管相关开关。
2. 系统弹出"允许添加 VPN 配置"提示,输入设备密码或使用面容确认。
3. 在"设置 - VPN"中确认该配置状态为已连接。

Linux

Linux 上创建 TUN 设备依赖内核自带的 tun 模块,通常无需单独安装驱动,但客户端进程需要 CAP_NET_ADMIN 能力或以 root 权限运行才能创建接口和修改路由表。

# 以 root 权限运行客户端,或为二进制文件单独授予网络管理能力
sudo setcap cap_net_admin,cap_net_raw=eip /path/to/clash-core

授予能力后即可用普通用户身份运行客户端并开启 TUN 模式,不必每次都用 sudo 启动整个程序,这样能减少不必要的权限暴露。

DOC-05

常见冲突与排查思路

TUN 模式涉及虚拟网卡与路由表改写,出问题时表现往往是"能连上但没有效果"或"直接连不上网",而不是清晰的报错。以下是几类高频情况。

与其他 VPN 或虚拟网卡工具冲突

如果设备上同时运行着企业 VPN 客户端、某些安全软件自带的网络过滤驱动,或另一款代理工具的 TUN 组件,多个虚拟网卡会争夺路由优先级。表现通常是开启 TUN 后网络时断时续,或者部分流量绕过了预期路径。处理办法是先关闭其他虚拟网络组件,只保留一个在跑,确认 Clash 的 TUN 单独工作正常后,再考虑是否需要两者共存以及如何调整路由优先级。

DNS 解析异常

开启 TUN 模式后,如果域名解析仍走系统原有 DNS 而不经过 Clash 内核,可能导致域名被劫持到错误地址,或者规则里按域名匹配的项目失效。这种情况通常需要在配置里同时打开 DNS 接管相关设置,让内核统一处理解析请求,而不是让流量层面接管了、解析层面却还在用系统默认 DNS。

虚拟网卡创建失败

Windows 上常见原因是驱动未正确安装或权限不足;macOS 上常见原因是特权辅助工具被系统安全策略拦截;Linux 上常见原因是权限能力未正确设置。排查顺序建议是:先确认客户端是否以足够权限运行,再检查系统日志或客户端日志里是否有明确的驱动或权限报错,最后确认没有其他程序占用了同名的虚拟网络接口。

部分应用仍未被接管

少数应用会绕过系统路由表,自行指定网络接口发送数据,这类情况在 TUN 模式下也无法覆盖,属于应用自身的实现方式导致,不是配置错误。如果确认某个应用始终不受任何模式管控,可以在该应用自身的网络设置里检查是否有独立的代理或直连选项。

DOC-06

该不该常开 TUN 模式

TUN 模式的覆盖面更完整,但也意味着系统层面多了一层路由改写,遇到问题时排查链路更长。日常只用浏览器上网、对分流精细度要求不高的场景,系统代理模式已经能满足需求,配置简单、冲突概率低。需要覆盖游戏客户端、命令行工具、后台服务等不配合系统代理设置的场景时,TUN 模式是更稳妥的选择。

两者并不互斥,大多数客户端支持随时切换,可以按当前使用场景灵活启停,不必固定选择一种模式长期使用。