TUN 模式和系统代理有什么区别:两种流量接管机制的工作原理对比

两种机制的本质区别

Clash 客户端提供两种让流量走代理的方式:系统代理(System Proxy)和 TUN 模式。很多人把它们当成"哪个更好用"的二选一开关,但实际上两者工作在完全不同的层级,解决的是不同的问题。理解这个层级差异,才能明白为什么某些应用换了代理设置也不生效,而某些命令行工具怎么设都连不上。

系统代理是操作系统提供的一套配置接口,本质上只是往系统或浏览器写入一条"HTTP/HTTPS 代理服务器地址"的记录。它工作在应用层:哪个程序愿意读取这条配置、愿意按这个地址转发请求,流量才会经过代理;不读取这条配置的程序,流量照常走原本的网络路径,和代理毫无关系。

TUN 模式则完全不同。它由客户端在系统里创建一块虚拟网卡(Virtual Network Interface),并通过修改系统路由表,把设备上大部分甚至全部的出站流量都先送到这块虚拟网卡,再交给 Clash 内核处理。这个过程发生在网络层,不依赖任何应用主动配合——只要数据包要出网,就会经过虚拟网卡,不管上层是什么程序、用了什么协议。

系统代理的工作路径与局限

系统代理的实现路径可以拆成三步:客户端启动 HTTP/SOCKS 混合端口(Clash 里默认的 mixed-port 常见值是 7890)、客户端把这个端口写入系统或浏览器的代理设置项、应用发起网络请求时查询该设置并把请求转发到这个端口。整个链路的关键在第三步——转发这一步是"应用主动配合"完成的,不是系统强制的。

大多数图形界面浏览器和常见桌面应用都会规范地读取系统代理设置,所以系统代理模式覆盖日常网页浏览、聊天工具、大部分桌面软件已经足够。但它有几个明确的短板:

• 不遵循系统代理设置的程序不受影响,常见于部分命令行工具、部分游戏客户端、以及一些用自定义网络库直连的应用。
• 只覆盖 HTTP/HTTPS 及部分 SOCKS 流量,不处理 UDP 为主的协议(比如某些依赖 UDP 的游戏或视频通话场景),除非程序本身支持走 SOCKS5 UDP 转发。
• 依赖 PAC 或系统层配置项,不同操作系统实现细节不一致,macOS、Windows、Linux 桌面环境各有各的代理配置入口,行为略有差异。

TUN 模式如何在网络层接管流量

TUN 全称 Tunnel 虚拟网络设备,它是操作系统内核提供的一种网络接口类型,行为上和一块真实网卡几乎一样——有自己的 IP 地址,能被路由表引用,能被防火墙规则匹配。区别在于它不连接物理硬件,收发的数据包由用户态程序(这里就是 Clash / Clash Meta 内核)读取和处理。

开启 TUN 模式后,客户端会做三件事:创建虚拟网卡并分配一个内部 IP、把系统默认路由或部分路由指向这块虚拟网卡、在内核内部接管从这块网卡流入的数据包并按代理规则转发。因为路由层面已经把流量导向虚拟网卡,任何走系统网络栈发出请求的程序都逃不掉这一层拦截,不管它是否知道"代理"这个概念。这也是为什么 TUN 模式常被称为全局流量接管。

一个直观的配置片段能说明这个层级差异,以下是 Clash Meta(mihomo)配置里 TUN 相关的常见字段:

tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53
  auto-route: true
  auto-detect-interface: true

auto-route 负责自动写入路由表条目,dns-hijack 负责把 DNS 查询也一并劫持到内核里处理,避免流量走了代理但 DNS 解析仍暴露真实出口的情况。这两项配合起来,才是"全局接管"名副其实的原因——系统代理模式做不到劫持 DNS 查询,这也是两者在隐私层面的一个实际差异。

为什么命令行工具和游戏经常必须用 TUN

命令行工具(比如某些包管理器、版本控制工具、自定义脚本)往往不读取系统代理设置,而是要求用户手动传入 --proxy 参数或设置 HTTP_PROXY/HTTPS_PROXY 环境变量才会生效。如果工具本身没有实现这类参数,系统代理设置对它就是不可见的,唯一能让它联网走代理的方式就是 TUN——因为 TUN 拦截的是路由层的数据包,工具是否"愿意"配合代理完全不重要。

游戏客户端的情况类似,但原因更复杂一些:

1. 不少游戏的网络模块直接调用底层 socket 接口发起连接,完全绕开系统或浏览器的代理配置项。
2. 游戏对战、语音、部分资源下载大量使用 UDP,而系统代理默认覆盖的 HTTP/HTTPS 场景对 UDP 支持有限。
3. 部分游戏客户端会做反作弊或网络环境检测,直接屏蔽已知的系统代理端口特征,但对虚拟网卡这种系统层网络接口不做特殊处理。

这三点叠加,导致"开了系统代理但游戏还是直连"的现象很常见,而切到 TUN 模式后流量立刻被正确接管。这也是为什么很多客户端把 TUN 模式单独列出来,并在教程里特别强调游戏、命令行场景优先用 TUN。

性能与稳定性差异要提前预知

TUN 模式覆盖面更广,但代价是多了一层用户态与内核态之间的数据拷贝和处理,理论上会比系统代理多一点延迟和 CPU 占用,尤其在流量较大的场景(比如大文件下载、4K 视频)更容易感知到差异。系统代理因为链路更短,通常在轻量场景下表现更轻。实际使用中这个差异对多数人不明显,但如果设备性能有限或对延迟极度敏感(比如竞技类游戏),值得先做个人对比测试再决定长期用哪种模式。

另外,TUN 模式因为修改了系统路由表,在少数情况下可能与其他 VPN 软件、虚拟机网络、企业内网客户端产生路由冲突,表现为开启后完全无法联网或只能访问部分地址。遇到这种情况,先确认是否同时运行了其他会修改路由表的网络工具,关闭其中一个通常能定位问题。系统代理因为不改路由表,基本不会有这类冲突,兼容性更稳。

该怎么选:两种模式的适用场景

不需要纠结"哪个更好",两者本来就是为不同场景设计的,可以按下面的思路选:

• 日常浏览网页、用主流聊天工具和桌面应用,系统代理已经够用,链路短、资源占用低。
• 用命令行工具、SDK、包管理器需要联网但工具本身不认系统代理设置,直接开 TUN,不用逐个工具找参数配置代理。
• 玩需要走代理的游戏,或者游戏走 UDP 较多导致系统代理下延迟异常,优先试 TUN。
• 怀疑某个应用绕过了代理设置在直连,可以先用系统代理模式配合抓包工具确认,再决定是否切到 TUN 彻底堵住这个口子。

大多数客户端(比如 Clash Verge Rev、FlClash、Clash Nyanpasu)在设置里都把系统代理和 TUN 模式做成独立开关,两者甚至可以同时开启,互不冲突,只是同时开启时实际生效的接管层级以 TUN 为主。刚安装完客户端建议先用默认的系统代理模式验证节点和规则是否正常,再根据具体应用的联网情况决定是否需要额外打开 TUN。