#TUN 模式与系统代理有什么区别:流量接管层级、兼容性差异与选择建议

系统代理的工作机制:应用层的自觉配合

系统代理本质上是操作系统提供的一组环境变量或注册表项,记录着"HTTP 流量该发到哪个地址和端口"。Clash 系列客户端开启系统代理后,会把这组设置指向自己监听的 port(HTTP)或 socks-port(SOCKS5),浏览器、大多数带网络设置的应用在发起请求前会读取这些值,主动把连接建到 Clash 监听的端口上,再由 Clash 按规则分流。

这套机制的关键词是"自觉"。它依赖应用主动读取代理设置并遵守,一旦某个程序不读取系统代理(比如老版本的 Java 程序、部分游戏客户端、命令行工具默认忽略环境变量),它的流量就会直接走物理网卡出网,完全绕开 Clash 的规则判断。这不是 Clash 的问题,而是系统代理这种接管方式本身的边界——它只能管住"愿意配合"的进程。

TUN 模式的工作机制:网络层的虚拟网卡

TUN 模式的思路完全不同,它不在应用层做说服工作,而是直接在操作系统的网络层挂一张虚拟网络接口(virtual network interface)。启用后,Clash Meta(mihomo 内核)会创建一张名为 utun(macOS)、Meta 或类似命名(Windows/Linux)的虚拟网卡,并通过修改系统路由表,把默认路由或部分子网的流量指向这张虚拟网卡。

此后,操作系统层面看到的不是"某个应用要不要用代理",而是"这个数据包该走哪张网卡出去"——这是内核路由层的决策,和应用是否感知代理无关。数据包进入虚拟网卡后,由 mihomo 内核在用户态解析、还原成 TCP/UDP 连接,再按代理规则处理转发。因为决策点下沉到了网络层,几乎所有进程产生的流量都会被这张虚拟网卡截获,不存在"某个程序不听话"的问题。

# config.yaml 中开启 TUN 模式的基础字段
tun:
  enable: true
  stack: system   # 可选 system / gvisor / mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

其中 stack 决定虚拟网卡的实现方式:system 使用系统原生 TUN/TAP 驱动,性能较好但对系统版本有一定要求;gvisor 是用户态网络栈,兼容性更好但吞吐略低;mixed 是较新内核提供的折中方案。auto-route 负责自动写入路由表,关闭后需要手动配置路由,建议非高级用户保持开启。

两者的覆盖范围与兼容性差异

覆盖范围上,系统代理只能管住主动读取代理设置的进程,典型是浏览器、大多数桌面应用的网络请求;而系统级服务、部分后台进程、命令行工具、游戏客户端的网络模块往往不读取系统代理,流量会直接绕过。TUN 模式因为工作在路由层,理论上能接管所有基于 IP 协议栈的流量,包括那些"不认代理"的进程。

但覆盖范围广不等于没有兼容性代价,以下几类场景需要留意:

• 虚拟机与容器网络:如果虚拟机使用 NAT 或桥接网络,其流量路径可能与主机的 TUN 路由表产生冲突,导致虚拟机断网或走错路径,通常需要在 route-exclude-address 中把虚拟机子网排除。
• 本地局域网访问:开启 TUN 后访问局域网内的打印机、NAS、路由器管理页面时,如果没有正确配置直连规则或本地网段例外,流量可能被误判成需要代理转发,造成访问失败。
• VPN 软件叠加使用:两套虚拟网卡同时争夺默认路由,容易出现互相覆盖、断线的情况,一般不建议同时开启系统级 VPN 和 Clash 的 TUN 模式。
• 需要管理员/系统权限:创建虚拟网卡、修改路由表都属于系统级操作,TUN 模式在 Windows 上需要管理员权限运行,在 macOS/Linux 上通常需要 sudo 或对应的权限授予流程,这一点和系统代理"点个开关就好"不同。

相对地,系统代理不涉及路由表和虚拟网卡,基本不会和虚拟机、其他 VPN 冲突,权限要求也低,这是它在兼容性上的优势——问题只出在覆盖不全。

性能开销与稳定性对比

系统代理的转发路径比较短:应用直连 Clash 监听的端口,Clash 判断规则后转发到目标服务器,中间只经过一次用户态代理逻辑,开销主要来自规则匹配和加密解密,对大多数带宽场景影响很小。

TUN 模式多了一道"网络层截获 + 协议还原"的工序:数据包先进虚拟网卡,内核网络栈处理后交给 mihomo 用户态程序解析成完整的 TCP/UDP 会话,再走一遍代理规则和转发逻辑。这个过程比系统代理多了一次内核态与用户态之间的数据拷贝,理论上会带来轻微的延迟和 CPU 占用增加,具体幅度和 stack 的选择有关——system 栈通常比 gvisor 更接近系统代理的性能水平。对普通网页浏览、视频观看等场景,这点差异基本感知不到;但在大量小包、高并发连接的场景(比如某些下载工具、区块链节点同步),差异会更明显一些。

稳定性方面,系统代理出问题通常表现为"某个应用没走代理",影响范围局限、易定位;TUN 模式出问题则可能表现为路由表异常导致的大范围断网,恢复手段是关闭 TUN 或重启网络服务,排查成本相对更高,这也是为什么多数客户端把 TUN 模式放在"进阶设置"里,而不是默认开启。

命令行工具、游戏与 UWP 应用场景下怎么选

不同应用类型对代理设置的支持程度差异很大,以下是几类典型场景的建议。

命令行工具(curl、git、包管理器等)

大多数命令行工具默认不读取系统代理,而是依赖显式设置的环境变量,例如:

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"

如果嫌逐个设置环境变量繁琐,或者工具本身连环境变量都不认(部分 Go/Rust 编译的静态工具),开启 TUN 模式是更省心的做法——不需要为每个工具单独配置,虚拟网卡会统一接管。

游戏客户端

不少游戏的启动器和游戏本体是分离的两个进程,且大量使用 UDP 传输(尤其是对战类游戏的实时同步数据),系统代理对 UDP 的支持有限,往往只能代理到启动器登录环节,进入对局后的流量仍然走物理网卡。如果需要让游戏对局流量也按规则分流(比如接入某个专线节点降低延迟),TUN 模式基本是唯一可靠的路径,因为它在网络层统一接管 TCP 和 UDP。需要注意提前在规则里为游戏加速节点单独分组,避免游戏流量被电影、下载等大流量规则组抢占带宽。

UWP 应用(Windows 应用商店应用)

Windows 平台的 UWP 应用运行在独立的网络隔离容器(Network Isolation)里,默认情况下既不读取系统代理,也不在 TUN 模式的常规路由捕获范围内,这是 Windows 系统设计导致的沙盒隔离,不是 Clash 客户端的疏漏。要让 UWP 应用(例如部分应用商店版本的浏览器、聊天工具)也走代理,通常需要额外执行 CheckNetIsolation.exe 相关命令为该应用放行网络隔离,或者在客户端里找到"允许访问 UWP 应用回环/网络"一类的开关,这一步系统代理和 TUN 模式都需要单独处理,不存在哪种模式天然兼容。

该怎么选:一个简单的判断思路

如果日常使用集中在浏览器和常规桌面应用,系统代理已经能覆盖绝大部分场景,配置简单、出问题好排查,是更省心的默认选项。如果遇到以下任意一种情况,再考虑切换到 TUN 模式:命令行工具频繁需要代理却不想逐个设置环境变量;游戏、语音通话等 UDP 流量需要走规则分流;某个进程明确不读取系统代理导致规则形同虚设。切换前建议先确认自己的虚拟机、其他 VPN 软件是否会和虚拟网卡产生路由冲突,并检查客户端里的局域网直连规则是否已经正确配置,避免开启后出现内网设备访问异常的情况。