TUN 模式是一种在操作系统网络层接管全部流量的代理方式。 它通过创建一张虚拟网卡并改写系统路由表，把设备上所有应用的联网请求——包括那些不读取系统代理设置的命令行工具、Docker、游戏客户端——统统强制导向代理，从而实现真正的「全局代理」。
这也是很多人搜「tun模式是什么」时最想先弄明白的一句话。下面把它和普通系统代理的区别、谁需要开、以及代价讲清楚。
你设好了代理，规则写得也不错，Terraka 的状态栏显示「已连接」。但打开终端跑一条 npm install，包还是从国内镜像拉——或者根本超时。这不是配置问题，而是系统代理的设计边界：它只对「愿意配合」的应用生效。TUN 模式解决的就是这个问题。
01 什么是 TUN 模式
TUN 模式（TUN mode）里的 TUN 指的是操作系统提供的一种虚拟网络设备（虚拟网卡）。代理软件创建一张这样的虚拟网卡，再修改路由表把所有出站流量导过来，然后逐个连接决定走代理、直连还是拒绝。
它和你平时说的「系统代理」是两种完全不同的机制：
- 系统代理：工作在应用层，靠应用「自愿」把请求发给代理端口。App 不配合就没用。
- TUN 模式：工作在网络层，在流量离开设备前就接管，应用完全无法绕过。
所以一句话记住：系统代理是「请应用走代理」，TUN 模式是「强制所有流量走代理」。这就是为什么 TUN 模式能覆盖那些系统代理管不到的场景。
02 系统代理的边界
所谓系统代理，是操作系统提供的一个全局设置：HTTP_PROXY=127.0.0.1:7890。应用启动时读这个环境变量，把 HTTP 请求转发给本地代理端口——仅此而已。
问题在于，这只是一个君子协定。没有任何机制强迫应用遵守。浏览器、Telegram、大多数图形界面软件会乖乖配合；但命令行工具通常读取自己的配置文件，Docker 守护进程走自己的网络命名空间，有些 Electron 应用里内嵌的原生模块甚至会绕过 Electron 的代理设置，直接用系统 Socket。
这些应用不是「出了 bug」——它们只是没有选择使用系统代理这套机制。
TUN 模式在网络层接管流量，绕过应用层代理限制，实现真正的全局代理。
— Clash.Meta 文档，关于 TUN 模式的说明
03 TUN 在哪一层工作
理解 TUN 模式，需要先在脑子里画一张网络分层图。
普通的 HTTP/SOCKS 代理工作在应用层（Layer 7）：应用主动发起连接到代理端口，代理替它转发请求。整个过程需要应用的主动参与。
TUN 工作在网络层（Layer 3）。它让 Terraka 在操作系统里注册一张虚拟网卡（macOS 下叫 utun，Windows 下叫 Terraka Tunnel），然后修改系统路由表，把所有出站 IP 流量都导向这张虚拟网卡。
内核会把这些 IP 包原封不动地交给 Terraka，Terraka 再根据规则决定每个连接走哪个出口——代理、直连、还是拒绝。
应用对这一切毫不知情。 它只是发出了一个普通的 TCP/UDP 连接，内核在背后做了重定向。这就是为什么命令行工具、Docker、游戏客户端在 TUN 模式下都能走代理。
gVisor vs 系统栈
Terraka 内部支持两种 TUN 实现。stack: system 直接复用操作系统网络栈，性能更好；stack: gvisor 使用用户态协议栈，隔离性更强但 CPU 开销略高。默认用 system 即可。
04 哪些 App 真的需要 TUN
如果你只用浏览器和几个图形界面 App，系统代理已经够用。TUN 的价值主要体现在以下几类用户：
开发者。 git clone、npm install、pip install、brew upgrade、docker pull——这些命令默认不读系统代理。没有 TUN，你要么手动给每个工具配代理环境变量，要么在终端里每次 export https_proxy=...，烦死了。TUN 开着，什么都不用管。
Docker 用户。 容器里的网络请求走的是 Docker 自己的网桥，完全绕过宿主机的系统代理。TUN 在宿主机网络层工作，容器流量同样被接管。
游戏玩家。 游戏客户端通常用 UDP，不走 HTTP 代理。TUN 能接管 UDP 流量（配合 Hysteria2、TUIC 这类基于 QUIC 的 UDP 协议更有意义），减少跨境延迟。
Windows UWP 应用。 UWP 有沙箱限制，默认无法使用系统代理。TUN 是绕过这个限制最干净的方式。
05 代价与取舍
TUN 不是没有代价的，列几个你应该知道的点：
需要更高的系统权限。 macOS 需要「网络扩展」权限，首次授权需要管理员密码；Windows 需要以管理员身份运行，并安装 WinTun 内核驱动。这是 TUN 工作原理决定的，无法绕过。
DNS 处理需要配合。 TUN 接管了 IP 层流量，但 DNS 查询默认还是走系统 DNS——这可能导致 DNS 泄漏，或者 DNS 结果和实际代理出口对不上（CDN 优化失效）。正确做法是同时开启 Terraka 的 dns-hijack，把 53 端口的 DNS 请求也转给内置 DNS 处理——具体原理见代理为什么会 DNS 泄漏、怎么彻底防止。
轻微的性能开销。 每个 IP 包都要经过虚拟网卡转发，会多一次内核态到用户态的切换。实测在 M 系列芯片上 CPU 开销增加不到 3%，基本感知不到；Intel 老机器可能稍微明显一点，但也在可接受范围内。
退出时记得关闭。 强制退出 Terraka 而不先关闭 TUN，路由表里的规则可能残留，导致无法正常联网直到重启。养成习惯：退出前先点「停止 TUN」。Terraka 2.7 起加了自动清理逻辑，但防患于未然。
06 该不该默认开启
我的建议是：如果你是开发者，默认开。
命令行工具不走代理这件事每天都在摩擦你的注意力，TUN 一次性解决。代价（需要授权、轻微 CPU 开销）远小于收益。
如果你是普通用户，只用浏览器和 App：不强求。系统代理对你够用，TUN 带来的额外权限请求和可能的偶发路由问题不值得。
如果你用 Docker 或者在跑各种命令行工具，那 TUN 几乎是必需的。
具体开启步骤（macOS / Windows，包括权限授予和验证方法）在这篇教程里。