TUN 模式与系统代理对速度和流量的影响

结论：TUN 很少本身变慢，变化来自它接管了什么

TUN 模式与系统代理在速度上的差别，多数时候不是来自“哪种模式更快”，而是来自两者接管的流量范围、DNS 处理方式和 UDP 走向不同。TUN 会让更多流量进入代理，包括后台更新和 UDP，这可能挤占带宽、加快流量消耗，也可能让原本失败的应用开始正常工作。纯粹的处理开销只有在性能较弱的设备上才可能明显。

本文只讲对速度和流量的影响原理。两种模式的工作方式与选择建议，见 Windows 系统代理与 TUN 模式有什么区别；开关步骤和其他桌面端设置在 桌面端客户端：Windows 与 macOS。本文属于 晚高峰与网络质量影响因素二级专题。

五个影响速度和流量的方面

处理开销

TUN 模式下，系统发出的每个数据包都要进入虚拟网卡，由客户端内核把它们还原成连接，再按规则转发。客户端通常提供几种网络栈实现，处理效率与兼容性各有取舍。在常见的台式机和笔记本上，这部分开销一般不构成瓶颈；在老旧电脑、低功耗设备或同时跑大量连接时，处理能力可能先于带宽达到上限，表现为高速下载时速度上不去、风扇转速升高。

流量范围

这是最常被忽视的一点。打开 TUN 后，操作系统更新、网盘同步、各类应用的后台下载都会进入客户端。如果规则把它们判为走代理，它们就和你的前台使用共享同一个节点：晚间带宽本来就紧，后台流量再挤一下，前台网页和视频就会更慢；同时套餐流量消耗也会加快。系统代理模式下，这些后台程序大多不读取代理设置，原本是直连。

DNS 解析位置

TUN 模式为了按域名分流，通常会接管系统的 DNS 查询。接管方式不同，解析发生的位置不同，拿到的服务器地址也不同，这会直接影响网页加载快慢。原理单独写在 DNS 设置为什么会让网页变慢 中。

数据包大小

虚拟网卡有自己的最大传输单元设置。代理协议本身会在每个包外加一层头部，如果虚拟网卡上的包太大，加上头部后超过链路允许的大小，就要被拆分或丢弃重传。表现通常是：小请求正常，大文件下载或某些网站加载异常缓慢。客户端一般会给出合适的默认值，手动改过设置后出现这类现象时值得留意。

UDP 与 QUIC

系统代理基本只处理 HTTP 与 HTTPS 请求，UDP 应用要么直连、要么失败。TUN 能把 UDP 送进代理，语音和游戏因此可以工作；但浏览器和视频应用使用的 QUIC 也基于 UDP，它进入代理后的表现取决于节点如何承载 UDP。有的节点承载 UDP 效果不如 TCP，此时让应用回退到 TCP 反而更顺畅。UDP 承载的条件见 机场节点支持 UDP 吗。

为什么“切换模式后变快了”不一定可信

常见的误判是：系统代理下测速很快，开 TUN 后变慢了。实际上，系统代理模式下有些测速程序根本不读取代理设置，测到的是你本地宽带直连的速度；开 TUN 后它才真正经过节点。两次测的不是同一条路。

公平对比要满足四个条件：

1. 使用同一个节点，并关闭自动切换的策略组。
2. 使用同一个测试网址或同一个测速后端。
3. 在同一时段内交替测试，而不是一个在晚上、一个在白天。
4. 在客户端的连接列表里确认两次请求都出现过、出站节点相同。

流量消耗为什么会变快

开启 TUN 之后套餐流量用得更快，原因几乎都在“流量范围”这一项。可以在客户端的连接列表里按流量排序，看看占用最多的是哪些域名：如果排在前面的是系统更新、应用商店、网盘或云相册，说明这些后台服务正在经过代理。让它们走直连，既能减少流量消耗，也能把晚间有限的节点带宽留给前台使用。

晚高峰时的实际建议

晚间带宽本来紧张时，TUN 的“流量范围”效应会被放大。可以考虑以下做法，具体操作在客户端专题中：

• 只有需要覆盖全部程序或 UDP 时才开 TUN，日常浏览用系统代理即可；
• 让系统更新、网盘同步等大流量后台服务走直连规则；
• 晚间遇到慢时，先确认是不是后台有大流量在走代理；
• 切换模式后出现断网，按 开启 TUN 模式后断网的排查 处理。

晚间变慢的整体分析见 晚高峰与网络质量影响因素。本文不涉及任何品牌判断。请从官方渠道获取客户端，并遵守所在地法律法规与平台服务条款。