Appearance
什么是 TUN 模式？与系统代理模式对比 为什么打游戏和有些客户端必须开 TUN 模式？
⚡ Answer-First 核心速览
系统代理仅在应用层为遵循 WinINET 规范的浏览器提供 HTTP 和 Socks5 协商，完全无法接管基于 UDP 协议的竞技网游、终端工具以及沙盒 UWP 应用；TUN 模式在操作系统内核中安装虚拟网卡驱动，通过路由表注入将整个系统的网络层三层 IP 数据包无差别捕获，并由轻量级用户态协议栈解构为 TCP 和 UDP 数据流送入代理隧道。打联机游戏、使用命令行开发环境或解决应用走漏真实 IP 时，开启 TUN 模式是工业级解决方案。
在日常使用 Clash Verge Rev、Mihomo Party 或 Sing-box 时，许多用户都会经历这样的困惑。浏览器里看 YouTube 4K 视频流畅无比，但打开 Steam 联机游戏却一直提示“无法连接至官方匹配服务器”；在终端里执行脚本依旧直连超时；或者某些海外应用依然能够获取到本地宽带的真实公网 IP。
这些现象背后的技术根源在于“系统代理”的接管盲区。为了打破这个限制，现代代理工具引入了 TUN 虚拟网卡技术。理解系统代理与 TUN 模式在网络协议栈中的层级分工，掌握 Wintun 驱动的运作原理与路由机制，是彻底解决全场景流量接管、消除游戏高延迟与丢包的关键。
系统代理与 TUN 模式的技术断层剖析
为什么桌面客户端开启了系统代理，网页能正常出海，而游戏和许多应用却无动于衷。这需要从操作系统的网络通信层级说起。
text
OSI 七层模型 应用软件发起的通信链路 客户端接管方案
┌──────────────┐ ┌─────────────────────────────────┐ ┌───────────────────────────┐
│ 7. 应用层 │ ──> │ Edge, Chrome, 常用网页浏览器 │ ─> │ 【系统代理模式】 │
│ 6. 表示层 │ │ (主动读取 Windows 注册表代理键值)│ │ (仅接管应用层 HTTP/SOCKS) │
│ 5. 会话层 │ └─────────────────────────────────┘ └───────────────────────────┘
├──────────────┤ ┌─────────────────────────────────┐ ▲
│ 4. 传输层 │ ──> │ 竞技网络游戏, Discord 语音通话 │ │ (完全无视系统代理)
│ │ │ (基于纯 UDP / 原始 Socket 握手) │ │
├──────────────┤ ├─────────────────────────────────┤ ┌────────────┴──────────────┐
│ 3. 网络层 │ ──> │ 终端 CLI, Docker, WSL, UWP 应用 │ ─> │ 【TUN 虚拟网卡模式】 │
│ │ │ (网络层原始 IPv4 / IPv6 数据报文)│ │ (Wintun 驱动在内核强行截获)│
├──────────────┤ └─────────────────────────────────┘ └───────────────────────────┘
│ 2. 数据链路层│ │
├──────────────┤ ▼
│ 1. 物理层 │ ───────────────────────────────────────────────────> 物理网卡与互联网网关1. 系统代理的运行局限
在 Windows 环境下，当你在客户端界面上勾选“系统代理”开关时，程序通过调用 Windows API 修改了当前用户的注册表项。对应路径为 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings。
注册表中被修改的核心键值包括以下两项。
ProxyEnable设置为 1ProxyServer设置为127.0.0.1:7890
这个设置属于典型的弱契约协商机制。它并不具备强制性，只有那些在代码中主动调用 WinINET 库、WinHTTP 库，或者在启动时主动扫描系统注册表代理配置的软件（如 Edge、Chrome、Firefox 以及遵循系统规范的办公工具），才会自觉将 HTTP 请求包装为发往 127.0.0.1:7890 的代理流量。
大量高性能网络程序完全绕开这套机制。
- 竞技网游客户端。例如 CS2、Apex Legends、Valorant、战地系列等。为了追求极致的响应速度并降低通信开销，游戏引擎绝大多数使用无连接的 UDP 协议传输玩家位置、动作与射击弹道，而且代码中直接调用底层 Socket 绑定本地物理网卡直连远端游戏机房，根本不会去读取操作系统的 HTTP 代理注册表。
- 命令行与开发运维工具。Git、cURL、Python Requests、Docker 守护进程、Go 编译拉包工具等均源于 Unix 生态，天然忽略 Windows 注册表。
- Windows UWP 沙盒应用。微软为了系统安全，对 UWP 应用实施了 AppContainer 网络沙盒隔离。UWP 应用在默认状态下甚至被禁止访问本地回环地址（
127.0.0.1），即使它们想连接本地运行的代理客户端，也会被 Windows 防火墙当场拦截。
2. TUN 模式的破局思路
TUN 模式换了一种完全不同的思路。它不再寄希望于应用程序自觉配合，而是将战线直接推到了操作系统的第三层（网络层）。
客户端通过向操作系统注册一个虚拟网络适配器（在 Windows 上通常命名为 wintun 虚拟网卡），并修改内核路由表，将所有出站 IP 数据报文的默认路由强行指引到这张虚拟网卡中。 无论上层跑的是什么游戏、什么终端、什么私有协议，只要这个软件试图向公网发出任何 IP 数据包，操作系统的网络协议栈就会按照路由表规定，把这些数据包全部投递给 TUN 虚拟网卡，实现了真正无死角的系统级接管。
Wintun 虚拟网卡驱动底层技术原理
要在 Windows 系统中稳定、高速地截获三层数据包，驱动程序的性能与稳定性至关重要。
1. TAP 与 TUN 的本质分野
早期的虚拟网卡方案普遍采用源自 OpenVPN 项目的 TAP-Windows 驱动。在网络工程中，TAP 与 TUN 处于不同的协议层级。
- TAP 运行在第二层（数据链路层）。TAP 虚拟网卡模拟的是一张虚拟的以太网卡，它在内核中处理的是完整的以太网帧（包含 14 字节的以太网标头、源 MAC 地址、目标 MAC 地址以及 ARP 广播寻址）。当代理软件使用 TAP 模式时，客户端必须在用户态模拟 ARP 响应、维护虚拟 MAC 地址表。这种处理方式带来了巨大的额外计算损耗，延迟波动剧烈。
- TUN 运行在第三层（网络层）。TUN 虚拟网卡省去了所有链路层的 MAC 帧头与 ARP 繁琐协商，直接在用户态与内核态之间读写纯净的 IPv4 与 IPv6 报文。
2. Wintun 驱动的架构革新
为了给现代现代代理和 VPN 提供极致的吞吐性能，知名安全组网项目 WireGuard 的开发团队重写了一套专门针对 Windows 平台的新型虚拟网卡驱动，即 Wintun。
Wintun 彻底抛弃了老旧 TAP 驱动中冗长且臃肿的 NDIS 6.0 虚拟微端口架构，其技术创新主要体现在以下几个维度。
极简内核态设计
Wintun 只专注于将三层 IP 数据包在内核与用户态之间高速传递，不附带任何复杂的二层桥接逻辑。其驱动代码体积小巧，不仅极大地缩小了潜在的系统攻击面，更彻底杜绝了旧驱动频繁引发 Windows 蓝屏死机（BSOD）的隐患。
内存环形缓冲区（Ring Buffer）机制
传统驱动在内核态与用户态之间交换网络数据时，每次读取数据包都需要执行昂贵的系统调用（System Call）与跨内存空间的数据拷贝。 Wintun 创新性地引入了由内核空间与用户态空间共享的环形内存缓冲区队列。 当应用程序发出大量网络数据包时，驱动批量将数据指针放入队列，用户态的客户端进程（Mihomo 或 Sing-box）可以直接从环形队列中一次性拉取成百上千个数据包，极大地降低了 CPU 上下文切换的频率。在万兆内网压测环境下，Wintun 可以轻松跑满硬件吞吐，网络延迟增加量小于 1 毫秒。
3. 内核路由表注入与最长前缀匹配
Wintun 虚拟网卡创建完成后，如何让全系统的流量自动流入它。这依赖客户端对操作系统内核路由表的动态重构。
text
======================= 操作系统默认路由表 =======================
目标网络 (Destination) 子网掩码 (Netmask) 网关 (Gateway) 接口 (Interface)
0.0.0.0 0.0.0.0 192.168.1.1 (真实路由器) 192.168.1.50 (物理网卡)
======================= 开启 TUN 模式后的注入路由表 =======================
目标网络 (Destination) 子网掩码 (Netmask) 网关 (Gateway) 接口 (Interface)
0.0.0.0 128.0.0.0 (/1) 198.18.0.1 (TUN 网关) 198.18.0.2 (Wintun 网卡)
128.0.0.0 128.0.0.0 (/1) 198.18.0.1 (TUN 网关) 198.18.0.2 (Wintun 网卡)
节点物理 IP (如 1.2.3.4) 255.255.255.255 (/32) 192.168.1.1 (真实路由器) 192.168.1.50 (物理网卡)客户端并没有直接粗暴地删除系统原有的默认网关 0.0.0.0/0，而是运用了计算机网络中最经典的最长前缀匹配原则（Longest Prefix Match）。
在路由匹配时，子网掩码越长（前缀越具体），优先级越高。 客户端在路由表中插入了两个 /1 的精准子网路由，分别是 0.0.0.0/1（覆盖 0.0.0.0 到 127.255.255.255）和 128.0.0.0/1（覆盖 128.0.0.0 到 255.255.255.255）。 由于 /1 的掩码长度大于系统原本默认网关的 /0，因此系统内除特定保留路由外产生的一切网络请求，都会被无条件匹配进这两个路由条目，顺利滑入 Wintun 虚拟网卡。
还有一个至关重要的细节。如果所有流量都进了 Wintun，那么客户端本身向境外落地节点建立加密隧道的物理流量，岂不是也会被导回 Wintun 陷入死循环。 为了防止死锁，客户端在启动 TUN 模式的瞬间，会自动查询你当前选中的代理节点的物理公网 IP（例如 1.2.3.4），并在路由表中显式注入一条前缀最长的独占路由，即 1.2.3.4/32 走物理网卡网关。 由于 /32 的优先级最高，客户端发出的加密流量能够安全地直接走物理网卡出网，形成一个逻辑闭环。
用户态协议栈转换 从三层 IP 包到四层数据流
从 Wintun 驱动中吐出来的是原始的三层 IP 数据报文。报文中包含了源 IP、目标 IP、IP 标头校验和以及片偏移。 现代出海代理协议（无论是 Shadowsocks、VMess、Trojan 还是 Hysteria 2）工作在第四层或第七层，处理的是抽象的 TCP 数据流或 UDP 载荷。
如何把三层的原始二进制 IP 报文，还原成代理协议可以理解的数据。这必须依赖客户端内置的用户态轻量级网络协议栈。
text
[应用程序发出 HTTP 请求]
│
▼ (生成 TCP 握手 SYN 报文)
[操作系统网络层]
│
▼ (最长前缀匹配，命中 0.0.0.0/1)
[Wintun 虚拟网卡驱动]
│
▼ (内核 Ring Buffer 传递原始三层 IPv4 报文)
[用户态网络协议栈 (LwIP / gVisor)]
│
├── 1. 解析 IP 头部，提取源 IP、源端口、目标 IP、目标端口
├── 2. 模拟内核网络栈，在内存中维护 TCP 状态机 (SYN, ACK, 滑动窗口, 序列号重排)
├── 3. 向客户端核心暴露标准的 net.Conn (抽象 TCP 连接流) 与 net.PacketConn (UDP 会话)
└── 4. 配合本地 Fake-IP 映射表，反查出目标原始域名 (如 google.com)
▼
[Mihomo / Sing-box 分流引擎]
│ (匹配 rules 规则树)
▼
[加密协议封装器 (Trojan / Shadowsocks / Hysteria 2)]
│
▼ (经由节点独占物理路由 1.2.3.4/32)
[本地物理网卡] ──> 互联网 ──> 境外落地服务器 ──> 最终目标在现代客户端（如 Mihomo）中，通常提供了两种协议栈驱动选项。
1. gVisor 协议栈
源于谷歌容器沙盒安全项目的高性能用户态网络栈。它用 Go 语言完整实现了一套具备工业级健壮性的 TCP/IP 协议栈，对各种异常数据包、乱序重传、窗口探测具有极强的容错能力。虽然内存占用略高几兆，但在长时间高并发网络吞吐和复杂网络环境下稳定性拔群，是目前桌面环境的首选推荐。
2. System / Mixed 混合协议栈
对于标准的 TCP 流量，直接由操作系统内核原生机制处理，只将复杂的 UDP 报文送入协议栈。在某些低功耗嵌入式设备（如软路由、老旧平板）上能够进一步压榨 CPU 性能，但在 Windows 复杂防火墙环境下的兼容性略逊于纯 gVisor 方案。
系统代理 vs TUN 模式 vs 旁路由模式全景横向对照
为了更直观地看清不同网络接管方案的适用边界，下面针对工程中常见的四大方案进行横向技术对比。
| 评估维度 | 系统代理模式（WinINET） | TUN 模式（Wintun 驱动） | 传统 TAP 模式（OpenVPN） | 局域网旁路由透明代理 |
|---|---|---|---|---|
| 接入网络协议层级 | 第七层（应用层） | 第三层（网络层） | 第二层（数据链路层） | 第三层（网络层旁路网关） |
| 操作系统驱动依赖 | 无需任何底层驱动 | 依赖 Wintun 内核驱动 | 依赖 TAP-Windows 驱动 | 本机零驱动，依赖网络硬件 |
| 网络游戏 UDP 支持 | 完全不支持（直接走漏或断网） | 原生全特性支持（含 Full Cone） | 支持但延迟抖动大 | 原生支持，由 Linux 内核转发 |
| 终端命令行接管率 | 极低（需手动配环境变量） | 100% 系统无死角接管 | 100% 全局接管 | 100% 全局接管 |
| UWP 沙盒应用接管 | 需借助工具解除回环隔离 | 原生直接接管，无需配置 | 原生直接接管 | 原生直接接管 |
| CPU 与内存开销 | 极低（纯中继转发） | 适中（内存约增加 30-80MB） | 较高（频繁模拟二层 ARP 广播） | 本机零开销，算力由路由器承担 |
| 权限要求 | 普通用户权限即可运行 | 必须以系统管理员权限运行 | 必须以系统管理员权限运行 | 普通用户，只需修改网关 IP |
| 典型适用场景 | 网页浏览、看视频、轻度办公 | 联机打游戏、代码开发、终端拉包 | 传统企业组网（正在被淘汰） | 全屋智能家居、电视盒子、主机加速 |
通过对照可以发现，TUN 模式在不需要额外购置物理软路由硬件的前提下，在单台 PC 上实现了几乎等同于透明网关的强大控制力。
实战配置 Clash Verge Rev 与 Mihomo 生产级 TUN 模块
在客户端中开启 TUN 模式，通常只需在界面上点击一个开关。但如果缺乏深度配置，很容易导致局域网打印机失联、内网 NAS 无法挂载等副作用。
下面是一份针对 Clash Verge Rev / Mihomo 的高可用 TUN 配置模块，可直接写入扩展脚本（Script）或配置覆盖中。
yaml
# ==========================================
# 核心 DNS 模块配置 (Fake-IP 联动是 TUN 模式的基石)
# ==========================================
dns:
enable: true
listen: 127.0.0.1:1053
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "*.msftconnecttest.com"
- "*.msftncsi.com"
- "time.*.com"
- "ntp.*.com"
nameserver:
- 223.5.5.5
- 119.29.29.29
# ==========================================
# TUN 虚拟网卡驱动与网络栈接管配置
# ==========================================
tun:
enable: true
# 推荐使用稳定性最佳的 gvisor 协议栈
stack: gvisor
# 设备名称，默认为 Mihomo 或 wintun
device: wintun
# 自动向系统路由表注入默认接管路由
auto-route: true
# 自动检测当前正在连接公网的真实物理网卡，防止网关识别错误
auto-detect-interface: true
# 强制劫持发往 53 端口的所有 UDP/TCP DNS 报文
dns-hijack:
- "any:53"
- "tcp://any:53"
# 开启严格路由模式，防止多网卡同时在线时发生路由泄露
strict-route: true
# 局域网私有网段与关键服务排除名单 (防止内网设备失联)
route-exclude-address:
- 192.168.0.0/16
- 10.0.0.0/8
- 172.16.0.0/12
- 127.0.0.0/8
- 224.0.0.0/4关键配置参数深度解构
stack: gvisor指定了用户态协议栈。如果使用mixed遇到特定游戏无法登录，切回gvisor通常能当场解决。auto-detect-interface: true非常关键。如果你的电脑同时插了网线并连着 Wi-Fi，或者安装了 VMware、VirtualBox 虚拟网卡，该参数能保证客户端始终将真实的公网默认网关绑定在真正的物理网卡上，杜绝了物理流量死锁。dns-hijack: ["any:53"]强行将局域网内任意程序发出的 DNS 查询请求拦截并送回客户端本地的 DNS 解析器。即使游戏程序硬编码了8.8.8.8作为查询服务器，也会被虚拟网卡强行抓回，杜绝了 DNS 污染与查询泄露。route-exclude-address明确定义了不被 TUN 虚拟网卡接管的地址段。将家里的局域网 IP 段（如192.168.0.0/16）写入其中，确保访问家庭路由器、群晖 NAS、无线打印机时数据直达物理网卡，不走虚拟协议栈兜圈子。
游戏 UDP 转发与实战冲突排查指南
在开启 TUN 模式联机玩游戏的过程中，网络工程师经常会遇到丢包、无法组队、反作弊冲突或断网故障。以下是高频问题及排查路径。
1. 节点 UDP 转发支持与 NAT 类型评估
打游戏联机不仅要求网络通畅，还对 NAT 类型有极其苛刻的要求。
NAT 类型的致命影响
大部分 P2P 联机游戏（如怪物猎人、极限竞速地平线、任天堂 Switch 联机）在玩家组队时，要求至少达到 NAT2（Restricted Cone NAT） 甚至 NAT1（Full Cone NAT 全锥型）。如果你的节点不支持 UDP 转发，或者服务端只实现了对称型 NAT（Symmetric NAT），你的游戏 NAT 类型就会显示为 Strict（严格/NAT4），表现为能够进入游戏大厅，但永远无法加入好友的战队房间。
检测方法
在客户端中右键点击正在使用的节点，查看节点属性中的 udp: true 是否亮起。如果机场将节点的 UDP 转发功能关闭，任何通过该节点的游戏 UDP 流量都会被直接丢弃。可以使用专门的 STUN 探测工具测试当前节点的 NAT 锥型状态。
2. 反作弊系统（Vanguard / BattlEye / EAC）冲突排查
腾讯的 ACE、拳头的 Vanguard（瓦罗兰特特战英豪反作弊）、Apex 使用的 Easy Anti-Cheat 以及绝地求生使用的 BattlEye 运行在 Windows 内核的最底层（Ring 0 级别）。
这些反作弊系统在启动时会扫描系统中加载的所有内核驱动。如果使用的是来源不明、被第三方恶意二次打包的过时 TAP 驱动，反作弊系统会判定其为潜在的虚拟网卡流量拦截外挂，直接弹出错误弹窗并强退游戏。
解决方案
- 确保使用最新版官方签名的 Wintun 官方驱动（Wintun 驱动拥有微软正规 WHQL 数字签名，主流反作弊系统均将其列入信任白名单）。
- 在 Clash Verge Rev 中点击安装“服务模式”（Service Mode），让客户端以后台特权系统服务运行，避免因普通权限加载驱动时触发反作弊的完整性拦截。
3. 多网卡路由跃点数（Metric）竞争导致断网急救
在开启 TUN 模式后，系统如果出现完全断网，或者物理网卡与 Wintun 频繁断开重连，通常是因为路由跃点数（Interface Metric）冲突引起的。
在 Windows 路由逻辑中，Metric 数值越小，该网卡的优先级越高。 正常情况下，Wintun 虚拟网卡的 Metric 会被客户端设为一个极小的值（如 1 或 5），使其优先级高于物理网卡的 20 或 30。 但某些电脑安装了第三方游戏加速器、校园网客户端或杀毒软件，这些软件会恶意死循环修改物理网卡的 Metric 为 1，与 Wintun 产生激烈的优先级竞争，导致操作系统的路由表陷入逻辑死锁。
排错与急救命令
打开管理员权限的 PowerShell，执行以下排查命令。
查看当前系统活跃的网卡跃点数。
powershell
Get-NetIPInterface | Select-Object InterfaceAlias, InterfaceIndex, InterfaceMetric如果发现物理网卡（如“以太网”或“WLAN”）与 Wintun 发生 Metric 冲突，可以手动重设物理网卡的跃点数。
powershell
Set-NetIPInterface -InterfaceAlias "以太网" -InterfaceMetric 35如果此时网络彻底瘫痪，可以执行终极网络急救脚本，重置系统的整个 Winsock 协议栈与 IP 路由表。
powershell
netsh winsock reset
netsh int ip reset
route -f执行后重启计算机，操作系统将自动清除一切残留的虚拟路由，恢复最初的纯净网络状态。
常见问题深度解答
Q1 为什么开启 TUN 模式后电脑无法打开本地路由器后台 192.168.1.1
这是典型的局域网私有网段被虚拟网卡强行劫持的现象。 在默认粗糙的 TUN 配置中，0.0.0.0/1 覆盖了所有从 0 到 127 开头的网段，但如果路由表中缺少对本地物理子网的具体豁免规则，发往路由器后台的请求就会被打包扔进代理隧道。远在海外的落地机房根本不可能存在你家里的 192.168.1.1，所以连接必定超时。 解决方法是在客户端 TUN 配置的 route-exclude-address 中，明确将 192.168.0.0/16 填入白名单，或者在分流规则的顶端加入 - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve。
Q2 开启 TUN 模式打外服游戏延迟反而变高了是怎么回事
TUN 模式解决的是“能不能接管流量”的问题，而不是“网络物理加速”的魔法。 游戏实际延迟由两段物理链路决定，第一段是你的电脑到代理机场中继入口的国内延迟，第二段是机场出口到海外游戏服务器机房的公网物理延迟。 如果你选择了一个绕路严重的节点（例如打日服游戏却选了美国节点，数据包先从中国飞到美国，再从美国飞回日本），游戏内延迟必定飙升至 200ms 以上。 打外服游戏时，必须匹配物理距离最近的节点，例如韩服游戏选韩国首尔原生节点，日服游戏选日本东京专线节点，欧服游戏选德国法兰克福或英国伦敦节点，且优先挑选经过 IPLC 或 IEPL 内网专线传输的低抖动线路。
Q3 TUN 模式和第三方的网易 UU、迅游等游戏加速器有什么区别
两者的底层截获技术有相通之处，但在网络路由架构与服务器部署上有明显侧重。 商业游戏加速器针对特定的几百款热门游戏进行了精细的进程级 Hook（基于 LSP 或 WFP 驱动截获特定游戏 exe），并且加速器厂商在全球数百个主要游戏机房（如 Valve、EA、Riot 机房旁）直连部署了专属内网专线，在游戏协议特征优化和动态路由选路方面具有很高的专业度； 而开源代理客户端的 TUN 模式提供的是更底层的通用全系统接管能力，只要你的机场节点质量过硬、专线带宽充裕，TUN 模式同样能够达到甚至超越商业加速器的低延迟联机体验，同时兼顾了命令行开发与全协议出海。
Q4 为什么在 Windows 下安装 TUN 驱动时总是提示权限不足
Wintun 驱动的注册与内核网络路由表的注入属于最高安全级别的系统操作。 如果在普通的非管理员权限下运行客户端，Windows 的用户账户控制（UAC）机制会禁止该程序安装底层虚拟网卡硬件驱动。 正确的做法是右键点击客户端图标，选择“以管理员身份运行”。或者直接在客户端设置中开启“服务模式（Service Mode）”，客户端会自动向系统注册一个常驻后台的特权服务进程，之后哪怕在普通权限下登录系统，也能无感调用虚拟网卡。