Clash TUN 模式是什么?虚拟网卡接管全局流量的原理与开启方法

为什么需要 TUN:系统代理的三个盲区

多数 Clash 客户端默认以系统代理方式工作:内核在本地开启一个 HTTP/SOCKS 混合端口,再把这个地址写进操作系统的代理设置。这个方案部署简单,但存在三个结构性盲区。

• 只覆盖主动遵循设置的应用。是否走代理由应用自己决定,只有读取系统代理设置的程序才会把流量交给内核。大量命令行工具(git、curl、npm、docker)、多数游戏和一部分桌面软件不读这个设置,流量直接绕过代理。
• 只处理 TCP。系统代理管不到 UDP 与 ICMP,语音通话、在线游戏、QUIC 等基于 UDP 的流量不在接管范围内。
• DNS 仍走本地运营商。应用自行解析域名,解析结果可能被污染,被污染的错误 IP 再交给代理也无济于事。

TUN 模式的思路是把接管点从应用层挪到网络层:由内核创建一块虚拟网卡,让操作系统把所有出站 IP 包都路由进来,应用全程无感知。

工作原理:虚拟网卡如何接管全局流量

TUN 是操作系统提供的三层虚拟网络设备,进出它的是原始 IP 数据包;它的二层版本叫 TAP,处理以太网帧。Clash 系内核(mihomo 等)使用的是 TUN。

开启 TUN 后,内核依次做三件事:

1. 创建设备。Windows 上加载 wintun 驱动生成虚拟网卡,macOS 上创建 utun 设备,Linux 上打开 /dev/net/tun。
2. 接管路由。修改系统路由表,把默认路由指向虚拟网卡(auto-route),同时记录物理网卡作为真实出口(auto-detect-interface)。
3. 逐包处理。内核从虚拟网卡读出 IP 包,重组 TCP 会话、为 UDP 建立转发映射,再用配置里的规则(DOMAIN-SUFFIX、GEOIP、IP-CIDR、MATCH 等)决定这个连接走代理节点、直连还是拒绝。

协议栈 stack 的选择

把原始 IP 包还原成 TCP/UDP 流需要一套 TCP/IP 协议栈,mihomo 提供三种:gVisor 是用户态实现,兼容性最好;system 复用操作系统协议栈,开销更小;mixed 让 TCP 走 system、UDP 走 gVisor,是常见的折中。桌面客户端一般默认 gVisor 或 mixed,日常使用不必改动。

与 fake-ip 的配合

TUN 通常与 fake-ip 模式一起工作。应用的 DNS 查询被内核接管(dns-hijack),内核返回 198.18.0.0/16 段内的一个假地址,并记下它与域名的映射;应用随后连接这个假地址时,内核反查出真实域名,按域名规则精确分流。直接收益有两个:一是避开本地 DNS 污染,二是让按域名分流对只发 IP 包的场景同样生效。

TUN 模式与系统代理对照

两者不冲突。多数客户端建议保留系统代理作为兜底:遵循系统代理的应用走应用层通道,其余流量由 TUN 在网络层接住。

各平台开启方法

Windows(以 Clash Verge Rev 为例)

1. 打开设置页,找到「服务模式」(Service Mode),点击安装。该服务以系统服务常驻,负责创建虚拟网卡;装好后主程序不必每次用管理员身份启动。
2. 回到设置,打开「TUN 模式」开关。
3. 首次开启若被防火墙拦截,允许 wintun 虚拟网卡通过。

macOS

在 Clash Verge Rev 或 ClashX Meta 中打开 TUN(增强模式)开关,系统会要求输入登录密码,用于安装特权助手以创建 utun 设备。授权一次即可,之后开关不再询问。

Linux

创建 TUN 设备需要 CAP_NET_ADMIN 权限。要么用 root 运行内核,要么给内核二进制授权:

sudo setcap cap_net_admin,cap_net_bind_service=+ep /usr/local/bin/mihomo

Android 与 iOS

移动端没有独立开关:Android 客户端(Clash Meta for Android、FlClash 等)基于系统 VpnService 工作,iOS 端(Clash Plus 等)基于 Network Extension 的 Packet Tunnel,二者本身就是虚拟网卡方案。这也是移动端能全局接管所有 App 流量的原因。

手动写配置(进阶)

直接维护 mihomo 配置文件时,等效配置如下:

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

auto-route 负责接管默认路由,auto-detect-interface 负责识别真实出口网卡,两者缺一不可;dns-hijack 把 53 端口的 DNS 查询劫持进内核。

适合开 TUN 的场景

• 游戏与实时语音:UDP 流量只有 TUN 能接管,前提是所用节点支持 UDP 转发。
• 命令行与开发工具:git clone、curl、包管理器、容器拉取镜像等不读系统代理的操作。
• 不遵循代理设置的客户端:部分国产软件、老旧程序、内置硬编码网络栈的应用。
• 按进程分流:TUN 接管后内核能看到连接来自哪个进程,可配合 PROCESS-NAME 规则做细粒度分流。

反过来说,以日常网页浏览为主的用户,开不开 TUN 差别不大,系统代理已经足够,不必为开而开。

常见冲突与排查

与其他 VPN、加速器共存

每个 VPN 类工具都想接管默认路由,同时开两个的结果通常是路由表互相覆盖、两者都失效。同一时间只保留一个接管者;必须共存时,在另一个工具里把本机网段和节点服务器地址加入绕过列表。

流量回环

内核自己发往代理服务器的流量如果也被路由进 TUN,会形成回环,表现为开启瞬间全网断流。auto-detect-interface 的作用就是让内核出站绑定物理网卡,避开虚拟网卡。手动改路由表时,务必保证节点服务器 IP 走物理出口。

浏览器 DoH 绕过 DNS 接管

Chrome、Edge 的「安全 DNS」会把域名解析交给 DoH 服务器(走 443 端口),内核的 dns-hijack 接不到这些查询,fake-ip 随之失效,表现为域名规则对浏览器不生效。处理办法是关闭浏览器的安全 DNS,把解析交还给内核。

内网地址打不开

默认路由被接管后,公司内网、校园网、路由器管理页可能不可达。在规则里为内网网段加 IP-CIDR 直连规则:

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve

虚拟机、WSL2 与 Docker

Windows 上 Hyper-V 虚拟交换机与 TUN 路由可能冲突,导致 WSL2 断网或容器无法访问外网。可调整虚拟网卡的接口跃点数,让 WSL2 的流量被正确接管,或在客户端设置里排除 Hyper-V 网段。

开启 TUN 后完全无法上网

1. 确认 auto-route 与 auto-detect-interface 均已开启。
2. 退出其他代理工具的「增强模式」「全局路由」类功能后重试。
3. 查看客户端日志,确认虚拟网卡创建成功、没有权限报错。
4. 仍不通时关闭 TUN 开关,多数客户端会自动恢复路由表;未恢复则重启网络服务或重启系统。

常见问题

结论

TUN 模式把代理接管点从应用层下沉到网络层:一块虚拟网卡接住全部出站 IP 包,内核按规则逐连接分流。它解决的是系统代理管不到的三类流量——不读代理设置的应用、UDP、以及被污染的 DNS。日常浏览用系统代理即可;涉及游戏、命令行工具或顽固客户端时,再打开 TUN,并留意与其他 VPN 工具、浏览器 DoH 和内网网段的冲突。