TUN 模式与系统代理有什么区别:流量接管机制逐层拆解
很多人把这两者当成"设置里的两个开关",切换全凭手感。系统代理靠应用主动读取配置去连接代理端口,TUN 在网络层截获数据包,不管应用愿不愿意。这一层差异决定了覆盖范围、DNS 行为、以及踩坑时该往哪查。
两种机制先分清:它们各自在哪一层工作
要理解区别,先得知道网络请求从应用发出到真正上网,中间经过几层。系统代理和 TUN 模式接管的不是同一层,这是所有表现差异的根源。
系统代理工作在应用层。操作系统提供一个"代理设置"接口,浏览器、终端工具、部分桌面应用会读取这个设置,把自己的网络请求主动转发到指定的代理端口。这个转发行为是应用自己实现的,操作系统只负责存这份配置、告诉想读的人。
TUN 模式工作在网络层,更准确说是在 IP 数据包这一级。Clash Meta(mihomo)开启 TUN 后,会在系统里创建一张虚拟网卡,再通过修改路由表,把默认路由指向这张虚拟网卡。此后所有走 IP 协议出去的数据包,不管来自哪个进程,都会先经过这张虚拟网卡,被内核转交给 Clash 处理,再按规则决定直连还是走代理节点。
一句话概括:系统代理是"设置摆在那,应用自己来读";TUN 是"路由改了,包想走别处都绕不开"。
系统代理:应用自觉遵守的委托机制
系统代理的落地方式在不同操作系统上略有差异,但核心逻辑一致:
- Windows / macOS 图形界面——系统提供全局代理设置项,Clash 客户端开启"设置为系统代理"后,会把这项配置写入系统偏好,主流浏览器和大部分现代应用默认读取它。
- 命令行终端——认的是
http_proxy、https_proxy这类环境变量,系统层面的代理设置对终端往往不生效,需要单独 export。 - PAC 脚本——部分客户端用 PAC(Proxy Auto-Config)文件动态判断域名走不走代理,浏览器加载这个脚本按规则决定路径。
这套机制的前提是"应用愿意配合"。如果一个程序内部硬编码了连接地址,或者压根不检查系统代理设置(常见于一些游戏、更新服务、后台守护进程),系统代理对它无效,流量照样直连出去。这也是为什么开了系统代理,浏览器分流正常,某些客户端软件却始终连不上代理节点——它没在"自觉遵守"的那一批里。
系统代理对新开的进程立即生效,但已经运行中、且在启动时就缓存了网络配置的程序,有时需要重启该程序才能读到新的代理设置。排查"代理开了但某个软件不走"时,先试重启这个软件,再往下查规则。
TUN 模式:网络层建虚拟网卡,全量接管
TUN 模式不依赖应用配合,它改变的是数据包离开设备之前必经的路径。开启后大致发生这几步:
- Clash Meta(mihomo)内核创建一张虚拟网络接口(常见命名如
utun、Meta),这张网卡在系统里等同于一张真实的网络适配器。 - 修改本机路由表,把默认路由(或指定网段)指向这张虚拟网卡,优先级高于原有的物理网卡路由。
- 系统内核按路由表转发数据包时,匹配到默认路由的流量会先送到虚拟网卡,再由 Clash 进程读取、解析、按规则处理。
- 处理完的流量再从代理节点或直连出口发出,回包按原路径送回发起进程,进程本身感知不到这一整套转发过程。
因为接管发生在路由这一层,所有走 IP 协议的流量都会被截获——不区分浏览器、命令行工具、系统后台服务,也不需要它们支持代理设置。这正是 TUN 模式最大的价值:处理那些"不听话"的进程流量。
代价也很直接:虚拟网卡涉及系统底层网络栈,权限要求更高(Windows 上通常需要以管理员身份运行或授权驱动,macOS 上需要系统扩展或 root 权限的服务模式辅助),配置出错时故障面也更宽——路由表冲突、和其他 VPN 软件抢默认路由、防火墙拦截虚拟网卡流量,都是 TUN 模式特有的排查项,系统代理模式基本不会遇到。
DNS 处理:两种机制分歧最大的一环
DNS 解析该走代理还是走本地,是两种机制表现差异最明显的地方,也是新手最容易困惑的一环。
系统代理模式下,DNS 请求通常不经过 Clash——它只接管应用主动发起的 TCP/HTTP 连接,域名解析这一步很多时候仍走本机原有的 DNS 服务器完成,解析结果再拿去连代理。这意味着 DNS 查询本身可能暴露给本地网络运营商,而且如果本地 DNS 被污染,解析出的地址错误,连接照样会失败或者连错服务器。
TUN 模式下,Clash Meta(mihomo)可以接管 DNS 请求本身,常见做法是启用 fake-ip:内核给域名临时分配一个假的 IP 段,应用拿着这个假 IP 去连接时,Clash 在网络层识别出这是哪个域名对应的连接,再按规则匹配代理或直连,真实解析在代理端完成。这样一来,DNS 查询和后续连接都在 Clash 的掌控范围内,域名污染基本不会影响到判断结果。
| 对比项 | 系统代理 | TUN 模式 |
|---|---|---|
| 接管层级 | 应用层,需应用配合 | 网络层,基于路由表 |
| 覆盖范围 | 支持代理设置的应用 | 全部 IP 流量,进程无感 |
| DNS 处理 | 多数情况走本地解析 | 可用 fake-ip 全量接管 |
| 权限要求 | 普通用户权限即可 | 需管理员权限或系统服务 |
| 典型故障面 | 某应用不读取系统设置 | 路由冲突、虚拟网卡异常 |
覆盖范围对比:哪些流量会漏
实际使用中最常被问的问题是"为什么开了代理,还是有些东西没走代理"。答案往往取决于用的是哪种机制。
系统代理模式下容易漏的典型场景:
- 命令行工具(
curl、git、包管理器)不认系统代理,只认环境变量,没单独设置就会直连。 - 部分桌面客户端(即时通讯、下载工具、游戏更新器)内部走自己的网络栈,不检查系统代理设置。
- 系统级后台服务(自动更新、遥测上报)通常不受用户级代理设置约束。
TUN 模式下,上述场景基本都能被接管,因为路由层不区分进程身份。但 TUN 模式也有自己的"漏"——如果规则里把某个网段设置为直连(比如局域网段),或者虚拟网卡的路由优先级被其他网络工具(如某些 VPN 客户端、虚拟机网卡)抢占,流量同样会绕开 Clash。这类问题的排查方向是路由表和网卡优先级,而不是应用设置。
该用哪种:场景与切换建议
不是"哪个更好",而是"当前需求匹配哪个"。给几条实用判断:
- 日常浏览器为主、偶尔用几个常见工具——系统代理够用,配置简单,出问题时排查范围也小,先从这个模式开始更稳妥。
- 需要覆盖命令行工具、游戏、后台服务等不支持代理设置的程序——上 TUN 模式,这是它存在的核心意义。
- 已经在用其他 VPN 或有虚拟网卡冲突历史——优先排查路由表再决定是否开 TUN,避免两套网络接管机制抢路由导致连接抖动。
- 对 DNS 污染敏感、担心域名解析泄露——TUN 模式配合 fake-ip 更彻底,系统代理这条链路管不到 DNS 查询本身。
两种模式并非互斥,大多数客户端支持随时切换,遇到某个场景下行为异常,先确认当前用的是哪种接管机制,再对照上面的差异表定位问题,比盲目重装或换节点效率高得多。
排查连接异常的第一步,永远是先确认自己开的是系统代理还是 TUN——这两种机制的故障现场完全不同,搞混了方向,后面查什么都是白费功夫。