外观
TUN 模式与系统代理：区别、开启方法与常见问题
系统代理是向操作系统声明“请把网络请求交给本地某个端口”，只有愿意遵守这一声明的应用才会照做；TUN 模式则是客户端创建一块虚拟网卡并调整路由，让几乎所有出站流量先到达客户端，不依赖应用是否配合。
因此当某个应用、命令行工具或游戏不走代理时，才需要考虑开启 TUN；只用浏览器和常见桌面软件时，系统代理通常已经够用，并且冲突更少。
核心结论与适用条件
- 如果你的需求只是让浏览器和主流桌面软件走代理，那么系统代理足够，它不需要管理员权限，也不改动路由表，出问题时关闭开关即可恢复。
- 如果有应用不读取系统代理设置，例如部分命令行工具、某些开发环境、游戏启动器或自带网络栈的客户端，那么需要考虑 TUN 模式或为该应用单独设置代理端口。
- 如果你同时安装了其他 VPN、虚拟机网络或安全软件的网络防护模块，那么开启 TUN 之前先确认它们不会争抢虚拟网卡与路由，否则会出现断网或域名无法解析。
- 如果你在 macOS 上首次开启 TUN，系统弹出授权窗口属于正常机制，具体授权流程见macOS 权限说明。
- 如果你只想弄清当前流量分流逻辑，TUN 与出站模式是两个独立开关，出站模式的选择见规则、全局与直连模式。
上述结论的前提是客户端来自官方发布渠道、内核支持你的协议、同一时间只有一个接管者。本文只讲机制、使用时机和排错思路，不针对任何软件的具体版本、默认值或菜单路径作断言；开关的位置请在设置中找到“TUN”或“虚拟网卡”相关选项。若想先了解桌面端整体方案，可以回到桌面客户端专题。
一句话看懂区别：谁来“指路”
可以用一个比喻理解。系统代理像是在公司前台贴了一张通知：“寄快递请交给 3 号窗口”。自觉看通知的员工会照办，不看通知的员工直接自己去寄。TUN 则像是把整栋楼的出口只留一个，所有包裹无论员工是否知情，都必须经过这个出口。前者依赖自觉，后者依赖结构。
从技术角度看，系统代理工作在应用层：应用库在发起请求前读取系统代理设置，把请求以 HTTP 代理或 SOCKS 代理的格式发给本地端口。TUN 工作在网络层：客户端通过虚拟网卡接收 IP 数据包，再用自己的协议栈把这些数据包还原成连接，并按出站规则处理。这就是为什么 TUN 能接管不遵守系统代理的程序，也是为什么它需要更高的权限和更谨慎的配置。
两者也可以同时存在，但同时开启并不总是更好：多数应用走系统代理时会先连本地端口，没有走系统代理的应用才会被 TUN 兜住，规则匹配则发生在客户端内部。若配置不当，同一条流量可能被处理两次，表现为延迟异常或连接重置。
两种接管方式的技术参数对照
下表比较两种方式的机制差异。表中不含任何速度、延迟或资源占用数值，“统计口径”说明该行属于机制描述还是经验归纳；缺失的内容写待核实或 Not Tested。
| 指标 | 系统代理 | TUN 模式 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|
| 工作层次 | 应用层，HTTP 或 SOCKS 代理 | 网络层，虚拟网卡与路由 | — | 机制描述 | 通用技术资料 | 2026-10-18 |
| 是否需要应用配合 | 需要，应用须读取系统设置 | 不需要 | — | 机制描述 | 通用技术资料 | 2026-10-18 |
| 权限要求 | 通常无需管理员权限 | 通常需要管理员或系统授权 | — | 常见情况 | 通用技术资料 | 2026-10-18 |
| 对路由表的改动 | 无 | 有 | — | 机制描述 | 通用技术资料 | 2026-10-18 |
| 可接管的协议范围 | 以 TCP 请求为主，取决于应用 | 可覆盖 TCP 与 UDP 等 | — | 机制描述 | 通用技术资料 | 2026-10-18 |
| 命令行工具 | 通常需另设环境变量 | 通常可直接覆盖 | — | 经验归纳 | 通用技术资料 | 2026-10-18 |
| 与其他 VPN 的冲突风险 | 较低 | 较高 | — | 经验归纳 | 通用技术资料 | 2026-10-18 |
| 故障时的恢复方式 | 关闭系统代理开关 | 关闭 TUN，必要时重启网络 | — | 经验归纳 | 通用技术资料 | 2026-10-18 |
| 对节点流量的影响 | 取决于出站模式与规则 | 同上，且更多应用的流量被纳入 | — | 机制推导 | 通用技术资料 | 2026-10-18 |
| 实测稳定性 | Not Tested | Not Tested | — | 本站测试状态 | 本站 | 2026-10-18 |
“对节点流量的影响”一行需要特别说明：TUN 本身不额外消耗流量，但它让更多原本不走代理的应用被纳入客户端，若出站模式把这些流量送往节点，套餐流量的消耗来源就变多了。
什么时候真正需要开 TUN
场景一：命令行工具与开发环境
多数命令行下载工具、包管理器、版本控制工具并不读取操作系统的代理设置，而是读取环境变量或自己的配置文件。开启 TUN 后，这些工具的出站连接会被虚拟网卡捕获，无需逐个配置。但这并不意味着一定要用 TUN：给终端会话设置代理环境变量指向客户端本地端口，影响范围更小，也不需要额外权限。对 IDE 与终端的细节可参考开发环境代理设置与终端代理设置。
场景二：不遵守系统代理的桌面应用
部分应用自带网络库，启动时不查询系统代理；部分应用只代理自己的主界面请求，而后台更新、遥测、媒体流使用另一套通道。这类应用表现为“浏览器能上、某个软件上不去”。此时可以先在客户端的连接面板中观察该应用是否产生连接记录：如果没有记录，说明它没经过本地端口，TUN 是可选方案；如果有记录但命中了直连规则，则是规则问题，与接管方式无关。
场景三：UDP 流量与实时应用
系统代理的 HTTP 代理形态天然面向 TCP 请求，SOCKS 代理可以承载 UDP，但需要应用本身实现对应支持。实时通话、部分游戏和基于 QUIC 的流量依赖 UDP，若应用不支持 SOCKS 的 UDP 转发，系统代理方式就无法覆盖。TUN 在网络层捕获数据包，理论上能覆盖这类流量，但实际表现还取决于内核实现与所选协议对 UDP 的支持，这一点品牌资料没有提供，应当待核实并以实际测试为准。
场景四：希望统一接管、减少遗漏
有人希望“只要开着客户端，一切流量都被规则处理”，不愿意逐个检查应用。TUN 满足这种需求，但代价是要承担更高的配置复杂度：需要处理 DNS、本地网络排除、与其他网络软件的共存。如果没有这类需求，没有必要为了“看起来更彻底”而开启。
不需要开 TUN 的典型情形
只使用浏览器、聊天软件、办公软件，且这些软件都遵守系统代理；设备上还有公司 VPN 或校园网认证客户端；使用的是权限受限的公共电脑或受管设备，无法获得管理员权限。这些情形下系统代理更稳妥。
开启 TUN 之前的检查清单
虽然各客户端界面不同，但开启前的准备是通用的，建议按顺序检查：
- 确认内核可用：协议是 VLESS 等较新协议时，需要 mihomo 或同类内核，见内核差异说明；节点连通性应在系统代理模式下先验证，避免把节点故障误认为 TUN 故障。
- 确认权限：Windows 上以管理员方式运行或安装服务组件，macOS 上准备接受系统授权，Linux 上以 root 或授予所需网络能力运行。具体步骤请在对应系统的客户端说明中查阅。
- 清理冲突：关闭其他 VPN 或代理类软件；检查网络适配器列表中是否留有旧的虚拟网卡；暂时关闭可能拦截虚拟网卡流量的安全防护功能进行对照测试。
- 关闭系统代理中的重复接管：很多客户端在 TUN 开启时会建议关闭系统代理，以避免流量被处理两次；是否需要关闭取决于客户端设计，可参考其说明。
- 准备回退方案：知道如何迅速关闭 TUN，并记住关闭后需要检查网络是否恢复，必要时重启网络适配器。
- 确认 DNS 设置：TUN 与 DNS 处理关系紧密，开启前了解客户端的 DNS 相关选项，避免域名解析异常。
开启后的验证顺序
开启后不要立即测试复杂业务，建议按以下顺序验证：先确认客户端状态显示 TUN 已生效；再用浏览器访问一个国内站点，确认直连规则正常；再访问一个需要代理的站点，确认代理路径正常；然后在连接面板中观察此前不走代理的那个应用是否出现了连接记录；最后再测试命令行工具。这一顺序把“客户端是否生效”“规则是否正确”“目标应用是否被接管”三个问题分开，任何一步失败都有明确的排查方向。
决策树：系统代理还是 TUN
Decision Path
选择接管方式的判断路径
text
你的网络需求是什么？
├─ 只用浏览器与常见桌面软件
│ └─ 系统代理，不开 TUN
├─ 有应用不走代理
│ ├─ 先看连接面板：该应用有连接记录吗？
│ │ ├─ 有记录且命中直连 → 规则问题，与接管方式无关
│ │ ├─ 有记录且命中代理但不通 → 节点或 DNS 问题
│ │ └─ 无记录 → 应用没有经过本地端口
│ │ ├─ 能给它单独设置代理端口 → 优先单独设置
│ │ └─ 不能设置 → 考虑开启 TUN
│ └─ 是命令行工具 → 先试环境变量，不行再考虑 TUN
├─ 设备受管、无管理员权限
│ └─ 只能使用系统代理或应用内代理设置
├─ 已安装其他 VPN 或虚拟网卡软件
│ └─ 先关闭其他软件，单独验证后再开 TUN
└─ 开启 TUN 后网络异常
└─ 关闭 TUN 恢复，再按“症状排错”逐项检查决策树里反复出现“先看连接面板”，因为它是区分接管问题与规则问题的最快手段，没有连接记录就说明流量没到客户端，再改规则也无济于事。
常见症状与排错
症状一：开启 TUN 后完全断网
最常见的原因是虚拟网卡与路由配置冲突，或客户端没有获得足够权限，导致路由被改动但数据包无法到达客户端。处理方式是先关闭 TUN，确认网络恢复；然后检查权限与其他网络软件；再重新开启并观察。如果关闭 TUN 后网络仍未恢复，可以尝试重启网络适配器或系统，必要时检查是否残留了异常路由。
症状二：能上网但域名无法解析
TUN 与 DNS 紧密相关。如果客户端启用了自己的 DNS 处理，而系统的 DNS 设置与之冲突，或系统服务占用了 DNS 端口，就会出现能 ping 通 IP 但打不开网站的情况。排错方法是对比：用 IP 地址访问能否成功，再检查客户端 DNS 选项以及系统 DNS 管理服务是否与之冲突。Linux 上 NetworkManager 或系统解析服务的接管行为是常见来源。关于 DNS 的安全含义，可阅读协议与安全机制专题。
症状三：部分应用仍然不走代理
检查三点：应用是否在客户端设置的绕过列表中；规则是否把它的流量判定为直连；应用是否使用了客户端无法解析的特殊网络通道，例如内置的加密 DNS 或自带代理。有些应用会自行处理 DNS 查询，导致客户端无法按域名匹配规则，此时需要在规则中使用 IP 或进程名匹配，或在应用内关闭相关选项。
症状四：局域网设备无法访问
开启 TUN 后，如果私有地址段没有被排除，局域网请求可能被送入虚拟网卡再由规则处理。多数客户端默认对局域网有直连处理，但如果你的配置覆盖了默认规则，就需要确认私有地址段的直连规则仍然存在。同时要注意全局模式会让这个问题更明显。
症状五：开启后速度或稳定性变差
这类现象可能与多个因素有关：数据包经过虚拟网卡与客户端协议栈本身有处理开销；规则匹配方式变化；节点选择不同；DNS 变化。本站没有速度测试数据，任何速度差异都应由你在自己的环境中对比测试，不应假定 TUN 一定更快或更慢。
症状六：关闭客户端后网络异常
如果客户端异常退出，TUN 创建的虚拟网卡或路由可能残留，导致断网。处理方式是重新启动客户端后正常关闭 TUN，或在网络适配器列表中禁用残留的虚拟网卡；系统代理方式则要检查系统代理开关是否仍被保留。这类“残留”问题说明接管层的清理是客户端退出流程的一部分，建议总是通过客户端正常退出，而不是强制结束进程。
症状七：与自研客户端同时运行
机场自研客户端和第三方客户端同时运行，都试图创建虚拟网卡或修改系统代理，会造成冲突。同一时间只保留一个运行，是最稳妥的做法。自研客户端与第三方客户端的取舍见自研与第三方客户端对比。
知识图谱：TUN 与系统代理的概念关系
实体定义
TUN 是操作系统提供的虚拟网络设备类型，工作在 IP 层，用户态程序可以通过它读取和写入 IP 数据包。系统代理是操作系统保存的一组代理设置，供应用在发起网络请求时读取。两者都是“接管层”的实现方式，与“出站决策”和“节点选择”分属不同层次。
相关概念
上位概念是桌面代理客户端的接管机制；平行概念包括浏览器内的代理插件与应用内代理设置，见浏览器代理插件说明；下位概念包括虚拟网卡、路由表、DNS 劫持、协议栈；依赖概念包括管理员权限、系统授权、内核对 TUN 的支持。路由器端的类似方案在路由器 DNS 说明中有相关讨论。
技术参数
可观察的参数包括：虚拟网卡是否存在并处于启用状态、路由表中默认路由的变化、客户端连接面板中的连接数、DNS 解析结果、系统代理开关状态。这些参数都可以在系统网络设置与客户端界面中读取，无需第三方工具。
适用场景
系统代理适用于浏览器与遵守系统设置的应用；环境变量适用于命令行会话；应用内代理适用于支持自定义代理的单个软件；TUN 适用于需要统一接管、应用不配合或需要覆盖更多协议的情形。
对比依据
比较接管方式的依据应是覆盖范围、权限要求、冲突风险与恢复成本，而不是主观速度。覆盖范围越大，对系统的改动越多，出问题时影响范围也越大。
常见问题指向
“为什么开了 TUN 还有应用不走代理”指向规则与 DNS；“为什么系统代理下命令行不走代理”指向环境变量；“为什么 macOS 弹出授权”指向系统权限机制。下文常见问题一并回应。
方案关联：客户端与机场资料如何影响 TUN 使用
TUN 是否可用取决于客户端和内核，而不是机场。不过机场资料会通过两个字段影响你的选择。其一是协议：brands.json 中多数品牌标注 VLESS，这要求内核具备相应协议能力；开启 TUN 之前先在系统代理模式下确认节点连通，可以避免把协议不兼容误判为 TUN 问题。其二是客户端方式：部分品牌提供自研客户端，另一些只支持第三方订阅导入，自研客户端自带的接管方式与第三方客户端并不相同，是否提供 TUN 功能在资料中待核实。
下表列出本文涉及的客户端相关字段及其状态，数据来自品牌公开资料，状态为 Vendor Data，不构成推荐。
| 品牌示例 | 协议字段 | 客户端方式 | 对 TUN 使用的含义 |
|---|---|---|---|
| SOGO云 | VLESS | 自研客户端+第三方订阅导入 | 第三方客户端需使用支持 VLESS 的内核，自研客户端的接管方式待核实 |
| 一翻云 | VLESS | 支持第三方客户端订阅导入 | 需自行选择内核与接管方式 |
| 光速云 | VLESS | 自研客户端+第三方订阅导入 | 同上，价格为年付折算，月付价待核实 |
| 星岛梦 | 待核实 | 支持第三方客户端订阅导入 | 协议待核实，开启前需先确认节点类型 |
想按协议或客户端方式筛选更多品牌，可以进入品牌库；若还没有确定品牌，先回到选型清单。AI 工具与流媒体平台的可用性：品牌资料显示覆盖相关使用场景，具体可用性、解锁状态及节点表现可能随 IP、地区和平台策略变化，建议以最新实际测试结果为准，与接管方式本身无关。
优点、限制与风险提示
优点
- TUN 不依赖应用配合，能覆盖不读取系统代理的应用，减少遗漏。
- 在网络层处理数据包，原理上可以覆盖更多协议类型，包括依赖 UDP 的应用。
- 命令行工具在许多情况下无需逐个配置代理，降低维护成本。
- 系统代理方式配置简单、无需特殊权限，并且出问题时容易恢复。
限制
- TUN 需要更高权限，在受管设备、公共电脑上可能无法使用。
- TUN 与 DNS、路由、其他网络软件的交互复杂，排错门槛高于系统代理。
- 系统代理只对遵守设置的应用有效，覆盖范围由应用决定。
- 不同系统和客户端对 TUN 的实现差异较大，本文只讲通用机制，不对任何版本作承诺。
- 本站没有任何节点或接管方式的实测数据，实际表现为 Not Tested。
风险提示
- 开启 TUN 会修改系统路由与网络设置，操作前应了解回退方式，避免在重要网络环境下直接试验。
- 同时运行多个接管者会造成冲突，也可能让流量被意外地送往不预期的出口。
- 授权给客户端的权限较高，应确认客户端来自官方渠道，避免下载来路不明的安装包。
- 全部流量被纳入客户端后，若出站模式不当，会增加套餐流量消耗，计量口径以官网为准。
- 使用代理服务须遵守所在地区适用的法律法规与目标平台条款，本文仅讨论技术原理与选型。
常见问题
TUN 模式和系统代理有什么区别，什么时候需要开 TUN？
系统代理是应用层的设置，只有读取并遵守该设置的应用才会把请求交给本地代理端口；TUN 是网络层的虚拟网卡方式，能接管不遵守系统代理的应用。只用浏览器和常见软件时系统代理已足够，当有命令行工具或其他应用不走代理时才需要考虑 TUN。
开启 TUN 后可以同时保留系统代理吗？
技术上可以同时存在，但并不总是更好。遵守系统代理的应用会先连接本地端口，其余应用才被 TUN 兜住，配置不当可能让同一流量被处理两次。是否需要关闭系统代理取决于客户端设计，建议参考客户端说明并逐项验证。
为什么开启 TUN 后会断网？
常见原因是虚拟网卡与路由冲突、客户端权限不足，或与其他 VPN、安全软件争抢网络设置。处理时先关闭 TUN 确认网络恢复，再检查权限和其他网络软件，必要时重启网络适配器后重新开启。
开启 TUN 后能 ping 通 IP 却打不开网站，是什么问题？
这通常是 DNS 问题。客户端的 DNS 处理与系统 DNS 设置冲突，或系统服务占用了解析端口，都会导致域名无法解析。可以先用 IP 访问对比，再检查客户端 DNS 选项以及系统 DNS 管理服务是否与之冲突。
命令行工具不走代理，必须开 TUN 吗？
不必须。多数命令行工具读取环境变量，为终端会话设置代理环境变量并指向客户端本地端口，影响范围更小且不需要额外权限。只有环境变量方案不适用或需要统一接管时，才考虑开启 TUN。
macOS 开启 TUN 时弹出系统授权窗口是客户端故障吗？
不是。macOS 对创建虚拟网卡和修改路由有严格的权限控制，客户端需要通过网络扩展或辅助工具获得授权，授权窗口属于系统机制。拒绝授权则无法使用 TUN，只能退回系统代理方式。
TUN 模式一定比系统代理更快吗？
不能这样假定。TUN 需要经过虚拟网卡和客户端协议栈，系统代理则由应用直接连接本地端口，两者的实际表现还受节点、规则、DNS 与本地网络共同影响。本站没有速度测试数据，应在自己的环境中对比测试。
客户端异常退出后网络不正常怎么办？
异常退出可能让虚拟网卡或路由残留，系统代理开关也可能被保留。可以重新启动客户端后正常关闭 TUN，或在网络适配器列表中禁用残留的虚拟网卡，并检查系统代理开关是否已关闭。日常应通过客户端正常退出，而不是强制结束进程。
自研客户端和第三方客户端能同时开 TUN 吗？
不建议。两个客户端都会尝试创建虚拟网卡并改动路由，同时运行会造成冲突。同一时间只保留一个接管者，先用自研客户端验证订阅有效，再退出它并切换到第三方客户端。
开启 TUN 会让套餐流量消耗更多吗？
TUN 本身不额外消耗流量，但它让更多原本不走代理的应用被纳入客户端，若出站模式把这些流量送往节点，节点流量的来源就变多了。套餐的具体计量口径在品牌资料中待核实，应以官网说明为准。
下一步与同集群文章
如果你已经能稳定开启 TUN，下一步是理解出站模式如何与它配合，可以读规则、全局与直连模式的区别；想读懂配置文件里与 TUN 和 DNS 相关的段落，去看配置文件的三段结构；想看图形前端的完整导入流程，去看Clash Verge Rev 安装与订阅导入；Linux 桌面上的权限与运行方式见Linux 桌面方案；手机端的对应概念从移动端客户端专题进入。涉及线路与路由的背景知识可参考线路与路由专题，使用风险部分则见风险专题，整体对比请进入对比中心。
Cluster · clash
Clash 系客户端
- Clash Verge Rev 安装与订阅导入完整步骤如何安装 Clash Verge Rev 并导入订阅？
- mihomo（Clash Meta）内核：与原版 Clash 的差异mihomo 内核和原版 Clash 有什么区别？
- 规则模式、全局模式与直连模式：何时用哪一种Clash 的三种出站模式分别适合什么情况？
- TUN 模式与系统代理：区别、开启方法与常见问题TUN 模式和系统代理有什么区别，什么时候需要开 TUN？
- 读懂 Clash 配置文件：proxies、proxy-groups 与 rulesClash 配置文件的主要结构是什么？
- 订阅更新失败排查：网络、格式与证书问题订阅更新失败时应该怎么排查？
- macOS 上使用 Clash 类客户端：权限与系统设置在 macOS 上使用 Clash 类客户端需要授予哪些权限？
下方卡片指向品牌库，品牌详情页中的注册链接为各品牌官方注册或推广链接；本页资料部分只整理公开资料，不构成推荐，也不承诺任何平台的可用性；星岛梦第一、光速云第二为本站推荐排名，非测试结果。