2026-06-28 进阶配置 预计阅读 9 分钟

Clash TUN 模式和系统代理有什么区别:流量接管机制对比与选择建议

对比系统代理与 TUN 模式两种流量接管方式的工作层级、覆盖范围与兼容性差异,说明哪些程序会绕过系统代理,以及什么场景下应该切换到 TUN 模式。

两种接管方式先从原理说起

使用 Clash 之前,理解流量是怎样被"劫持"进代理程序的,比记住任何一个开关名称都更重要。Clash 及其衍生内核 Clash Meta(mihomo)提供两条截然不同的路线:一条是"系统代理",另一条是"TUN 模式"。它们解决的都是同一个问题——把设备发出的网络请求送进 Clash 的规则引擎再转发出去——但介入的层级完全不同,这直接决定了各自的覆盖范围、兼容性与配置成本。

系统代理是操作系统层面提供的一套配置接口,本质上是告诉支持该协议的程序:"请把你的 HTTP/HTTPS 请求先发给这个地址和端口"。Windows、macOS 都内置了系统代理设置项,浏览器、部分下载工具、IDE 的网络组件会读取这一配置。而 TUN 模式则完全是另一套思路,它在系统内部创建一张虚拟网络接口(Virtual Network Interface),操作系统会把这张虚拟网卡当成一条真实的网络出口,所有经过路由表判断应该走这条出口的 IP 数据包,不管来自哪个进程、使用什么协议,都会先流入这张虚拟网卡,再由 Clash 内核解析、匹配规则、转发到对应节点。

系统代理:轻量但天生有缝隙

系统代理的优点是配置简单、资源占用低、开关灵活,大多数人第一次接触 Clash 都是先用这种方式。它的工作机制建立在应用程序主动"配合"的基础上:程序内部要读取系统或环境变量里的代理地址,然后自己去连接这个地址完成请求转发。这意味着只有遵守这套约定的程序,流量才会被正确接管。

问题也正出在这里。并不是所有联网程序都会读取系统代理设置,常见的绕过情况包括:

  • 部分命令行工具或后台服务不读取系统代理环境变量,需要额外手动设置 HTTP_PROXY/HTTPS_PROXY。
  • 某些应用采用硬编码的直连逻辑,或使用非标准端口通信,系统代理设置对其完全无效。
  • UDP 协议的流量(例如部分实时通信、游戏加速场景)往往不在系统代理的接管范围内,系统代理主要针对 TCP 层面的 HTTP/HTTPS 请求设计。
  • 移动端应用生态更为分散,不少 App 直接使用系统底层网络库发起连接,跳过应用层代理配置。

换句话说,系统代理更像是一份"君子协定":配合的程序会老实转发,不配合的程序照样直连出去。这也解释了为什么有些用户明明开着 Clash,某个客户端依然显示"未连接代理"或者访问结果与预期不一致——问题往往不在规则写错了,而在这个程序压根没走系统代理这条路。

TUN 模式:在网络层统一接管

TUN 模式的思路更彻底。它不依赖应用程序是否"愿意"配合,而是在操作系统的网络协议栈层面插入一张虚拟网卡,并配合路由表规则,把设备上几乎全部符合条件的 IP 数据包都导向这张虚拟接口。数据包进入虚拟网卡后,由 Clash Meta(mihomo)内核在用户态完成协议解析(常见实现基于 gVisor 或系统原生栈两种协议栈模式)、域名匹配、规则判断,再决定走哪个代理节点或直连。

因为接管发生在网络层而不是应用层,TUN 模式几乎不挑应用程序,无论是浏览器、命令行工具、游戏客户端还是系统自身的后台服务,只要它产生的流量符合路由规则,都会被统一纳入管理,包括原本系统代理管不到的 UDP 流量。这也是为什么很多需要精细分流游戏、语音通信、跨平台客户端的用户,最终都会转向 TUN 模式。

注意

TUN 模式需要创建虚拟网卡,这一操作通常需要系统管理员权限(Windows 下需以管理员身份运行,macOS/Linux 下涉及网络扩展或 root 权限),首次启用时系统可能弹出授权提示,属于正常现象。

兼容性与稳定性的现实差异

覆盖范围更广并不意味着 TUN 模式没有代价。由于流量在网络层被截获并送入用户态协议栈处理,再转发出去,数据包要经历更多一层封装与解析,理论上会带来轻微的性能开销,在低性能设备或对延迟极度敏感的场景下可能有感知差异。此外,虚拟网卡与本机路由表、防火墙规则、VPN 客户端之间存在相互影响的可能:

  • 如果设备上同时运行其他 VPN 软件或虚拟网络工具,可能出现路由表冲突,导致部分流量走向异常,建议避免同时启用多个虚拟网卡类工具。
  • 部分企业内网环境或安全软件会对系统新增的虚拟网络接口进行拦截或告警,首次开启 TUN 模式前建议了解所在网络环境的策略。
  • 不同操作系统对 TUN 设备的实现细节不同,Windows 依赖 Wintun 驱动,macOS 使用系统网络扩展框架,配置入口和权限申请方式略有差异,但对最终用户的开关体验基本一致。

相对地,系统代理没有这些底层风险,配置即时生效、关闭即时恢复,出问题时排查路径也更直观——大概率就是某个程序没读取代理设置。这也是为什么系统代理至今仍是很多轻量场景下的默认选择。

覆盖范围一览对比

对比维度系统代理TUN 模式
工作层级应用层,依赖程序主动读取代理配置网络层,基于虚拟网卡与路由表统一接管
协议覆盖主要覆盖 HTTP/HTTPS,UDP 支持有限覆盖 TCP 与 UDP,几乎不区分协议类型
是否需要额外权限通常无需管理员权限需要管理员/root 权限创建虚拟网卡
兼容性风险低,但存在"绕过代理"的程序存在与其他虚拟网络工具冲突的可能
典型适用场景日常浏览、轻量办公、快速临时使用游戏分流、命令行工具、多进程精细管控

哪些程序容易绕过系统代理

如果发现某个软件的流量始终没有按照代理规则走,大概率属于以下几类:

  1. 命令行与开发工具:例如包管理器、构建工具,很多默认不读取系统代理,需要单独配置环境变量或工具自带的代理选项。
  2. 使用自有网络栈的客户端:一些即时通信、云盘同步类软件为了追求连接速度,自行实现了网络请求逻辑,不经过系统代理接口。
  3. 游戏与语音通信:大量游戏使用 UDP 进行实时数据传输,系统代理对 UDP 的支持普遍薄弱或缺失,这类流量基本只能靠 TUN 模式接管。
  4. 系统后台服务与更新组件:操作系统自身的更新检查、遥测上报等后台进程通常不走用户配置的代理。

遇到这类问题时,与其逐个排查每个程序的代理设置入口,不如直接切换到 TUN 模式,从网络层一次性解决"接管不全"的问题。

什么场景下应该切换到 TUN 模式

结合上面的对比,可以给出一个相对清晰的判断标准:

  • 如果只是日常浏览网页、处理少量应用的代理需求,系统代理已经足够,配置也更省心。
  • 如果设备上运行着大量不遵守系统代理约定的程序(命令行工具、游戏、部分聊天软件),或者需要对 UDP 流量做规则分流,TUN 模式是更彻底的解决方案。
  • 如果需要按进程做精细化分流(例如让某个应用直连、其余走代理),TUN 模式配合 Clash Meta(mihomo)的进程规则(process-name)能实现应用层面无法做到的粒度。
  • 在企业网络、安全软件较为严格的环境中,建议先确认虚拟网卡是否会被拦截,再决定是否启用 TUN 模式,避免影响正常办公网络。
建议

大多数客户端支持系统代理与 TUN 模式共存或快速切换,可以先用系统代理验证节点与规则是否正常工作,确认无误后再开启 TUN 模式扩大覆盖范围,这样排查问题时思路更清晰。

配置上的实际差异

从配置文件角度看,系统代理不需要在 Clash 配置里额外声明,由客户端界面上的一个开关直接调用系统 API 完成;TUN 模式则通常需要在配置文件中显式声明相关字段,例如启用状态、协议栈类型、是否接管 DNS 等。以 Clash Meta(mihomo)的常见写法为例:

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

auto-route 决定是否自动配置路由表将流量导入虚拟网卡,dns-hijack 则用于接管 DNS 查询,避免部分域名解析绕开规则匹配。这些字段大多数图形化客户端已经封装成了界面上的简单开关,普通用户无需手写配置文件,但了解其含义有助于排查偶发的连接异常。

常见疑问简答

开启 TUN 模式后还需要系统代理吗?一般不需要同时开启,TUN 模式的覆盖范围已经包含系统代理能处理的部分,同时开启容易造成路由判断混乱,建议二选一。

TUN 模式会不会让所有流量都变慢?额外的封装解析确实存在开销,但在多数现代设备上这一开销并不明显,更多情况下网速差异来自代理节点本身的线路质量,而不是接管方式。

手机端也有 TUN 模式吗?Android 端通常通过 VpnService 接口实现类似效果,概念上与桌面端的虚拟网卡思路一致,同样能接管应用层无法处理的流量;iOS 端则依赖网络扩展框架实现同类能力。

下载客户端