V2RayN的TUN模式与系统代理有什么区别？如何选择？

一、先厘清边界：两个模式改的根本不是同一层

在 v2rayN 的日常使用中，TUN 模式与系统代理的区别，往往决定了你到底有没有把「该走的流量」真正接管进来。两者听起来都像「全局生效」，但底层动手的位置完全不同：一个改的是应用层的代理约定，另一个改的是操作系统的路由与网卡。把这一层分清楚，后面关于覆盖范围、日志与权限的讨论才有落脚点。

先把术语摊开。系统代理（System Proxy）是操作系统提供的一组合约：Windows 把它存在当前用户的 Internet 设置里，macOS 把它存在各个网络服务的「代理」页签中，Linux 桌面环境则多半通过环境变量（http_proxy、https_proxy、all_proxy）或桌面环境的代理面板传递。凡是主动去读这些设置的应用，就会把请求交给代理；不读的，就当它不存在。

TUN 模式走的是另一条路。TUN 是操作系统提供的一种虚拟网络设备，工作在网络层（IP 层）。开启 TUN 后，客户端会创建一块虚拟网卡并调整路由表，让原本要发往物理网卡的 IP 包先被送进这块虚拟网卡，再由代理内核接手转发。这条链路上，应用完全不需要知道代理的存在，也就谈不上「配合」与否。

这个差别决定了两者的适用边界。系统代理更像君子协定，配置轻、可逆、权限要求低；TUN 模式更像接管交通，覆盖面广、对系统侵入深、通常需要更高权限。选择哪一个，本质上是在回答：你需要接管的，是「愿意配合的应用」，还是「整台机器的 IP 流量」。

二、接管范围对比：谁被接管，谁被漏掉

很多人第一次意识到区别，是在装了 TUN 之后发现某个原本死活连不上的工具突然通了。反过来，也有人在只开系统代理时，发现浏览器正常、命令行却一直在超时。这两类现象都指向同一个原因：接管范围不同。

对比维度	系统代理	TUN 模式
作用层	应用层，依赖应用主动读取	网络层，IP 包被虚拟网卡截获
典型覆盖	浏览器、Electron 桌面应用、部分开发工具	绝大多数基于 IP 的 TCP/UDP 流量
典型漏网	不读系统设置的命令行程序、部分游戏、Java 应用	被路由排除的网段、部分容器网络、部分虚拟机
权限要求	普通用户即可	通常需要管理员/root 权限与驱动支持
回退难度	关闭开关即恢复	需同时恢复路由与虚拟网卡状态
DNS 处理	多由应用或代理协议决定	需要在本地配置 DNS 模块介入

一个具体的例子：假设你在同一台机器上同时用浏览器查资料、用 curl 拉一个包、再开一个基于自研 UDP 协议的联机游戏。只开系统代理时，浏览器大概率正常，curl 与游戏通常不受影响，因为前者只认环境变量、后者根本不看系统设置。切到 TUN 后，三者都会先进入虚拟网卡，能否正常连通则取决于内核的 UDP 处理能力与分流规则。

三、从可审计性看差异：日志里究竟能看到什么

如果把「合规与数据留存」当作一条主线，那么两个模式最值得关注的区别不在速度，而在可观测性：你究竟能拿到多完整的连接清单。下面分三层来看这件事。

3.1 连接级记录的覆盖度

v2rayN 主界面提供日志面板，展示的是代理内核输出的运行信息，粒度受日志等级设置影响。系统代理模式下，只有那些主动把流量交给代理的应用才会在内核中留下记录；其余应用的连接由系统直接发出，内核对此一无所知。TUN 模式下，被虚拟网卡截获的 IP 连接都会经过内核，记录覆盖面明显更宽。

但要注意，「更宽」不等于「完整」。命中直连规则的目标、被路由排除的网段、以及内核未处理的协议，都不会出现在日志里。经验性观察是：在高等级日志下，TUN 模式能呈现的连接条目数量通常远多于系统代理模式，两者的差集基本就是「不读系统代理设置的那批应用」。

3.2 DNS 查询落在哪里

这是两条链路里最容易被忽略的一处差异。系统代理模式下，如果应用走的是 SOCKS5 或 HTTP CONNECT 并传递域名，DNS 解析发生在代理侧，本地不会留下对应的查询记录；但若应用自己先解析成 IP 再发起连接，本地 DNS 查询就照常落在系统解析器上。

TUN 模式下，DNS 通常需要内核的 DNS 模块介入，例如通过 fake-ip 之类的机制在本地先行应答。如果这部分没有配置好，典型表现是「能连通 IP、一解析域名就卡住」，或者出现解析结果与预期不符的情况。排查时先看内核日志里有没有 DNS 相关报错，比反复重启客户端更有效。

3.3 三个需要提前知道的盲区

第一是 UDP。不同内核、不同配置对 UDP 的支持程度不一致，日志中 UDP 关联的条目往往不如 TCP 清晰。第二是进程级分流。如果规则里按进程名做了直连或代理，那么这部分流量会绕过默认路径，记录形态也随之改变。第三是 IPv6。部分环境下 IPv6 的接管与 IPv4 并不同步，容易出现「v4 走了代理、v6 直连出去」的情况。

可复现的验证方法：把日志等级调高，先在系统代理模式下运行一段时间，记录日志面板中出现的连接条目；再切到 TUN 模式、用相同的应用组合重复一遍，对比两次记录的条目差异。预期可观测到的现象是：TUN 模式下的条目集合会包含系统代理模式下的子集，并额外出现若干此前未出现的条目。

四、版本差异与运行前提

截至当前的最新版本，v2rayN 的界面选项与所依赖的内核能力仍在演进。写这篇对比时使用的判断依据，来自公开可查的通用机制而非某一个具体构建号，因此下面的路径描述以「能稳定复现的操作序列」为主，具体文案请以你本地实际界面为准。

4.1 内核分工：Xray 与 sing-box

较新版本的 v2rayN 允许在参数设置中选择内核类型，常见选项覆盖 Xray 与 sing-box 两条路线。经验性观察是，TUN 相关能力在不同内核上的成熟度并不一致：部分内核把 TUN 作为一等公民内置支持，另一些则需要依赖额外的网络组件。这直接影响你在参数设置里能看到的开关形态——有的版本是一个复选框，有的版本是下拉选项。

因此，如果你在参数设置里找不到 TUN 相关条目，第一件事不是怀疑版本坏了，而是确认当前选中的内核是否支持，以及是否需要先切换内核再重启客户端。这类切换属于离线操作，不会影响既有订阅配置，但建议在切换前导出一次配置备份。

4.2 权限、驱动与系统组件

TUN 模式需要在系统里创建虚拟网卡，因此在 Windows 上通常要求以管理员身份运行，并可能需要安装或调用 TUN 驱动组件；在 Linux 上则对应创建 tun 设备与调整路由表，通常需要 root 或相应的 capability。macOS 上同样涉及网络扩展与权限授权。

边界条件很明确：在受管设备、公司统一分发的终端、或不允许安装网络驱动组件的环境里，TUN 模式可能根本无法启用，或启用了也会被安全软件拦截。这种情况下，系统代理是唯一可行的选项，而不是「退而求其次」。

五、操作路径：桌面端最短可达路径

需要先说明平台定位：v2rayN 主要面向桌面端使用。移动端概念相近但属于不同的客户端形态，菜单与路径无法逐一对齐，本文不对移动端的具体界面路径做描述，以免与真实 UI 不符。

5.1 启用系统代理

最短路径：打开 v2rayN 主界面 → 顶部菜单「设置」→「系统代理」→ 在子菜单中选择自动配置类选项。勾选生效后，Windows 的当前用户 Internet 设置会被写入代理地址与端口。

想验证是否真的写进去了，可以在 Windows 上打开「Internet 选项 → 连接 → 局域网设置」，查看代理服务器一栏；也可以在命令行执行 reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" 观察 ProxyEnable 与 ProxyServer 两项的值。在 macOS 上，对应的验证方式是执行 networksetup -getwebproxy 系列命令（具体参数以你的系统版本为准）。

同一菜单下通常还会看到「不改变系统代理」「清除系统代理」等条目，它们的语义分别是「不动系统设置」与「主动还原系统设置」。切换代理模式前先选「清除系统代理」，可以避免旧配置残留造成的怪异现象。

5.2 启用 TUN 模式

最短路径：主界面「设置」→「参数设置」→ 进入内核基础设置页 → 勾选或选择 TUN 模式相关选项 → 保存 → 以管理员权限重启客户端。重启后主界面通常会给出状态提示，也可能在系统网络适配器列表里多出一块虚拟网卡。

为什么必须重启而不是立即生效？因为创建虚拟网卡与改写路由表属于系统级操作，需要在进程启动时完成初始化。这也是为什么在 TUN 模式下切换节点通常无害，但切换内核类型往往要求重启。

5.3 回退路径：如何干净地关掉

回退分两步。第一步，在参数设置里取消 TUN 选项；第二步，检查系统网络适配器里是否残留虚拟网卡，以及路由表中是否还有指向它的条目。Windows 上可用 route print 查看默认路由，Linux 上可用 ip route show。

如果关闭 TUN 后出现「上不了网」的情况，多半是默认路由仍指向已失效的虚拟网卡。处置方式是重启网络适配器或直接重启系统，让操作系统重新选举默认路由。这类问题在实践中并不罕见，属于 TUN 模式必须承担的运维成本。

六、平台差异速查

同一套概念在不同桌面系统上的落地方式差别不小，下面把关键差异压缩成一张表。需要强调的是，具体入口名称随版本变化，表格只描述机制层面的对应关系。

平台	系统代理落点	TUN 依赖
Windows 桌面	当前用户 Internet 设置	管理员权限 + TUN 驱动组件
macOS 桌面	各网络服务的代理页签	网络扩展授权
Linux 桌面	环境变量或桌面代理面板	tun 设备与路由权限
移动端	不适用同一套设置项	通常以 privacy tool 服务形式实现类似接管，路径与桌面不一致

从这张表可以读出一条规律：越往下，客户端能做的事越受系统授权模型约束。桌面 Linux 是最灵活但也最需要手工排查的一档；移动端虽然接管方式更接近 TUN 的效果，但配置入口与排障路径完全是另一套体系。

七、迁移步骤：从系统代理切到 TUN 的五步

如果你已经用了一段时间系统代理，想切到 TUN，建议按下面的顺序走，每一步都有明确的观察点，出问题时能快速定位到是哪一环。

1. 备份现有配置。导出订阅与本地规则，避免切换内核后出现配置兼容问题。
2. 清除系统代理。在主菜单先选「清除系统代理」，让系统设置回到干净状态，避免两套机制同时生效。
3. 确认内核与权限。在参数设置里核对当前内核类型，确认它支持 TUN；随后以管理员权限重启客户端。
4. 开启 TUN 并观察。勾选 TUN 选项后重启，打开系统网络适配器列表或查看路由表，确认虚拟网卡与默认路由已就位。
5. 逐项回归测试。先测浏览器，再测命令行工具，最后测你真正关心的那个应用。

第 5 步为什么要逐项来？因为「整体通不通」这个信号太粗糙。当浏览器正常而命令行不通时，说明 TUN 层已经工作，问题出在分流规则或 DNS；当浏览器也不通时，问题更可能在网卡或路由层面。把观察点分开，能省下大量试错时间。

什么时候不该做这次迁移？如果你的工作环境明确禁止修改网络栈、或终端由统一策略管理、或你只需要让浏览器走代理，那么停留在系统代理是更合理的选择。迁移的前提是「有应用确实绕过了系统代理」，而不是「TUN 听起来更高级」。

八、兼容性对照表

下面按常见软件类型列出两类模式下的典型表现。表格内容是机制推导出的普遍规律，具体到某个版本仍可能不同，建议以实测为准。

软件类型	系统代理	TUN 模式
主流浏览器	通常生效	通常生效
curl / wget 等命令行工具	需自行设置环境变量	通常生效
Git 等开发工具	多数需单独配置代理参数	通常生效
Java 运行时应用	默认不读取，需显式参数	通常生效
使用自定义 UDP 协议的游戏	通常不生效	取决于内核 UDP 支持
容器 / WSL 内进程	通常不生效	不经额外配置时常常不生效
虚拟机内客户机	通常不生效	视网络模式而定，常需单独处理

表中最后两行值得多说一句。容器与虚拟机各自拥有独立的网络命名空间或虚拟交换层，宿主机的 TUN 接管的是宿主机这一侧的流量，客户机内部的出站往往走的是另一条路径。经验性观察是：这两类场景下，指望开一个 TUN 开关就全部搞定，通常会失望。

九、故障排查：现象 → 可能原因 → 验证 → 处置

下面按现象组织，每条都给出验证动作。这样做的目的是让排查从「猜」变成「测」。

现象一：开启 TUN 后完全无法上网

可能原因是虚拟网卡未成功创建、默认路由指向失效接口，或管理员权限不足导致初始化失败。验证方式：查看系统网络适配器列表是否出现新网卡，并用路由查看命令确认默认路由的下一跳。处置方式是检查客户端日志的启动段、确认以管理员身份运行、必要时重启系统恢复路由。

现象二：能打开 IP，打不开域名

可能原因是 DNS 模块未正确接管，本地解析器仍在用旧配置。验证方式：分别用 IP 与域名访问同一目标，观察差异；同时查看内核日志中是否有 DNS 相关报错。处置方式是检查 DNS 相关配置项是否启用，并在切换网络环境后重新确认。

现象三：切换 TUN 后某些应用反而失效

可能原因是分流规则把这些目标判给了直连，而 TUN 接管后原本可用的直连路径被改变。验证方式：临时调整日志等级，观察这些应用的目标地址命中了哪条规则。处置方式是修正规则或把这些目标加入例外。

现象四：关闭 TUN 后系统残留代理设置

可能原因是系统代理与实际链路状态不一致。验证方式：查阅前文提到的注册表项或系统命令行查代理。处置方式是手动执行「清除系统代理」，或直接在系统设置中还原。

十、风险控制与边界：什么时候不该开 TUN

TUN 模式改变了整机的网络栈行为，这既是它的价值，也是它的风险来源。从可审计角度看，最大的一类风险是「你以为被记录的流量其实没被记录」：命中直连规则的目标、被路由排除的网段、以及内核未处理的协议，都不在日志覆盖范围内。如果留存日志的目的是做流量清单审计，这些盲区必须提前在文档里写明，而不是事后解释。

第二类风险是权限。以管理员身份运行的网络组件，一旦配置出错，影响面是整台机器而非单个应用。因此建议在启用 TUN 前记录一次基线状态：默认路由、DNS 配置、网络适配器列表。这份基线在出问题时价值极高。

第三类风险是合规边界。在单位终端或个人设备上启用 TUN，取决于所在地与所在组织对网络行为的约定。本文只讨论技术机制与可观测性，不构成任何合规建议；是否启用、如何留存日志，应当依据适用的规则自行判断。

十一、适用与不适用场景清单

把选择标准压缩成一组准入条件，比记忆功能描述更实用。

适合用系统代理的情况：主要需求集中在浏览器与少数桌面应用；你只有普通用户权限；所在终端由统一策略管理、不允许安装网络组件；你需要快速开、快速关，且不希望留下路由残留。

适合用 TUN 模式的情况：确实存在不读系统代理设置的应用需要被接管；你能拿到管理员权限；你接受在异常时需要手工恢复路由；你希望得到覆盖面更广的连接记录。

两者都不适合硬扛的情况：容器内部与虚拟机内部的出站流量，通常需要在各自环境里单独配置，而不是靠宿主机的一个开关解决。

十二、最佳实践检查表

下面这份清单可以直接当作切换前的自检流程，按顺序过一遍，能规避掉大部分常见问题。

• 切换前导出配置，确认订阅与本地规则可恢复。
• 先清除系统代理，再启用 TUN，避免两套机制叠加。
• 确认当前内核支持 TUN，必要时切换内核后重启客户端。
• 记录一次基线：默认路由、DNS 设置、网络适配器列表。
• 启用 TUN 后以管理员权限运行，并确认虚拟网卡已出现。
• 日志等级按需调整，用完及时恢复，不为长期审计默认开启最高等级。
• 逐项回归测试：浏览器 → 命令行 → 目标业务应用。
• 若结果不符合预期，先回退到系统代理恢复可用状态，再逐步定位。

这份清单里最容易被跳过的是第四条。基线记录看起来多余，但当默认路由被改坏、又要在一台已经无法联网的机器上排查时，它就是唯一的参照物。

十三、常见问题（FAQ）

十四、小结与下一步行动

回到最初的问题：TUN 模式与系统代理的区别，核心不在速度，而在接管范围与可观测性。系统代理改的是应用愿意遵守的约定，轻量、可逆、覆盖面窄；TUN 模式改的是操作系统的路由与网卡，覆盖面宽、权限要求高、回退成本也更高。从可审计角度看，TUN 能提供更完整的连接记录，但「更完整」不等于「全覆盖」，路由排除项、直连规则与未处理协议始终构成盲区。

选择的方法可以简化成一句话：如果问题出在「某些应用不吃系统代理」，那就上 TUN；如果需求只是让浏览器走代理，就留在系统代理。不要为了追求概念上的彻底而引入不必要的运维负担。

下一步建议按这个顺序做三件事。第一，记录当前环境的网络基线，包括默认路由、DNS 配置与适配器列表，这份记录在出问题时价值最大。第二，按前面的五步迁移流程做一次小范围切换，并逐项回归测试，确认哪些应用的表现发生了变化。第三，依据实测结果决定长期停留在哪个模式，而不是依据印象。

最后提醒一句关于版本的现实：v2rayN 的界面与内核能力仍在持续演进，本文描述的是机制层面的稳定差异，具体到菜单文案与开关位置，请以你本地实际安装的版本为准。经验性观察是，这类客户端正把越来越多的网络层能力下沉到内核实现，界面上的开关形态也随之在不同构建之间摆动；因此与其记住某个菜单长什么样，不如记住它背后改动的是哪一层。遇到与描述不符的地方，先对照客户端日志确认实际生效的机制，再做判断，这套判断依据不会因界面改版而失效。