TUN模式是什么？和系统代理有什么区别？
TUN 模式是代理客户端在操作系统里创建一块虚拟网卡，在网络层把设备的全部流量——包括 UDP 和那些根本不认系统代理的程序——统一接管进代理隧道；而"系统代理"只是在系统设置里登记一个 HTTP/SOCKS 入口，应用可以用，也可以完全无视它。一句话概括区别：系统代理是"通知"，TUN 模式是"接管"。
TUN模式到底是怎么工作的？
一句话定义：TUN 模式是指代理客户端向操作系统注册一块虚拟网卡（TUN 设备），并把系统默认路由指向它，使所有出站 IP 数据包先进入代理客户端、由客户端决定走代理还是直连。因为拦截发生在网络层（IP 层），应用程序对此完全无感——它以为自己在正常联网，实际上每一个数据包都先经过了代理客户端之手。这带来两个直接好处：一是覆盖面完整，浏览器、命令行工具、游戏客户端一视同仁；二是 DNS 查询这类 UDP 流量也在接管范围内，不再有"漏网之鱼"。部分客户端把这个功能叫"增强模式"或"虚拟网卡模式"，本质是同一件事。
系统代理又是怎么回事？
一句话定义：系统代理是操作系统提供的一项"通告"设置，告诉应用程序"本机有一个 HTTP/SOCKS 代理入口，建议你把流量发给它"——是否照做完全取决于应用自己。浏览器和大多数图形界面软件会遵守这个通告，所以日常网页浏览看起来一切正常。但它有两个天然短板：第一，很多程序不读这个设置，典型如命令行工具（curl 需要单独配环境变量）、部分桌面客户端和游戏；第二，它工作在应用层，主要面向 TCP/HTTP 流量，系统层面的 DNS 查询、UDP 数据包通常不在覆盖范围内。这正是"开了代理却还有 DNS 泄露"最常见的根源之一。
什么情况下必须用TUN模式？
结论：只要你需要"全部流量、无一遗漏"地走代理，就应该用 TUN 模式。典型的三类场景：
- 命令行和后台程序：终端里的 git、pip、docker 等工具默认不认系统代理，逐个配环境变量既繁琐又容易漏。TUN 模式下它们自动走代理，无需任何单独配置。
- 游戏和实时语音的 UDP 流量：系统代理基本管不到 UDP，而外服游戏和语音通话大量依赖 UDP。TUN 模式在网络层接管，UDP 与 TCP 一同处理。
- 防止 DNS 和 WebRTC 绕过泄露：系统层 DNS 查询和 WebRTC 的 UDP 探测都可能绕开系统代理直连出去，暴露真实位置。TUN 模式把这些流量一并收进隧道，是修复此类泄露最彻底的手段。
顺带一提 fake-ip：这是 TUN 模式下常见的 DNS 处理策略——客户端先给域名返回一个假的内网 IP 占位，等应用真正发起连接时再在代理侧完成真实解析，既加快响应又避免本地解析泄露。多数客户端默认配置即可，无需深究，具体行为以你所用客户端的官方文档为准。
系统代理和TUN模式怎么对比？
先说结论：TUN 模式在覆盖能力上全面占优，系统代理胜在轻量和零权限。对照下表按需选择：
| 对比维度 | 系统代理 | TUN 模式 |
|---|---|---|
| 接管范围 | 仅遵守代理设置的应用（主要是浏览器等） | 全系统所有应用的出站流量 |
| UDP 支持 | 基本不支持，游戏/语音流量走直连 | 完整支持，UDP 与 TCP 同等接管 |
| DNS 接管 | 系统 DNS 查询通常绕过代理，易泄露 | DNS 查询一并接管，可配合 fake-ip 策略 |
| 权限要求 | 普通用户权限即可 | 需要管理员权限或安装系统扩展/驱动 |
| 兼容性 | 极少冲突，随开随关 | 偶发与虚拟机、其他 VPN 软件、安全软件冲突 |
| 资源开销 | 几乎无额外开销 | 所有数据包过一遍客户端，耗电与 CPU 略增 |
TUN模式有什么代价和坑？
结论：TUN 模式的代价是权限、功耗和偶发兼容问题，对多数人可以接受。首先是权限——创建虚拟网卡需要管理员权限，macOS 上通常还要批准系统扩展，Windows 上要安装虚拟网卡驱动，首次开启时的授权弹窗属于正常流程。其次是开销——所有数据包都要经过代理客户端处理，笔记本电脑的耗电会略有增加，一般感知不明显。最后是兼容性——TUN 模式接管了默认路由，与虚拟机网络、其他 VPN 客户端或某些安全软件同时运行时偶尔会互相干扰，表现为断网或流量绕行；遇到这类问题优先排查是否有多个软件在抢路由。各客户端的开关名称和授权步骤随版本变化，以官方文档为准。
常见问答
开了TUN模式还需要开系统代理吗？
一般不需要，TUN 模式已经覆盖了系统代理的全部能力。两者同时开通常也不冲突（走系统代理的流量同样会被客户端处理），但为了排查问题时路径清晰，建议开 TUN 后关掉系统代理，保持单一接管入口。
TUN模式能修复DNS泄露吗？
能，而且是最彻底的修复方式之一。DNS 泄露的根源是解析请求绕过代理直连出去，TUN 模式在网络层把 DNS 查询一并收进隧道，绕过的路径被堵死。开启后到 DNS 泄露检测 重测一次即可确认。
TUN模式会让网速变慢吗？
影响很小，多数场景感知不到。所有数据包过一遍客户端确实有处理开销，但瓶颈几乎总在代理线路本身而不是本机转发。如果开启 TUN 后速度明显下降，优先怀疑分流规则把本该直连的流量也送进了代理。
手机上有TUN模式吗？
有，形式略有不同。iOS 和 Android 的代理类 App 基本都通过系统的 VPN 接口实现全局接管，效果等同于桌面端的 TUN 模式——这也是它们安装时会请求"添加 VPN 配置"权限的原因。手机上反而很少有"只设系统代理"的形态。
为什么开TUN模式要输管理员密码？
因为创建虚拟网卡和修改系统路由表是操作系统级操作，必须有管理员权限。这是 TUN 模式的固有要求而非软件问题；如果你使用的是可信的客户端，正常授权即可。
真实使用场景
一位做独立开发的读者反馈：浏览器访问外网一切正常，但终端里 git clone 和 pip install 慢得离谱甚至超时，他以为是代理线路的问题，换了好几条节点都没用。实际原因是他只开了系统代理——浏览器遵守代理设置所以正常，而命令行工具根本不读这个设置，一直在直连。他曾尝试给终端逐个配 http_proxy 环境变量，但 docker、ssh 各有各的配法，顾此失彼。最后在客户端里打开 TUN 模式，管理员授权后所有终端工具自动走了代理，git 和 pip 立刻恢复正常。他顺手在本站跑了 DNS 泄露检测 和 WebRTC 泄露检测，发现之前一直存在的 DNS 泄露也随之消失了——系统代理时代漏出去的 DNS 查询，被 TUN 模式一并收编了。