TUN 模式 vs 系统代理：原理与选择

代理软件
8k 词

摘要：代理客户端通常提供两种工作模式：系统代理和 TUN 模式。两者的核心区别在于流量的捕获方式——系统代理只能捕获部分应用的流量，TUN 模式则接管整个系统的网络。本文解释两者的工作原理、优劣和选择建议。

为什么需要理解这个区别

很多用户第一次用代理客户端时，打开软件、导入订阅、选好节点，以为就万事大吉了。结果发现：浏览器能翻墙了，但某个游戏的网络还是卡；或者命令行里 git clone 一个 GitHub 仓库，速度依然慢得像蜗牛。

问题往往出在工作模式的选择上。代理客户端（Clash Verge Rev、sing-box 等）默认使用的是”系统代理”模式。这个模式并不能捕获所有应用的网络流量。要理解哪些流量被捕获、哪些被遗漏，就需要搞清楚系统代理和 TUN 模式各自的工作原理。

系统代理（System Proxy）

工作原理

系统代理的本质是修改操作系统的代理设置。在 Windows 上，它写入的是注册表中 Internet Settings 下的 ProxyServer 值；在 macOS 上，它修改的是”网络偏好设置”中的代理配置；在 Linux 上，它依赖的是 http_proxy、https_proxy 等环境变量。

具体流程如下：

  1. 代理客户端在本地启动一个 HTTP/SOCKS 代理服务器，监听在某个端口上，比如 127.0.0.1:7890
  2. 修改操作系统的代理设置，告诉系统”所有 HTTP/HTTPS 请求应该发送到 127.0.0.1:7890 这个地址”
  3. 应用程序读取系统代理设置，在发起网络请求时，不再直接连接目标服务器，而是先连接到本地代理端口
  4. 代理客户端接收请求，根据分流规则判断走代理还是直连，再转发到对应的目标

这个机制有一个关键前提：应用程序必须主动读取并尊重操作系统的代理设置。操作系统并不会在网络层面强制所有流量走代理，它只是”通知”应用程序有一个代理可用。至于应用程序是否使用这个代理，完全取决于应用自身的实现。

哪些流量会被捕获

理解了系统代理的工作原理后，就能推断出哪些流量会被捕获、哪些不会：

会被捕获的流量：

  • 浏览器（Chrome、Edge、Firefox）：所有主流浏览器都会读取系统代理设置，这是最可靠的场景
  • 大多数现代 GUI 应用程序：包括 Electron 框架开发的应用（VS Code、Slack、Discord 等），因为 Electron 底层使用的是 Chromium 的网络栈，天然支持系统代理
  • 部分命令行工具：curl 默认读取 http_proxy / https_proxy 环境变量；git 可以通过 http.proxy 配置走代理；npm 支持 proxy 配置项

不会被捕获的流量：

  • 游戏客户端：绝大多数游戏使用自己的网络库直接建立 TCP/UDP 连接，不会读取系统代理设置。这也是”开了代理但游戏还是卡”的根本原因
  • 系统级连接：Windows Update、时间同步、微软账户验证等系统服务通常不走系统代理
  • UDP 流量：HTTP 代理只支持 TCP 协议。虽然 SOCKS5 协议理论上支持 UDP，但很少有应用原生支持 SOCKS5 代理，更不用说通过 SOCKS5 转发 UDP
  • 某些桌面应用程序：部分原生应用（尤其是使用底层 socket API 开发的应用）会绕过系统代理，直接发起网络连接
  • DNS 请求：应用程序的 DNS 查询通常由操作系统的 DNS 解析器处理，不经过 HTTP 代理。这意味着即使 HTTP 请求走了代理，DNS 查询可能仍然暴露在外，造成 DNS 泄漏

优势

  • 轻量级：不需要创建虚拟网卡，不会修改系统的网络栈，对系统的侵入性最小
  • 无需管理员权限：普通用户权限即可运行，不需要以管理员身份启动客户端
  • 兼容性好：不会与 VPN 软件、虚拟机网络适配器产生冲突
  • 排障简单：流量路径清晰，出问题时容易定位——如果某个应用不走代理，大概率是该应用不读取系统代理设置
  • 应用程序可选择性绕过：某些应用可以手动配置是否使用代理，灵活性高

劣势

  • 覆盖面有限：无法捕获不读取系统代理的应用流量，这是最核心的限制
  • 不支持 UDP：HTTP 代理只能处理 TCP 流量，游戏、VoIP 通话、QUIC 协议等依赖 UDP 的场景无法工作
  • DNS 泄漏风险：DNS 查询不经过代理，ISP 或 GFW 可以看到你在查询哪些域名
  • 对命令行工具支持不一致：不同的 CLI 工具对代理的支持方式不同，有些需要设环境变量，有些需要单独配置，有些根本不支持

TUN 模式

工作原理

TUN 模式的工作层级与系统代理完全不同。它工作在操作系统的网络栈层面，通过创建一个虚拟网络适配器（TUN 设备）来拦截系统的所有网络流量。

具体流程如下：

  1. 代理客户端请求管理员权限，创建一个 TUN 虚拟网卡。在 Windows 上，这通常表现为一个名为 Wintun 或 WireGuard Tunnel 的虚拟网络适配器；在 macOS / Linux 上，它是一个 utun / tun0 设备
  2. 修改系统路由表，将默认路由（0.0.0.0/0）指向这个虚拟网卡。这意味着系统中所有的出站网络流量，无论来自哪个应用、使用什么协议，都会先流经这个虚拟网卡
  3. 代理客户端在 IP 层（OSI 第三层）接收所有数据包，解析出 TCP/UDP 连接信息，根据分流规则决定走代理还是直连
  4. 走代理的流量被封装后通过代理隧道发送到远端代理节点；直连的流量则通过真实网卡直接发出

由于 TUN 工作在 IP 层，它能看到操作系统发出的每一个网络数据包，不依赖应用程序是否”配合”。这从根本上解决了系统代理的覆盖面问题。

哪些流量会被捕获

简短的答案：所有流量。

  • 所有应用程序——浏览器、游戏、命令行工具、系统服务、后台进程，无一例外
  • 所有协议——TCP、UDP、ICMP，只要是 IP 层之上的协议都会被捕获
  • 所有端口——不仅仅是 80/443，任何端口的流量都会经过 TUN 设备
  • DNS 查询——系统发出的 DNS 请求（通常是 UDP 53 端口）也会被 TUN 捕获，代理客户端可以完全接管 DNS 解析过程

这就是 TUN 模式被称为”全局代理”的原因——它真正做到了”全局”，不留死角。

TUN 协议栈（Stack）选项

TUN 设备接收到的是原始 IP 数据包，需要一个 TCP/UDP 协议栈来将这些数据包还原为应用层的连接。目前主流实现提供以下几种协议栈选项：

gVisor（推荐）：

gVisor 是 Google 开发的用户态网络栈，它在用户空间完整实现了 TCP/UDP 协议处理。代理客户端不依赖操作系统内核的网络栈，而是自己解析和管理 TCP 连接状态。

  • 优势：稳定性高，与系统网络栈隔离，不会因为内核网络模块的 bug 或策略导致异常行为；跨平台一致性好
  • 劣势：性能开销比直接使用系统内核栈略高，CPU 占用略大
  • 适用场景：日常使用推荐，稳定性优先

system（系统内核栈）：

直接利用操作系统内核的 TCP/UDP 协议栈处理数据包。代理客户端将 TUN 接收到的数据包通过系统 socket API 转发，内核负责协议处理。

  • 优势：性能最高，CPU 开销最低，因为协议处理由经过高度优化的内核代码完成
  • 劣势：在某些操作系统或网络环境下可能出现兼容性问题；与系统网络栈耦合度高，排障更困难
  • 适用场景：对性能有较高要求的场景，如高带宽下载、游戏加速

mixed（混合模式，sing-box 特有）：

TCP 连接使用 system 栈（追求性能），UDP 连接使用 gVisor 栈（追求稳定性）。这是一个折中方案——TCP 流量通常是大头（网页浏览、文件下载），用 system 栈提升性能；UDP 流量（DNS、游戏、VoIP）用 gVisor 栈保证兼容性。

优势

  • 真正的全局代理：所有应用、所有协议、所有端口的流量都会被捕获，不存在遗漏
  • 完整的 UDP 支持：游戏、VoIP 通话、QUIC 协议（HTTP/3）、视频会议等 UDP 密集型应用都能正常工作
  • 完全控制 DNS：DNS 查询被 TUN 设备捕获后，由代理客户端统一处理，彻底杜绝 DNS 泄漏
  • 无需逐个配置应用：不需要为每个应用单独设置代理，开启 TUN 后所有应用自动走代理/分流

劣势

  • 需要管理员权限：创建虚拟网卡和修改路由表需要 root / 管理员权限，客户端通常需要以管理员身份运行
  • 可能与其他网络软件冲突：TUN 设备会修改系统路由表，可能与已有的 VPN 客户端（如 WireGuard、OpenVPN）、虚拟机软件（VMware、VirtualBox 的 Host-Only / NAT 网络）产生路由冲突
  • 资源开销略高：运行用户态协议栈（如 gVisor）会增加 CPU 和内存消耗，在低端设备上可能有感知
  • 局域网服务可能受影响：所有流量都经过 TUN 设备，包括局域网内的通信。如果配置不当，可能导致网络打印机、NAS、局域网文件共享、mDNS 设备发现等功能失效
  • 排障难度更高：流量路径涉及虚拟网卡、路由表、协议栈等多个环节，出问题时排查更复杂
  • 杀毒软件误报：某些杀毒软件会将创建虚拟网卡、修改路由表的行为标记为可疑操作

Clash Verge TUN vs sing-box TUN：实现差异

目前桌面端最常用的两个 TUN 实现分别来自 Clash Verge Rev（基于 mihomo 内核）和 sing-box。两者在 TUN 实现上有一些值得了解的差异。

Clash Verge Rev（mihomo 内核）

mihomo（前身为 Clash.Meta）的 TUN 实现经过多年迭代，其配置细节可参考 Clash Wiki。它，稳定性和兼容性在社区中得到了广泛验证。

  • 与规则系统深度集成：mihomo 的 TUN 模块和规则引擎是一体化设计的，流量从 TUN 捕获到规则匹配再到分流转发的链路非常紧密，配置也更直观
  • 协议栈选项：支持 gVisor（默认）和 system 两种
  • 配置简单：在 Clash Verge Rev 的 GUI 中，开启 TUN 只需一个开关。默认的 gVisor 栈对绝大多数用户来说就是最佳选择
  • 社区资源丰富：大量的中文教程、配置模板和排障指南

sing-box

sing-box 的 TUN 实现是独立设计的，在某些技术细节上与 mihomo 有所不同。

  • 协议栈选项更多：除了 gVisor 和 system 之外，还提供 mixed 模式，在 TCP 性能和 UDP 稳定性之间取得平衡
  • 部分边缘场景处理更好：社区反馈 sing-box 的 TUN 在处理某些特定游戏的 UDP 连接、以及某些不常见的网络协议时，兼容性略优
  • 性能表现：sing-box 整体设计注重性能，TUN 模块的吞吐量基准测试结果通常略优于 mihomo
  • 配置灵活但门槛更高：sing-box 使用 JSON 配置文件，灵活性强，但对新手不太友好

实际体验差异

对于绝大多数用户来说，两者的 TUN 实现在日常使用中的差异几乎感知不到。浏览网页、看视频、日常办公的场景下，两者表现基本一致。

差异主要体现在以下边缘场景：

  • 某些特定游戏：少数游戏的 UDP 连接处理方式比较特殊，可能在一个实现下正常、另一个下异常。这类情况无法一概而论，需要实际测试
  • 高带宽场景：在千兆以上的带宽环境下，system 栈和 gVisor 栈之间的性能差异可能变得可感知
  • 与特定 VPN 软件共存：不同的 TUN 实现在路由表管理上的策略不同，可能导致与第三方 VPN 的兼容性差异

结论：选择的依据应该是你更偏好哪个客户端的整体体验（GUI、配置方式、规则管理、社区生态），而不是纠结于 TUN 实现本身的微小差异。如果你追求简单易用，Clash Verge Rev 是更好的选择；如果你偏好灵活配置且不怕折腾，sing-box 值得尝试。

怎么选？

以下决策流程可以帮助你快速判断应该使用哪种模式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
你需要代理游戏、VoIP 或其他 UDP 应用吗？
├── 是 → 必须用 TUN 模式（系统代理不支持 UDP）
└── 否 ↓

    你是否在意部分应用可能绕过代理？
    ├── 在意（比如担心 DNS 泄漏、某些应用不走代理） → TUN 模式
    └── 不在意（只要浏览器能翻墙就行） → 系统代理足够
    
你的设备上是否运行了 VPN 软件或虚拟机？
├── 是 → 可能与 TUN 冲突，建议先试系统代理
└── 否 → TUN 模式通常没有问题

你的设备性能是否有限（老电脑、低端设备）？
├── 是 → 系统代理更轻量
└── 否 → TUN 模式的额外开销可以忽略

一般建议：先用系统代理模式。如果你发现有应用无法通过代理访问，或者需要游戏/UDP 支持，再切换到 TUN 模式。对于大多数只在浏览器中使用代理的用户，系统代理已经够用了。

配置指南

Clash Verge Rev 开启 TUN 模式

  1. 打开 Clash Verge Rev，进入”设置”页面
  2. 找到”TUN 模式”开关，点击开启
  3. 系统会弹出 UAC 提示（Windows）或要求输入密码（macOS / Linux），授权管理员权限
  4. 推荐使用默认的 gVisor 协议栈，除非你有明确的性能需求

对应的 mihomo 配置片段：

1
2
3
4
5
6
7
tun:
  enable: true
  stack: gvisor       # 推荐 gvisor，追求性能可用 system
  dns-hijack:
    - any:53          # 劫持所有 DNS 请求
  auto-route: true    # 自动配置路由表
  auto-detect-interface: true  # 自动检测出站网卡

关键参数说明：

  • stack：协议栈选择。gvisor 稳定性优先，system 性能优先
  • dns-hijack：劫持 DNS 请求，确保所有 DNS 查询都由代理客户端处理，防止 DNS 泄漏
  • auto-route：自动将默认路由指向 TUN 设备，无需手动配置路由表
  • auto-detect-interface：自动检测物理网卡，确保代理客户端自身的出站流量不经过 TUN（避免死循环）

局域网绕过配置

开启 TUN 后，局域网流量也会被 TUN 捕获。如果你需要访问局域网内的设备（打印机、NAS、本地服务器等），需要在分流规则中添加直连规则：

1
2
3
4
5
6
7
8
9
rules:
  - IP-CIDR,192.168.0.0/16,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT
  - IP-CIDR,100.64.0.0/10,DIRECT  # CGNAT 地址段
  - IP-CIDR,169.254.0.0/16,DIRECT  # 链路本地地址
  - IP-CIDR,224.0.0.0/4,DIRECT     # 多播地址
  - IP-CIDR,255.255.255.255/32,DIRECT  # 广播地址

大多数机场提供的订阅配置已经包含了这些规则。如果你发现开启 TUN 后无法访问局域网设备，首先检查配置中是否缺少上述直连规则。

常见问题排查

TUN 模式无法正常工作

按以下顺序检查：

  1. 管理员权限：确认代理客户端是否以管理员身份运行。Windows 用户可以右键客户端 → “以管理员身份运行”；也可以在客户端设置中开启”以管理员身份运行”选项
  2. VPN 软件冲突：检查是否有其他 VPN 客户端正在运行（如 WireGuard、OpenVPN、公司 VPN）。多个 VPN / TUN 设备同时运行几乎必然导致路由冲突。解决方法是关闭其他 VPN，或将代理客户端切换到系统代理模式
  3. 虚拟机软件冲突：VMware 和 VirtualBox 的虚拟网络适配器可能与 TUN 设备的路由规则冲突。如果使用虚拟机，尝试在虚拟机网络设置中切换到”桥接模式”
  4. 杀毒软件拦截：某些杀毒软件（尤其是国内的安全软件）可能阻止创建虚拟网卡。尝试在杀毒软件中添加代理客户端的白名单

开了 TUN 后局域网设备找不到

TUN 模式会捕获所有出站流量，包括发往局域网的流量。局域网设备发现协议（如 mDNS、SSDP、NetBIOS）依赖多播和广播，这些流量经过 TUN 后可能被代理客户端错误处理。

解决方法：

  • 确保分流规则中包含局域网 IP 段的直连规则（见上文”局域网绕过配置”部分）
  • 在 Clash Verge Rev 中检查”绕过”设置，确认局域网地址段已被排除
  • 如果问题仍然存在，考虑切换到系统代理模式来排除 TUN 层面的问题

CPU 占用过高

TUN 模式下 CPU 占用异常升高，通常与协议栈选择有关：

  • gVisor 栈在高带宽场景下 CPU 占用较高：如果你在进行大文件下载或高速传输，gVisor 的用户态协议栈需要处理大量数据包，CPU 开销会显著增加。解决方法是切换到 system 栈
  • 规则匹配效率：如果你的分流规则数量过多（数万条），每个数据包都需要匹配规则，也会增加 CPU 负担。检查是否加载了过多的规则集

常见问题

Q: TUN 模式会让网速变慢吗？

理论上 TUN 模式引入了一层额外的处理：数据包需要经过虚拟网卡 → 用户态协议栈 → 代理客户端 → 真实网卡，比系统代理多了一些环节。但在实际使用中，这个开销几乎感知不到。现代处理器处理网络数据包的速度远远高于家用带宽的速率，瓶颈几乎总是在代理节点的带宽和延迟上，而不是在 TUN 本身。

如果你感觉开了 TUN 后速度明显下降，问题大概率出在节点质量或规则匹配上，而非 TUN 模式本身。

Q: 可以同时开启系统代理和 TUN 模式吗？

不建议。两种模式是互斥的工作方式。同时开启可能导致流量被重复处理——数据包先被系统代理捕获一次，再被 TUN 设备捕获一次，造成处理混乱、性能下降，甚至连接失败。

大多数代理客户端在开启 TUN 时会自动关闭系统代理。如果你的客户端没有自动处理，请手动关闭系统代理后再开启 TUN。

Q: 手机上也有 TUN 模式吗？

是的，但实现方式有所不同。iOS 和 Android 上的代理客户端（如 Shadowrocket、Surge、sing-box 等）通过系统提供的 VPN API 来实现类似 TUN 的效果。

当你在手机上开启代理客户端时，系统会显示一个 VPN 图标——这正是因为客户端创建了一个 VPN 隧道来捕获所有流量。从效果上看，手机上的代理客户端默认就是”全局捕获”的工作模式，等同于桌面端的 TUN 模式。因此，手机用户通常不需要额外考虑”系统代理 vs TUN”的选择问题。

Q: 为什么我开了 TUN 后打印机/局域网设备找不到了？

TUN 模式捕获了所有出站流量，包括原本应该在局域网内部传递的流量。网络打印机、NAS、智能家居设备等局域网设备的发现和通信依赖于局域网内的多播、广播以及对特定 IP 段（如 192.168.x.x、10.x.x.x）的直接访问。

当这些流量被 TUN 设备捕获后，代理客户端可能将它们视为需要代理的流量，导致局域网通信失败。解决方法是在代理配置的分流规则中，将所有私有网络地址段（RFC 1918 定义的 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）设置为直连（DIRECT）。

Q: TUN 模式下如何让某个应用不走代理？

在 TUN 模式下，所有流量都被捕获，但你仍然可以通过分流规则来控制特定流量的去向。两种常见做法：

  1. 基于进程名的规则（mihomo 支持）：PROCESS-NAME,app.exe,DIRECT，直接指定某个进程的流量走直连
  2. 基于目标 IP / 域名的规则：如果你知道某个应用访问的目标地址，可以为该地址添加直连规则

在 Clash Verge Rev 中，也可以通过”绕过”列表来排除特定的 IP 段或进程。

一图总结

对比维度 系统代理 TUN 模式
工作层级 应用层（依赖应用配合） IP 层（系统级别强制）
流量覆盖 部分应用 所有应用
协议支持 仅 TCP（HTTP/SOCKS） TCP + UDP + ICMP
DNS 控制 无（DNS 可能泄漏） 完全控制
权限要求 普通用户权限 管理员/root 权限
系统侵入性 低（修改代理设置） 高（虚拟网卡 + 路由表）
VPN 冲突风险 低 高
配置复杂度 低 中等
适合场景 浏览器翻墙、日常办公 游戏、全局代理、防 DNS 泄漏

选择的核心逻辑很简单：如果系统代理能满足需求就用系统代理，如果不能就上 TUN。不需要过度追求”全局”——很多用户只在浏览器里用代理，系统代理完全够用。只有当你遇到了系统代理无法覆盖的场景（游戏、UDP、DNS 泄漏等），TUN 模式才是必要的。