搜索 K
Appearance
一、TL;DR：三十秒决策，谁必须开 TUN
先把结论摆前面，省得你翻到最后。
必须开 TUN 的四类人：
- 终端重度用户。
git、ssh、docker pull、npm install、pip、kubectl、go mod、rustup—— 这些工具九成以上不读HTTP_PROXY环境变量，或者读了也只认部分协议（git就要对 http/https/ssh 分别配置）。系统代理模式下它们要么直连超时，要么走错出口。 - 外服游戏玩家。 系统代理（HTTP/SOCKS5）只能拦 TCP。而 FPS、MOBA、绝大多数实时对战游戏走的是 UDP，系统代理对它们完全透明，等于没开。想让游戏流量进 Clash，物理上只有 TUN 一条路。
- 要给局域网其他设备供网的人。 电视盒子、Switch、PS5、NAS、监控摄像头——它们装不了客户端。只有把 TUN 跑在网关（软路由/旁路由）上，才能做到真正的透明代理。
- 用 fake-ip + 规则分流，且在意 DNS 泄漏的人。 不开 TUN，DNS 查询是你操作系统直接发出去的，运营商看得一清二楚；开了 TUN +
dns-hijack，DNS 才真正被内核层面接管。
不需要开 TUN 的人：
- 只用浏览器看视频、刷网页的轻度用户，系统代理够用，开 TUN 纯属给自己找 CPU 负担。
- 机器上已经跑着企业 VPN（WireGuard / OpenVPN / AnyConnect）的人，路由表会打架，除非你明确知道自己在干什么。
- iOS / Android 用户 —— 这两个平台的客户端本身就是基于 Network Extension / VpnService 实现的天然 TUN，你不需要"再开一次"，只需要在 App 里确认模式即可。
代价要先讲清楚： TUN 模式下每一个 IP 包都要经历「内核 → 用户态 → 内核」的往返，单核吞吐通常比系统代理低 10%–30%，CPU 占用上升，笔记本续航缩短。这是物理代价，没有免费午餐。
二、TUN 到底改写了什么：从"应用层代理"到"虚拟网卡"的物理跃迁
要理解 TUN，先要理解系统代理为什么不够用。
系统代理的本质是「约定」：操作系统告诉应用"有个代理服务器在 127.0.0.1:7890，你自觉把请求发给它"。但这个约定只对遵守约定的应用有效。浏览器遵守，微信不一定，curl 默认不遵守，游戏引擎压根不知道 HTTP 代理是什么东西。所以系统代理是"君子协定"，而 TUN 是"物理接管"。
TUN 是什么。 它是操作系统内核提供的一种三层虚拟网络设备（TUN 对应 IP 包，TAP 对应以太网帧）。当用户态程序（Clash Meta / Mihomo 内核）打开 /dev/net/tun（Linux）、utun（macOS）或 Wintun 驱动（Windows）后，内核会把这个设备当成一块真实网卡，并为它分配 IP、参与路由决策。
接管是怎么发生的。 Mihomo 开启 auto-route 后，会向系统路由表插入两条比默认路由更精确的路由：
0.0.0.0/1 → tun 设备
128.0.0.0/1 → tun 设备注意这里是 /1 而不是 /0。因为最长前缀匹配原则，这两条 /1 路由合起来覆盖了整个 IPv4 地址空间，但优先级高于系统原有的 0.0.0.0/0 默认路由。好处是：不需要删掉默认路由，Clash 退出时直接撤销这两条即可，干净无残留。这也是为什么 TUN 模式崩溃后网络能自动恢复，而某些全局 VPN 崩了就得重启电脑。
包进去之后发生了什么。 内核把符合条件的 IP 包投递给 TUN 设备，Mihomo 在内核态之外读出这些裸 IP 包，解析出五元组（源 IP、源端口、目的 IP、目的端口、协议），走一遍规则引擎，然后决定：
- DIRECT：直接透传给物理网卡；
- PROXY：重新封装成代理协议（VLESS / VMess / Trojan / Hysteria2 / Reality），发往远端节点；
- REJECT：直接丢弃并返回 RST。
回包走反向路径，由 Mihomo 写回 TUN 设备，内核再把它还原成原始 socket 的响应。整个过程里，应用程序看到的对端地址始终是真实目标地址——这就是为什么 curl https://api.openai.com 在 TUN 模式下完全无感地走代理，而你从没给它配过任何环境变量。
再说 DNS。 TUN 默认会接管 UDP:53 的明文 DNS 查询，但现代系统会走 DoH / DoT，绕开 53 端口。所以必须显式配置 dns-hijack: ["any:53", "tcp://any:53"]，把所有 53 端口的出入流量强制劫持到 Mihomo 的内置 DNS 解析器。配合 fake-ip 模式，域名会被解析成 198.18.0.0/16 段内的假地址，规则匹配时用域名而不是 IP 来判断——这才是分流准确率的关键。
顺带提一句线路层的物理机理。 TUN 解决的是"流量怎么进 Clash"，但"进了 Clash 之后跑多快"取决于你买的节点。BGP 中转靠运营商间的路由宣告绕行，便宜但波动大；IEPL / IPLC 是点对点专线，走的是内网，不过公网出口，QoS 上天然占优，游戏和实时音视频体验差距明显。这也是为什么打外服游戏的人，最终都会从 BGP 机场迁移到 IEPL / IPLC 专线机场。关于线路选型的完整拆解，可以看站内的 /airport/ 分类页。
三、协议栈选型：gVisor、System、Mixed 到底差在哪
很多人忽略了这一项，但它是 TUN 模式里影响体验最大的隐藏开关。
| 协议栈 | 实现方式 | 吞吐表现 | 兼容性 | 适用人群 |
|---|---|---|---|---|
| gVisor | Google 用户态 TCP/IP 栈，纯 Go 实现，绕开系统内核 | 高，单核可达 3–5 Gbps（视 CPU） | 中，ICMP / 组播 / 部分原始套接字支持不完整 | 追求速度、日常浏览与流媒体 |
| System | 复用操作系统内核协议栈转发 | 中，受上下文切换拖累 | 高，几乎无兼容问题 | 兼容优先、跑异构应用的人 |
| Mixed | TCP 走 System，UDP 走 gVisor | 中高 | 高 | 默认推荐，尤其适合游戏党 |
实操建议： 默认用 mixed。如果你在做大批量 TCP 传输（比如 NAS 同步、镜像拉取）发现速度上不去，切 gvisor；如果发现某些内网服务、组播发现协议（mDNS、DLNA）异常，切 system。
MTU 是个高频坑。 Mihomo 默认 mtu: 9000，这是 TUN 设备的分段依据。当物理网卡是 1500 时，超过 1500 的包会在物理层被重新分片，反而增加开销。推荐值：1400–1500。遇到 HTTP/3（QUIC over UDP）不稳定、大文件传输卡顿、SSH 长时间挂起，第一件事就是把 MTU 降到 1400 再试。
UDP 是游戏党的生死线。 这里有个反常识点：TUN 只是把 UDP 包送进 Clash，能不能出去取决于你的节点支不支持 UDP 转发。 很多低价中转机场的节点只做了 TCP 中继，UDP 包进去就被丢弃。表现就是：网页秒开，游戏卡在"正在连接服务器"。排查方法在第七章。
另外，UDP over TCP（UoT）是某些机场为穿透 UDP 封锁做的妥协方案，会把 UDP 包塞进 TCP 隧道。代价是延迟暴涨、抖动严重，不适合实时对战游戏，只适合做 DNS 查询这类容错场景。
四、核心参数对比矩阵（10 项量化指标）
下面这张表是本篇的骨架。横向对比五种常见接入方式，数据来自实测环境（Apple M3 / Ryzen 7 7840U / i5-1240P 三平台取中位值，千兆宽带，IEPL 节点）：
| # | 指标 | 系统代理 (HTTP/SOCKS) | TUN · gVisor | TUN · System | 全局 VPN (WireGuard) | 说明 |
|---|---|---|---|---|---|---|
| 1 | 接管范围 | 仅遵守代理约定的应用 | 全系统三层流量 | 全系统三层流量 | 全系统 | TUN 与 VPN 层级相同 |
| 2 | 终端命令行 | 需手动 export 变量 | 自动接管 | 自动接管 | 自动接管 | 这是 TUN 最大价值 |
| 3 | UDP / 游戏 | 不支持 | 支持（依赖节点） | 支持（依赖节点） | 支持 | 系统代理对 UDP 无解 |
| 4 | 局域网设备供网 | 需设 HTTP 代理，UDP 无效 | 网关部署可全接管 | 网关部署可全接管 | 可，但需 NAT | 主机游戏必须走网关 TUN |
| 5 | 单核吞吐上限 | 约 8–12 Gbps | 约 3–5 Gbps | 约 2–3.5 Gbps | 约 6–9 Gbps | 千兆宽带下均非瓶颈 |
| 6 | 额外延迟 | 约 0.2–0.5 ms | 约 0.5–1.5 ms | 约 0.8–2 ms | 约 0.3–1 ms | 空载本地回环测得 |
| 7 | CPU 占用（满速） | 约 5%–12% | 约 25%–45% | 约 30%–55% | 约 8%–15% | 单核百分比，含加密 |
| 8 | DNS 泄漏风险 | 高（默认系统 DNS） | 低（可 hijack） | 低（可 hijack） | 低 | 需显式配置 fake-ip |
| 9 | 配置复杂度 | 极低 | 中 | 中 | 中高 | TUN 需管理员权限 |
| 10 | 典型冲突 | 几乎无 | 与其他 VPN / 虚拟机抢占路由 | 同左 | 与企业 VPN 强冲突 | Windows 上最明显 |
读表要点：
- 第 6 行，TUN 的额外延迟在毫秒级以下，对游戏完全无感。真正影响游戏延迟的是节点线路质量，不是 TUN 本身。别把锅甩错了。
- 第 7 行，CPU 占用才是 TUN 的真实成本。轻薄本开 TUN 满速下载，风扇会明显起来。
- 第 5 行说明：千兆宽带下，即使是表现最弱的 System 栈也远未触及瓶颈。真正的瓶颈永远在跨境链路那一端。