两种流量接管方式的本质区别
Clash 客户端(以及 mihomo 内核)提供两种截然不同的流量接管方式:系统代理与 TUN 模式。二者常被当作"效果差不多的两个开关",但它们在操作系统层面的工作原理完全不同,这个差异直接决定了哪些流量会被代理、哪些会被漏过。
系统代理的做法是修改操作系统或浏览器的代理设置项,告知支持代理协议的应用程序"请把 HTTP/HTTPS 请求发到这个地址和端口"。这是一种应用层的约定,依赖每个程序自己去读取并遵守这个设置。Windows 的"网络和 Internet 设置"、macOS 的"网络偏好设置"、Linux 桌面环境的代理选项,本质上都是在写入一份可被查询的配置,程序读取后自行决定是否使用。
TUN 模式则完全不同,它在操作系统内核层面创建一张虚拟网络接口(virtual network interface),让系统认为多了一张网卡。随后 Clash 通过路由表规则或防火墙规则,把设备上几乎所有出站流量都导向这张虚拟网卡,再由 mihomo 内核在用户态解析这些原始 IP 数据包,还原成具体的连接请求后按规则转发。这种方式作用在网络层,不依赖应用程序是否"配合",是一种更底层的流量劫持机制。
系统代理为什么会漏流量
系统代理的核心局限在于它是"自愿遵守"机制,而不是强制接管。这带来几类实际会踩到的漏流量场景。
不读取系统代理设置的程序
大量命令行工具、后台服务和部分桌面程序不会主动查询系统代理配置,而是直接建立 TCP 连接。常见例子包括 curl、git、ssh、部分包管理器(如未显式配置代理的 pip、npm)、以及不少 Electron 应用之外的原生客户端。这些程序发出的请求会直接绕过 Clash,走本机默认网络路径。
UDP 流量普遍不受系统代理约束
系统代理设置本质上是为 HTTP/HTTPS 这类基于 TCP 的请求设计的,操作系统层面并没有统一的"UDP 系统代理"概念。这意味着依赖 UDP 的应用——包括大量网络游戏的实时同步流量、基于 QUIC(HTTP/3)的网页请求、部分视频通话软件、DNS 查询本身——在系统代理模式下往往完全不经过 Clash。如果代理节点本身支持 UDP 转发(如 Shadowsocks、Trojan 部分实现),这部分能力在系统代理模式下也用不上。
游戏客户端的特殊性
游戏对网络延迟极为敏感,多数游戏引擎会直接调用底层 socket 接口建立连接,既不查询系统代理,也很少支持应用层代理协议。想要让游戏流量走代理,几乎必须依赖网络层的接管方式,系统代理在这类场景里基本无效。
系统代理模式下"部分网站能访问、部分连不上"的现象,很多时候不是节点或规则问题,而是该程序本身没有遵循系统代理设置,或使用了系统代理管不到的 UDP 通道。排查前先确认问题程序的网络实现方式,能省下不少反复调节点的时间。
TUN 模式如何做到全局接管
TUN 模式的接管范围明显更广,原理上覆盖了系统代理遗漏的绝大多数场景,原因在于它工作在网络层而非应用层。
- 不依赖程序配合。虚拟网卡加路由表的组合,让所有发往公网的数据包默认经过这张虚拟接口,无论发起连接的程序是否"知道"存在代理,这一点对命令行工具和不支持代理设置的程序尤其重要。
- 原生支持 UDP。mihomo 内核在处理 TUN 流量时会解析 UDP 数据包并按规则转发,只要选中的代理节点本身支持 UDP over 对应协议,游戏、语音通话、QUIC 请求都能被正常代理,不再是系统代理模式下的盲区。
- 对本机所有网络接口生效。虚拟机、容器、部分开发环境产生的流量,只要最终经过系统默认路由,也会被 TUN 网卡截获,覆盖面比逐个应用配置代理更彻底。
需要指出的是,TUN 模式并非"零配置万能开关"。它依赖操作系统层面的权限——在 Windows 上需要管理员权限运行以创建虚拟网卡并修改路由表,在 macOS 和 Linux 上通常需要安装内核扩展或使用特定网络扩展框架,并授予相应权限。部分客户端(如 Clash Verge Rev、FlClash)在设置中提供了"服务模式"或"TUN 模式"开关,开启前一般会有权限授权提示,这是正常流程而非异常报错。
两种模式的实际差异对照
| 对比维度 | 系统代理 | TUN 模式 |
|---|---|---|
| 工作层级 | 应用层(需程序主动读取设置) | 网络层(虚拟网卡 + 路由表) |
| 命令行工具覆盖 | 取决于工具是否读取代理环境变量 | 默认全部覆盖 |
| UDP / 游戏流量 | 普遍不支持 | 支持(取决于节点协议能力) |
| 所需权限 | 普通用户权限即可 | 需管理员/root 权限或系统网络扩展授权 |
| 开启成本 | 低,开关即用 | 较高,涉及首次权限配置 |
| 与本地网络工具的兼容性 | 基本无冲突 | 可能与部分虚拟机网络、VPN 客户端产生路由冲突 |
如何选择:场景导向的判断标准
没有绝对更优的一方,选择应该基于实际使用场景。以下是几种典型判断路径。
只是日常网页浏览、办公软件访问外部服务
系统代理已经足够。浏览器和绝大多数办公类客户端都会遵循系统代理设置,不需要引入 TUN 模式带来的额外权限配置和潜在路由冲突风险。这也是多数客户端默认给出的初始模式。
需要在终端里使用 git、curl、包管理器等工具
优先考虑 TUN 模式,或者为这些工具单独配置代理环境变量(如设置 HTTP_PROXY/HTTPS_PROXY 环境变量指向 Clash 的混合端口)。后者更轻量,但需要逐个工具配置,不如 TUN 模式一次性解决。
玩需要连接海外服务器的网络游戏
基本只能依赖 TUN 模式。游戏流量以 UDP 为主且不读取系统代理设置,系统代理模式下几乎不会对游戏连接产生任何效果,这也是社区里"开了代理游戏还是连不上"的常见原因之一。
公司电脑或对系统权限变更有顾虑的环境
建议使用系统代理。TUN 模式需要较高的系统权限并会修改路由表,在受管控的办公设备上开启前应确认是否符合所在单位的设备使用规范。
主流客户端(Clash Verge Rev、FlClash、Clash Plus 等)都支持在设置界面里直接切换系统代理与 TUN 模式,不需要手动改动配置文件字段。首次开启 TUN 模式时按提示完成一次性的权限授权即可,后续切换只是一个开关操作。
关于混合使用的几点说明
部分用户会同时开启系统代理和 TUN 模式,理论上不冲突,但实际意义有限——一旦 TUN 模式生效,几乎所有流量已经被路由表导向虚拟网卡,系统代理设置基本不会再被触发,同时开启更多是心理上的"双重保险",不带来额外覆盖范围。
另外需要注意,TUN 模式与某些 VPN 客户端、虚拟机桌面软件的网络适配器可能存在路由表争抢的情况,如果发现开启 TUN 模式后虚拟机网络异常或另一个 VPN 连接失效,通常是路由优先级冲突,可以在配置中调整 TUN 的路由跳数(metric)或临时关闭冲突的一方定位问题,而不必怀疑 Clash 本身出错。
无论选择哪种模式,策略组、代理节点与分流规则的配置逻辑是共通的——TUN 模式只是改变了"流量怎么被送到 Clash 手里",之后走规则判断、选节点、转发出去的处理链路和系统代理模式完全一致。理解这一点后,两种模式之间的切换只是接管方式的选择,不涉及重新学习一套规则体系。