Clash TUN 模式原理详解:虚拟网卡如何接管全局流量与开启方法

NT-02.1系统代理为什么"管不全"

Clash 默认的工作方式是系统代理(System Proxy):客户端在系统网络设置里写入 HTTP/HTTPS 代理地址,操作系统把这个地址通知给应用程序,应用程序再决定是否遵守。这个"遵守"是关键——系统代理本质是一份建议,不是强制转发。绝大多数图形界面浏览器、常见聊天工具会读取系统代理设置并照做,但命令行工具(`curl`、`git`、`ping`)、部分游戏、老旧客户端、以及一些安卓/iOS 应用往往绕过系统代理设置,直接用系统底层网络接口发包。

这就带来一个常见现象:浏览器里代理测速正常,能访问目标站点,但终端里 `curl` 同一个地址却直接超时;或者某个应用在设置里勾选了"使用系统代理",实际抓包却发现流量根本没有经过代理端口。这不是配置错误,而是系统代理机制本身的覆盖范围有限——它只能覆盖"愿意读取并遵守"这条设置的进程。

TUN 模式解决的正是这个覆盖范围问题。它不再依赖应用程序"自愿"读取代理设置,而是在操作系统网络栈更底层的位置建立一张虚拟网卡,把系统路由表指向这张虚拟网卡,从而让几乎所有出站流量都无法绕开。

NT-02.2虚拟网卡如何接管流量

TUN(Tunnel,隧道设备)是操作系统提供的一种虚拟网络接口类型,和物理网卡、Wi-Fi 网卡一样会出现在系统的网络接口列表里,拥有自己的 IP 地址,但它背后没有真实的物理链路,收发的数据包直接交给创建它的用户态程序处理。Clash Meta(mihomo 内核)开启 TUN 模式后,会在系统里创建这样一张虚拟网卡,并调整系统路由表,把默认路由或指定网段的流量导向这张虚拟网卡。

此后,应用程序发出的 IP 数据包,不管它是否"知道"有代理这回事,都会先经过系统路由判断,被送到 TUN 虚拟网卡。mihomo 内核在用户态读取这些原始数据包,还原出目标地址与协议信息,按照规则集匹配对应的策略组,再通过真实网络接口转发给选中的节点。回包按原路返回,再由 TUN 网卡交还给发出请求的进程。整个过程对应用程序是透明的——它以为自己在直接和目标服务器通信,实际上每一个包都经过了内核的规则判定。

这也解释了为什么 TUN 模式常被称作"全局透明代理":它工作在网络层,而系统代理工作在应用层协议(HTTP/SOCKS)之上,层级更低意味着覆盖面更广,但也意味着排查问题时思路要切换——不再是看"这个应用有没有代理选项",而是看"这台设备的流量有没有被正确路由"。

NT-02.3开启前要理清的三个配置项

TUN 模式不是一个开关就完事,配置文件里通常涉及以下几项,理解含义能省掉后续大量排查时间。

1. enable:TUN 功能总开关,布尔值。仅开启这一项,虚拟网卡才会被创建。
2. stack:选择用户态网络栈实现,常见取值为 system、gvisor、mixed。不同内核版本对可选值支持不同,一般优先用文档推荐的默认值,遇到兼容性问题再切换对比。
3. dns-hijack:是否在 TUN 层劫持 DNS 查询请求,通常写作监听地址加端口(如 any:53)。这一项和下文的 DNS 处理直接相关,配置不当会导致域名解析异常或规则分流失效。

此外,TUN 模式下的分流判断仍然依赖规则集,和系统代理模式共用同一份 rules 配置,区别只在"流量怎么被送进内核",而不是"内核怎么分流"。也就是说,开启 TUN 不会让原有规则失效,但可能暴露出规则里此前没被系统代理模式覆盖到的流量。

NT-02.4各平台开启步骤

不同客户端的界面入口不同,但底层都是调用 mihomo 内核的 TUN 参数,思路一致。

Windows

1. 确认使用的客户端内核为 Clash Meta / mihomo(部分基于旧 Clash 内核的客户端不支持 TUN)。
2. 在客户端设置里找到"TUN 模式"或"Tun Mode"开关,首次开启通常会弹出管理员权限申请,需允许。
3. 若客户端以非管理员身份启动导致开关无效,需以"以管理员身份运行"重新启动客户端。
4. 开启后可在系统"网络连接"列表里看到新增的虚拟网卡设备,名称通常包含 Mihomo 或 Meta 字样。

macOS

1. 在客户端设置里开启 TUN 模式,系统会弹出"网络扩展"或"系统扩展"授权提示。
2. 前往「系统设置 → 隐私与安全性」或「系统设置 → 网络 → VPN 与过滤器」,手动允许该扩展。macOS 版本不同,弹窗位置略有差异。
3. 授权完成后重新开启 TUN 开关;若客户端安装时已处理过网络扩展权限,这一步通常可以跳过。

Android

1. Android 上 TUN 模式对应系统的 VPN 服务接口,开启时会弹出"连接请求"式的系统授权对话框,点击允许即可。
2. 授权后状态栏会常驻一个 VPN 图标,这是系统级提示,不代表异常。
3. 若同时安装了其他 VPN 类应用,注意系统通常只允许一个 VPN 服务处于激活状态,两者会互相顶替。

Linux

1. 创建 TUN 设备需要 CAP_NET_ADMIN 权限,图形客户端通常需要以 sudo 或授权方式启动核心进程。
2. 命令行运行 mihomo 内核时,若未加权限直接启动,日志会报创建 TUN 设备失败,需检查启动方式。
3. 部分发行版默认启用了防火墙(如 ufw、firewalld),需确认没有额外规则拦截虚拟网卡的转发。

NT-02.5开启后常见问题排查

TUN 模式引入了新的路由层,以下几类问题出现频率较高。

• 开启后完全无法上网:多数是路由表被完全接管,而规则里存在配置错误或核心进程异常退出导致虚拟网卡"占了路由但没转发"。可先关闭 TUN 恢复系统代理验证基础连接,再单独排查 TUN 配置段。
• 部分网段无法访问局域网设备:TUN 模式默认接管全部路由后,访问局域网内的打印机、NAS 等设备可能受影响。需要在规则里为局域网网段(如 192.168.0.0/16、10.0.0.0/8)配置直连(DIRECT)策略,排除在代理路由之外。
• 与其他 VPN 软件冲突:同一台设备上如果还运行着企业 VPN 或其他基于虚拟网卡的工具,两者可能争抢默认路由,表现为间歇性断连或路由跳变,建议同一时间只保留一个虚拟网卡类工具处于激活状态。
• DNS 解析异常:未同步配置 dns-hijack 和 fake-ip 时,域名解析可能仍走本机原有 DNS,导致按域名匹配的分流规则不生效,表现为"能上网但分流不对"。

NT-02.6什么情况下适合用 TUN,什么情况下不必

TUN 模式不是"越全局越好"的选项,是否开启取决于实际需求。

• 需要让命令行工具、开发环境、游戏客户端等非浏览器程序走代理时,TUN 是目前最可靠的方式。
• 日常仅使用浏览器和常见聊天软件,且这些软件都能正确读取系统代理时,继续用系统代理模式更省心,出问题时排查链路也更短。
• 在企业办公网络、已有 VPN 客户端常驻的设备上,谨慎开启 TUN,先确认不会与既有网络策略冲突。
• 移动设备电量与稳定性有一定顾虑时,可先在桌面端验证规则集是否配置妥当,再决定是否在手机上长期开启。

总体上,TUN 模式解决的是"覆盖面"问题,系统代理解决的是"够用就好"的日常场景。理解两者在网络栈层级上的差异,遇到"某个应用没走代理"的问题时,就能快速判断该切到哪种模式,而不是反复重启客户端试错。