TUN 全局代理是指：客户端创建一张操作系统级别的三层虚拟网卡（TUN），再通过路由或策略规则，把本机大部分 IP 流量导向这张网卡，由代理/VPN 程序读取、封装并转发。它解决的核心问题不是“加密算法更强”，而是接管范围：让那些不认 HTTP/SOCKS 代理设置的应用，也能在系统层进入隧道。

TUN 到底是什么

TUN 是操作系统提供的虚拟网络设备，工作在 OSI 模型的第三层（网络层）。对协议栈来说，它像一张普通网卡：可以有 IP 地址、可以出现在路由表里、可以收发 IP 包。对用户态程序来说，它更像一个特殊文件或驱动接口：读到的是原始 IP 包，写回去的也是原始 IP 包。

与之相对的是 TAP：

特性TUNTAP
工作层级三层（IP 包）二层（以太网帧）
典型用途VPN、全局代理虚拟交换机、桥接、需要广播的场景
额外开销较低较高（帧头、ARP 等）
移动端支持常见少见且受限

绝大多数消费级 VPN 和“增强模式/全局 TUN”代理客户端使用的是 TUN，而不是 TAP。原因很直接：日常上网主要是 IP 流量；TAP 带来的二层能力对普通用户收益有限，却增加复杂度和开销。

一个需要记住的定义句：TUN 是接口，不是协议。 WireGuard、OpenVPN、IPsec、Clash/sing-box 的增强模式都可以建立在 TUN 之上；它们的差异在握手、加密、伪装和控制平面，不在“有没有 TUN”这一层。

“全局代理”在系统里具体发生了什么

开启 TUN 全局模式后，典型链路如下：

  1. 客户端以管理员/系统权限创建虚拟接口（如 Linux 的 tun0、macOS 的 utun*、Windows 的 Wintun 适配器）；
  2. 给该接口配置地址（例如 198.18.0.1/30 这类保留测试网段，或客户端自选的私有地址）；
  3. 修改路由：把 0.0.0.0/0（以及理想情况下的 ::/0）指向 TUN，或插入更高优先级的默认路由；
  4. 应用发出的 IP 包经路由查找进入 TUN；
  5. 用户态程序从 TUN 读出 IP 包，按规则决定直连、拒绝或代理；
  6. 需要代理的流量被封装成对远端节点的连接，经真实物理网卡发出；
  7. 回程数据解密/解封装后，再写回 TUN，交给本机协议栈送达应用。

关键点在于第 3 步：没有路由变化，TUN 只是一张空网卡。很多人以为“开了 TUN 就全局了”，实际上全局与否取决于默认路由、策略路由和排除规则是否正确安装。

为什么必须给节点本身留直连路由

如果默认路由已经指向 TUN，而连接代理节点的数据包也跟着进 TUN，就会形成路由环：包还没到达真实服务器，又被送回隧道入口。因此成熟客户端会为节点 IP（以及 DNS、控制 API 等必要地址）写入更精确的直连路由，优先级高于默认路由。

这不是边角优化，而是 TUN 模式能建立连接的前提。

TUN 全局 vs 系统代理 vs 单应用代理

把三种接管方式放在同一张表里，边界会更清楚：

维度HTTP/SOCKS 系统代理TUN 全局单应用/容器代理
接管位置应用层配置操作系统网络层进程/命名空间
覆盖范围认代理的应用绝大多数 IP 流量指定应用或环境
游戏/命令行经常失效通常可用取决于注入方式
权限要求较低通常需要管理员/VPN 权限中等
DNS 处理易泄漏到系统解析器可强制进隧道，但仍需正确配置依赖环境
性能开销较低中等（多一次虚拟接口与拷贝）视实现而定
故障影响面单个应用整机网络单个应用

系统代理的本质是告诉应用：“请主动把连接交给 127.0.0.1:7890”。应用如果不问、不支持或使用自己的网络栈，流量就不会进入代理。TUN 不依赖应用配合，而是改变操作系统“包该从哪张网卡出去”的决策。

这也解释了为什么在桌面端讨论“真正的全局”时，TUN 往往比系统代理更接近用户预期；以及为什么移动端系统原生 VPN API 本质上也是一类受系统管控的 TUN/虚拟接口模型。

各平台的实现差异

TUN 的抽象相同，落地接口并不相同：

  • Linux：经典路径是 /dev/net/tun。程序通过 ioctl 创建接口后，用普通文件描述符读写 IP 包。策略路由、iptables/nftables、ip rule 常被用来做更细的分流与防泄漏。
  • macOS / BSD：常见接口族是 utun。权限和路由操作与 Linux 类似，但系统扩展、网络配置框架和沙盒限制会影响客户端实现方式。
  • Windows：现代高性能方案多为 Wintun 这类内核驱动用户态库，而不是早期效率较低的方案。客户端通常还要处理 WinHTTP/WinINET 代理设置残留、NRPT（Name Resolution Policy Table）和多网络配置文件冲突。
  • Android：官方入口是 VpnService。应用创建虚拟接口后，系统把指定应用或全部应用的流量导入该接口；是否“全局”由系统 VPN 对话框与路由/应用排除列表决定。
  • iOS：通过 Network Extension 的 packet tunnel provider 实现类似能力。系统对后台保活、DNS 和路由有更严格约束，客户端自由度低于桌面端。

因此，“同一个客户端在 Windows 上的 TUN”和“在 Android 上的 VPN 模式”用户体验接近，底层权限模型、驱动和故障模式并不完全一样。跨平台排查时，不要假设配置项一一对应。

DNS：TUN 模式最容易被忽略的半条链路

IP 路由进了隧道，不等于名字解析也进了隧道。DNS 泄漏或错误解析会导致两类问题：

  1. 隐私与出口不一致：网页流量走节点，DNS 仍问本地运营商；
  2. 连通性失败：域名被污染，或解析到与出口地区不匹配的 CDN 地址。

TUN 全局模式下，较完整的做法通常包括：

  • 向系统下发隧道内 DNS（或客户端内置的虚拟 DNS）；
  • 确保到该 DNS 服务器的路由进入 TUN；
  • 处理浏览器自带的 DoH/DoT（它们可能绕过系统 DNS）；
  • 同时覆盖 IPv4 与 IPv6；
  • 在域名分流场景中，让“解析结果”和“后续连接出口”保持一致。

只开 TUN、不处理 DNS，表面上“全局了”，实际上控制面仍有一半留在本地网络。更系统的链路说明见现代 VPN 技术架构。

IPv6、UDP、QUIC：全局不等于无旁路

2026 年的真实网络里，旁路很少再只出现在“某个老旧软件不走代理”。更常见的是协议族和传输层旁路：

  • IPv6 未接管：只改了 0.0.0.0/0，应用优先走 IPv6 时会直连；
  • Happy Eyeballs：双栈竞速让流量在 v4/v6 间切换，放大配置不完整的影响；
  • QUIC/HTTP3：基于 UDP，某些只劫持 TCP 的旧式方案管不到；TUN 按 IP 接管时通常能覆盖，但若上层规则只匹配 TCP，仍可能例外；
  • WebRTC / 语音视频：可能做 NAT 打洞或使用独立候选地址，表现取决于客户端是否拦截相关流量；
  • 系统更新、商店、厂商服务：有的使用独立通道或硬编码解析路径。

所以评估“是不是真全局”时，应同时检查：IPv4/IPv6 默认路由、DNS、UDP、以及节点自身的直连例外是否符合预期。

增强型用户态协议栈：为什么有些 TUN 更快或更稳

传统路径是：应用 → 内核协议栈 → TUN → 用户态代理程序。代理程序若要把 IP 包变成到节点的 TCP/UDP 连接，往往还要实现或调用一套用户态网络栈（有的基于 gVisor netstack 一类实现）来解析连接五元组、维护会话并做转发。

这种“TUN + 用户态栈”的结构带来两个结果：

  1. 能力变强：可在 IP 层做域名/进程/端口策略，不必依赖应用支持 SOCKS；
  2. 开销变真实：多一次跨内核/用户态拷贝，CPU 占用通常高于纯系统代理；低端设备或高带宽场景下更明显。

性能优化常见方向包括批量读写、减少拷贝、内核加速接口，以及把热路径留在更少的上下文切换中。对使用者而言，选择标准不是“有没有增强模式”这个名字，而是：延迟、吞吐、耗电、断线恢复和 DNS 行为是否满足自己的设备与场景。

MTU 与“能连上但打不开部分网站”

TUN 全局模式会额外叠加外层封装。若虚拟网卡 MTU 仍按 1500 配置，隧道内大包出网后可能超过路径 MTU，表现为：

  • ICMP 被过滤后的 Path MTU 黑洞；
  • 小请求正常、大页面/大文件异常；
  • 部分 TLS 握手失败或卡住。

处理思路与 VPN 相同：下调 TUN MTU、钳制 TCP MSS、允许必要的 ICMP，并按实际外层协议头长度留余量。这类问题常常被误判成“节点不行”，其实是本地路径参数不匹配。

常见误解

误解 1：TUN 全局 = 更安全。
TUN 扩大的是接管范围。安全性仍取决于节点信任模型、加密协议、DNS、日志政策和客户端实现。把明文流量送进不可信出口，只是把暴露面从本地运营商换成了出口方。

误解 2：开了 TUN 就不会泄漏。
IPv6、DNS、WebRTC、权限不足导致的半启用状态、以及分流规则，都可能造成部分流量旁路。全局是配置目标，不是开关按下后的物理定律。

误解 3：TUN 比系统代理“更翻墙”。
能否绕过封锁看协议伪装、入口质量和网络环境，不看流量是从系统代理进还是从 TUN 进。TUN 只保证更多应用的流量有机会进入你选择的那条通道。相关背景见VPN 抗封锁技术演进。

误解 4：所有软件在 TUN 下行为一致。
使用原始套接字、自带 VPN、企业安全套件或虚拟机桥接网络的程序，仍可能部分或全部绕过。虚拟机若使用 NAT，通常跟随宿主机；若使用桥接，则按虚拟机自身路由决策。

什么时候该用 TUN 全局

更适合开启的情况：

  • 需要游戏、下载器、命令行、系统组件等“不认代理”的程序统一出口；
  • 希望降低“某个 App 忘记设代理”造成的泄漏面；
  • 需要在设备层统一处理 DNS 与双栈路由。

可以考虑不用、或改用分流/系统代理的情况：

  • 设备性能较弱，全局 TUN 导致明显发热或掉速；
  • 只需要浏览器访问，系统代理已足够；
  • 企业软件、银行或校内网对虚拟网卡/VPN 接口敏感；
  • 你需要精确控制“只有少数域名走代理”，且域名分流规则已经稳定。

若仍在建立基础概念，可先读VPN 是什么；若要对照机场与商业 VPN 的产品形态差异，见机场和商业 VPN 怎么选。

排查清单：TUN 已开启却“不像全局”

按层检查，比反复开关客户端更有效：

  1. 接口层：系统里是否真的出现了虚拟网卡，状态是否 Up；
  2. 路由层：IPv4/IPv6 默认路由是否指向该接口，节点 IP 是否有直连例外；
  3. DNS 层：系统 DNS 是否变为隧道 DNS，浏览器是否仍在用 DoH；
  4. 权限层：是否缺少管理员权限或系统 VPN 授权，导致“半启用”；
  5. 规则层：配置里是否存在 DOMAIN/IP/PROCESS 直连规则把流量打回本地；
  6. 应用层：目标程序是否使用独立网络栈、VPN 或虚拟机桥接；
  7. 路径层：MTU 是否异常，UDP/QUIC 是否被本地防火墙干扰。

一句话实践建议

把 TUN 全局代理理解成“用虚拟网卡重写本机默认出站路径”，而不是一个神秘的加速开关。先确认双栈路由和 DNS 真的进入隧道，再谈节点快慢与协议优劣；否则你优化的可能只是一半流量，另一半仍在本地网络上裸奔。

主要技术资料