--- title: TUN 模式 vs 系统代理：原理与选择 date: 2026-05-10 updated: 2026-05-10 categories: - 代理软件 tags: - TUN - 系统代理 - Clash - Sing-box - 配置 index_img: /images/posts/tun-vs-system-proxy.png excerpt: 系统代理只能捕获部分应用流量，TUN 模式接管整个系统网络。解释两者原理、优劣和选择建议。 --- > **摘要**：代理客户端通常提供两种工作模式：系统代理和 TUN 模式。两者的核心区别在于流量的捕获方式——系统代理只能捕获部分应用的流量，TUN 模式则接管整个系统的网络。本文解释两者的工作原理、优劣和选择建议。 --- ## 为什么需要理解这个区别 很多用户第一次用代理客户端时，打开软件、导入订阅、选好节点，以为就万事大吉了。结果发现：浏览器能翻墙了，但某个游戏的网络还是卡；或者命令行里 `git clone` 一个 GitHub 仓库，速度依然慢得像蜗牛。 问题往往出在工作模式的选择上。代理客户端（[Clash Verge Rev](https://github.com/clash-verge-rev/clash-verge-rev)、[sing-box](https://github.com/SagerNet/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](https://wiki.metacubex.one/)。它，稳定性和兼容性在社区中得到了广泛验证。 - **与规则系统深度集成**：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 值得尝试。 --- ## 怎么选？ 以下决策流程可以帮助你快速判断应该使用哪种模式： ``` 你需要代理游戏、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 配置片段： ```yaml 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、本地服务器等），需要在分流规则中添加直连规则： ```yaml 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 模式才是必要的。