TUN 模式深度解析：全局透明代理的原理与配置

使用 Clash 时，大多数人首先遇到的问题是：为什么开了代理，游戏还是走国内线路？为什么 git clone 不走代理？为什么命令行工具需要单独配置？ 这些问题的根源在于系统代理的工作机制——它并不能覆盖所有应用。TUN 模式是解决这个问题的终极方案，本文带你深度理解它。

系统代理的局限性

「系统代理」模式的工作方式是：通知操作系统"请将 HTTP/HTTPS 请求发送到本地 127.0.0.1:7890"。这种方式存在一个根本限制：只有主动读取系统代理设置的应用程序才会遵循它。

浏览器（Chrome、Firefox、Safari）默认遵循系统代理设置，但以下类型的程序通常不会：

游戏客户端（Steam、Epic Games、各类网游客户端）
命令行工具（git、curl、wget、npm、pip）
Windows UWP 应用（Microsoft Store 安装的应用）
部分 Electron 应用和底层网络库直接调用的程序
几乎所有使用 UDP 协议的程序（包括大多数游戏和视频通话）

此外，系统代理只能代理 HTTP/HTTPS 协议的流量，无法处理原生 TCP 连接和 UDP 流量。这意味着即便是理论上"支持代理"的应用，其 UDP 流量也会绕过代理直接发出。

TUN 模式的工作原理

TUN（Tunnel Network Interface）是操作系统提供的一种 虚拟网卡 接口。与 TAP 接口（工作在链路层）不同，TUN 工作在网络层（IP 层），可以直接读写 IP 数据包。

Clash 的 TUN 模式工作流程如下：

Clash 向操作系统申请创建一块虚拟网卡（通常命名为 Mihomo 或 utun0）。
修改系统路由表，将特定目标 IP 段的出站流量重定向到这块虚拟网卡。
Clash 内核从虚拟网卡读取原始 IP 数据包，解析出目标地址和协议类型。
对于 TCP 流量，Clash 建立一个本地 TCP 连接接收数据，再按规则转发到代理节点或直连；对于 UDP 流量，同理处理。
从代理节点或直连服务器返回的数据，重新封装后写回虚拟网卡，交给操作系统路由到发起请求的应用。

由于是在 网络层 拦截流量，而非应用层，所有程序——无论是否支持代理协议——的出站网络数据包都会被捕获并处理。这就是 TUN 模式能实现真正全局代理的根本原因。

TUN 模式需要创建虚拟网卡并修改系统路由表，这两项操作均需要管理员（Windows UAC 提权）或 Root/sudo（Linux/macOS）权限。这不是程序"要求过高权限"，而是操作系统的安全机制决定的。

fake-ip：TUN 模式的 DNS 解决方案

TUN 模式下，DNS 处理方式变得非常关键，也是最容易出问题的环节。让我们先看传统 DNS 流程：

应用程序 → 查询 DNS: example.com → 获得真实 IP 203.0.113.1 → 向该 IP 发起 TCP 连接

问题在于：当 Clash 在 TUN 层面拦截到一个发往 203.0.113.1 的 TCP 连接请求时，它只看到 IP 地址，不知道这个连接对应的是哪个域名。而 Clash 的规则系统大量依赖域名匹配（DOMAIN-SUFFIX、DOMAIN-KEYWORD），没有域名就无法正确分流。

fake-ip 模式 是解决这个问题的优雅方案：

应用程序发起 DNS 查询 example.com。
Clash 拦截这个 DNS 查询，立即返回一个假 IP（如 198.18.0.1），并在内部记录 198.18.0.1 → example.com 的映射关系。
应用程序拿到假 IP，向 198.18.0.1 发起 TCP/UDP 连接。
Clash 在 TUN 层面拦截到这个连接请求，查询内部映射表，知道目标是 example.com。
Clash 按域名规则决定走代理还是直连。若走代理，由代理节点在目标地完成真正的 DNS 解析；若直连，Clash 会重新查询真实 DNS 后建立连接。

fake-ip 的核心优势在于：敏感域名的 DNS 查询完全在代理节点侧完成，彻底防止 DNS 泄漏；同时由于 Clash 掌握了域名信息，规则匹配准确率大幅提升。

开启 TUN 模式

Clash Verge Rev（Windows / macOS）

打开客户端，点击左侧「设置」图标。
找到「TUN 模式」（或「Tun Mode」）开关，点击开启。
系统弹出权限请求窗口，Windows 点击「是」，macOS 输入系统密码确认。
首次开启会在后台安装虚拟网卡驱动（Mihomo），稍等 5–10 秒。
客户端状态变为「TUN 已激活」，此时所有出站流量均由 Clash 接管。

完整 YAML 配置（Mihomo 内核）

tun:
  enable: true
  stack: mixed        # mixed / system / gvisor
  dns-hijack:
    - any:53          # hijack all DNS queries
  auto-route: true
  auto-detect-interface: true

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"
  nameserver:
    - https://1.1.1.1/dns-query    # Cloudflare DoH
    - https://8.8.8.8/dns-query    # Google DoH
  fallback:
    - https://1.0.0.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

TUN Stack 模式详解

TUN 的 stack 参数决定了如何处理被捕获的网络数据包，直接影响性能、兼容性和稳定性：

mixed（推荐）：TCP 流量使用系统原生网络栈处理，UDP 流量使用 gVisor 用户态实现。在兼容性和性能之间取得最佳平衡，适合绝大多数用户。
system：TCP 和 UDP 全部交给操作系统网络栈处理。性能最优、CPU 占用最低，但在 Linux 某些内核版本上可能有兼容性问题。追求极致性能的服务器场景推荐。
gvisor：TCP 和 UDP 全部在用户空间模拟完整网络栈（Google gVisor 项目）。兼容性最好，能处理所有边缘情况，但 CPU 和内存开销比 mixed 高 20–40%。遇到 mixed 模式出现奇怪问题时可切换尝试。

常见问题与排查

局域网设备（打印机、NAS、路由器后台）无法访问

TUN 模式通过 auto-route 接管了全部流量，局域网 IP 段的流量也会被路由到代理出口，自然无法到达本地设备。在规则文件 最前面 加入以下直连规则即可：

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  # ... 其他规则

关闭 Clash 后网络断开

关闭 Clash 前务必先在设置中关闭 TUN 开关，让程序有机会清理路由表条目。若已断网：重新打开 Clash → 关闭 TUN → 再退出程序。或进入设备管理器（Windows）禁用名为 Mihomo 的虚拟网卡，重启网络即可恢复。

fake-ip-filter 白名单不够用

本地开发域名（如 localhost、*.test）、企业内网域名、部分国内应用（QQ、微信）的特殊服务域名如果经过 fake-ip 处理，可能导致连接失败。将这些域名加入 fake-ip-filter 列表，Clash 会对其进行真实 DNS 解析而非返回假 IP。

TUN 模式开启后 CPU 占用升高

这是正常现象。TUN 模式需要在用户空间处理所有网络数据包，比系统代理模式的 CPU 开销高 10–30%。如果 CPU 占用异常高（超过 20%），尝试：将 stack 从 gvisor 切换到 mixed；检查是否有大量 UDP 流量（如 P2P）正在经过 Clash 处理。

总结

TUN 模式是 Clash 最强大也最完整的代理模式。它通过虚拟网卡在网络层拦截所有流量，配合 fake-ip DNS 机制实现精确的基于域名的分流，彻底解决了系统代理模式覆盖范围有限的问题。

对于日常浏览器使用，系统代理模式已经足够；但如果你需要代理游戏、命令行工具或所有 App 的流量，TUN 模式是不二之选。配置好局域网直连规则和 fake-ip-filter 白名单，TUN 模式可以运行得非常稳定。