系统代理接管不了的流量,TUN 能接管
先说清楚一个常被混用的概念区分:系统代理(System Proxy)和 TUN 模式解决的是同一个问题的两种不同层面。系统代理的原理是修改操作系统或浏览器读取的代理配置项——像 Windows 的"网络和 Internet"设置里那个 HTTP/HTTPS 代理地址,或是环境变量 HTTP_PROXY/HTTPS_PROXY。软件如果遵守这套约定、主动去读代理设置,流量就会被转发到 Clash 监听的端口;但如果软件不读、或者用的是自己写死的连接方式(常见于部分游戏客户端、命令行工具、某些 UWP 应用、系统更新服务),系统代理就管不到它。
TUN 模式换了一种思路:它不再"劝说"软件走代理,而是在操作系统网络栈里创建一张虚拟网卡(Virtual Network Adapter),然后把系统默认路由指向这张虚拟网卡。这样一来,所有出站流量——不管是浏览器、后台服务、还是不认识代理设置的程序——都会先经过这张虚拟网卡,再由 Clash(或 Clash Meta / mihomo 内核)在用户态读取、解析、按规则分流。这就是常说的"全局流量接管":接管的对象是整台设备的网络层,而不是某个应用的应用层设置。
需要澄清一个常见误解:TUN 模式不是"更强力的系统代理",而是完全不同的实现路径。系统代理停留在应用层协议(HTTP/HTTPS CONNECT),TUN 工作在网络层(IP 数据包),因此它能处理任意基于 TCP/UDP 的流量,包括游戏、VoIP、DNS 查询本身。这也是为什么部分场景——比如需要代理 UDP 流量、需要统一处理设备上所有程序——只有 TUN 模式能做到。
虚拟网卡怎么"劫持"流量:三个关键环节
理解 TUN 模式的工作流程,有助于排查后续可能遇到的问题。整个过程可以拆成三个环节:
- 创建虚拟网卡:客户端调用系统底层接口(Windows 上常用 Wintun 驱动,macOS 上是 utun 接口)创建一张名为类似
Clash、utun的虚拟网络适配器,并为其分配一个私有 IP 段。 - 调整路由表:客户端把系统的默认路由或部分路由规则改为指向这张虚拟网卡,同时保留到 Clash 自身进程、到本地网关的直连路由,避免流量绕圈子。
- 用户态转发与分流:操作系统把数据包送进虚拟网卡后,Clash 内核在用户态读取这些 IP 数据包,还原成具体的 TCP/UDP 会话,再按配置文件里的规则(域名匹配、IP 段匹配、GeoIP 等)决定走直连、走某个代理节点,还是直接拒绝。
这也解释了为什么 TUN 模式需要更高的系统权限——修改路由表和创建虚拟网卡在 Windows 上需要管理员权限,在 macOS 上需要 sudo 或系统扩展授权。这不是软件"越权",而是虚拟网卡这项技术本身对操作系统底层资源的必要访问。
开启 TUN 模式前,先确认设备上没有同时运行其他会创建虚拟网卡的软件(如另一个代理工具、某些 VPN 客户端)。两套虚拟网卡同时抢路由表,大概率导致断网或流量绕不出去,建议先完全退出冲突软件再开启 TUN。
Windows 上开启 TUN 模式的完整步骤
不同 Windows 客户端的界面布局略有差异,但核心开关和顺序是一致的,以下按通用流程说明:
- 确认客户端内核是 Clash Meta 或 mihomo(部分老版本 Clash Premium 内核不支持 TUN,升级客户端或切换内核即可)。
- 打开客户端主界面,找到"代理设置"或"网络"面板,定位到 TUN 模式 开关,首次开启时系统通常会弹出安装 Wintun 驱动的提示,点击允许。
- 若客户端提供"服务模式"(Service Mode)选项,建议一并安装。服务模式让 TUN 相关操作以 Windows 服务身份长期驻留后台运行,好处是不需要每次都以管理员身份重启客户端才能开启 TUN,也能避免用户注销登录后 TUN 网卡异常。
- 打开 TUN 开关后,客户端会提示以管理员权限重新启动,确认即可,首次启动可能有 1~2 秒的短暂路由切换感知。
- 切换到"代理模式"面板,确认当前处于规则模式(Rule)而不是全局直连,这样 TUN 接管的流量才会按订阅里的分流规则处理,而不是一股脑全部走代理或全部直连。
控制面板 → 网络和共享中心 → 更改适配器设置
应能看到一张名为 Clash / Mihomo 的虚拟网卡,状态为"已连接"
如果开启后网络适配器列表里没有出现对应的虚拟网卡,大概率是 Wintun 驱动安装失败或被安全软件拦截,可以尝试以管理员身份手动重启客户端一次,或临时关闭第三方安全软件的驱动拦截功能后重试。
macOS 上开启 TUN 模式:系统扩展授权是关键
macOS 从系统层面对创建网络扩展有更严格的审核流程,因此在 macOS 上开启 TUN 模式通常会多一步"系统扩展批准"的环节:
- 在客户端设置中开启 TUN 模式开关,首次开启系统会弹出"系统扩展被阻止"的提示。
- 前往"系统设置 → 隐私与安全性",找到底部提示允许该客户端对应的系统扩展,点击允许。
- 部分 macOS 版本需要重启电脑才能让系统扩展生效,重启后重新打开客户端。
- 再次打开 TUN 开关,客户端会请求管理员密码用于创建 utun 虚拟接口和修改路由表,输入密码确认。
- 开启成功后,可以在终端执行
ifconfig或networksetup -listallnetworkservices查看是否出现utun系列接口。
ifconfig | grep utun
# 正常应能看到类似输出
utun5: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
macOS 上如果反复出现系统扩展被拒绝,先检查"系统设置 → 隐私与安全性 → 安全性"里是否开启了"仅允许来自 App Store 的应用",部分安全策略会连带拦截合法的网络扩展授权请求,需要临时放宽后再重试一次。
验证 TUN 是否真的生效:别只看开关状态
开关变成"开"并不等于流量真的按预期接管了,这里给出两个可靠的验证方法。第一个是看 DNS 解析是否被劫持——TUN 模式下,DNS 查询本身也应该经过 Clash 内核处理,这样才能让基于域名的规则正确命中:
nslookup example.com
# 关注返回结果里的应答服务器地址
# 如果显示的是 Clash 内核在配置里设置的 DNS 监听地址(如 198.18.0.2 等 fake-ip 段)
# 说明 DNS 查询已经被 TUN 接管,而不是直接打到系统原生 DNS
第二个方法是直接在客户端的连接面板或流量面板里观察,开启 TUN 后应该能看到不经过浏览器代理设置的软件(比如系统自带的天气应用、某些命令行工具)的连接记录也出现在列表里。如果打开一个明确不支持系统代理设置的程序,依然完全无法联网或流量没有出现在面板里,说明 TUN 没有真正接管成功,需要回头检查路由表是否被其他软件抢占,或者服务模式是否正常运行。
另外要注意 fake-ip 模式下部分内网访问、局域网设备发现类功能可能受影响,如果同时需要正常访问局域网设备,建议在配置文件里为局域网 IP 段单独设置直连规则,或使用 fake-ip-filter 排除相应域名与地址段,避免内网访问被错误代理。
开启 TUN 后常见的几个问题
- 开启后立刻断网:多数是路由表冲突,先关闭其他可能创建虚拟网卡的软件,重启客户端后重新开启。
- 部分应用无法访问,报证书错误:如果客户端同时开启了 MitM(中间人抓包)相关功能,需要额外安装并信任 Clash 生成的根证书,和 TUN 模式本身无关,可以先在设置里关闭 MitM 相关选项排查。
- Windows 上每次重启电脑都要重新以管理员权限打开一次:说明服务模式没有正确安装,回到设置面板重新安装一次服务组件。
- 局域网内其他设备无法互相发现:检查规则列表中局域网地址段(如 192.168.0.0/16、10.0.0.0/8)是否设置为直连,必要时手动补充规则。
总的来说,TUN 模式解决的是系统代理天生的覆盖盲区问题,原理上依赖虚拟网卡与路由表调整,配置上比开启系统代理多了驱动安装与权限授权两步。理解了这三个环节——创建网卡、调整路由、用户态分流——遇到具体报错时,基本都能对应到某一步排查,而不是盲目重装客户端。