Clash Verge 系统代理模式与 TUN 模式有什么区别？

路由层级差异：两种模式的本质定位

在 Clash Verge 中，系统代理模式与 TUN 模式最根本的区别体现在 OSI 模型的不同层级。系统代理（System Proxy）依赖操作系统暴露的网络代理接口，工作在应用层（第七层）：它向系统内应用发出通知，要求将 HTTP 流量发送到本地指定端口。这意味着，只有主动查询并遵循系统代理设置的应用才会被接管。与之相对，TUN 模式通过创建虚拟网卡（Virtual Network Interface）下沉到网络层（第三层），操作系统将默认路由指向这块网卡，从而截获几乎所有出站 IP 报文——无论应用程序本身是否支持代理。

这种层级差异直接决定了二者的能力边界。系统代理对应用有「协作性」要求：应用必须识读操作系统的代理配置；TUN 模式则更接近「强制性」网关，流量一旦被路由到虚拟网卡，便由 Clash Verge 的内核（Mihomo）按规则集重新封装和转发。对普通用户而言，最直观的感受莫过于：开启系统代理后浏览器即刻生效，但某些命令行工具或游戏客户端可能依旧走直连；而开启 TUN 后，整机流量几乎都被纳入代理范畴，包括互联网控制消息协议（ICMP）探测、用户数据报协议（UDP）游戏包，甚至后台更新组件。

系统代理模式：轻量且有限的应用层方案

工作机制与协议边界

系统代理的核心是修改操作系统的「互联网选项」或「网络偏好设置」。在 Windows 环境下，Clash Verge 通过系统接口将代理地址写入网络配置，通常指向本地回环地址的默认端口或用户自定义端口；在 macOS 中，则通过修改网络偏好设置里的「网页代理」与「安全网页代理」实现。主流浏览器、即时通讯软件以及大部分遵循系统网络栈的图形界面应用，会在启动或网络状态变化时读取这些配置，从而将流量导向 Clash Verge。

然而，这一机制存在三个明显的协议与场景盲区。首先，它通常只覆盖超文本传输协议（HTTP）与安全超文本传输协议（HTTPS）流量，对于原始传输控制协议（TCP）连接、UDP 数据包以及 ICMP 请求无能为力。其次，大量命令行工具——如 Git、curl、npm、Docker 守护进程——默认不读取系统代理，除非手动导出 http_proxy 与 https_proxy 环境变量。第三，部分软件出于自身网络策略，会忽略系统代理设置直接建立连接，造成「漏网」现象。因此，系统代理更适合以网页浏览、轻量办公为主的场景，而非需要彻底全局管控的环境。

值得注意的是，系统代理并不等同于全局代理。操作系统在实现该功能时，通常还会参考代理自动配置（PAC）脚本或绕过本地地址列表。Clash Verge 在开启系统代理时，一般会自动配置一个指向本地的 PAC 地址，使系统能够根据规则集的初步判断决定直连还是代理。这意味着，系统代理下的流量并非全部涌入 Clash Verge，部分明确为直连的域名在系统层面即被分流，从而减轻内核负担。但这也带来一个副作用：如果 PAC 脚本缓存陈旧或被浏览器插件覆盖，实际行为可能与 Clash Verge 的规则集不一致，出现预期外的路由结果。

各平台配置的最短路径与回退

在 Clash Verge 的图形界面中，启用系统代理通常只需在主面板或设置页找到「系统代理」开关。Windows 用户可通过系统托盘图标的右键菜单快速切换；macOS 用户除了在图形界面内操作外，还可在「系统设置 › 网络 › 代理」中观察到代理地址的写入与清空。Linux 用户因桌面环境多样——如 GNOME、KDE、i3wm 等——若发现图形界面开关未能生效，可检查系统环境变量或桌面环境的底层配置，必要时手动导出代理变量作为临时补偿。

回退方案同样简单：关闭开关后，Clash Verge 会清理已写入的系统代理配置，应用即刻恢复直连。经验性观察表明，某些企业安全软件或域策略会周期性重置系统代理，表现为「刚打开就被关闭」。若反复拉锯无效，建议转而使用 TUN 模式，或联系管理员确认是否有组策略限制了代理修改权限。另一个常见分支是，部分移动热点或公共 Wi-Fi 的认证门户（Captive Portal）在检测到系统代理后会拒绝放行，此时临时关闭系统代理完成认证，再重新开启即可恢复正常访问。

TUN 模式：网络层全域接管及其代价

虚拟网卡与路由表注入原理

TUN 模式的命名源自类 Unix 系统中的 TUN/TAP 虚拟网络设备驱动。Clash Verge 在启用该模式时，会向操作系统注册一块虚拟网卡（名称常见为 mihomo、utun 或 clash，视平台而定），并自动插入一条优先级较高的路由规则，将默认网关指向这块网卡。所有出站报文——无论是网际协议第四版还是第六版——在离开真实物理网卡前，先被内核路由子系统转发到虚拟网卡，由 Mihomo 内核进行协议解析、规则匹配，再根据配置决定直连、代理或丢弃。

由于接管发生在网络层，TUN 模式对应用完全透明。示例：在 Windows 命令提示符中执行 ping 命令测试公网地址，即使命令行本身没有任何代理概念，其 ICMP 报文仍会被 TUN 虚拟网卡捕获。对于游戏玩家而言，这解决了大量客户端不读取系统代理、却需要通过代理服务器转发 UDP 包以降低延迟或突破地域限制的问题。截至当前最新版本，客户端对 Apple Silicon、Windows on ARM64 以及较新 Linux 内核的 TUN 驱动进行了适配，降低了在异构架构下的部署门槛。

Fake-IP 是 TUN 模式下经常伴生的域名解析策略。当 TUN 虚拟网卡接管 DNS 查询时，内核不会立即向外网发起解析，而是先返回一个本地保留网段（如 198.18.x.x）的虚假地址。待应用真正向该虚假地址发起 TCP 或 UDP 连接时，内核再在后台并行向多个 DNS 服务器（如基于 HTTPS 的 DNS 或基于 QUIC 的 DNS）查询真实 IP。这种「连接驱动解析」机制能有效降低 DNS 泄漏风险，并减少首次解析的感知耗时。不过，这也解释了为何部分用户在开启 TUN 后发现某些网站首次打开稍慢、刷新后恢复正常——Fake-IP 的异步解析需要一次往返以建立映射缓存。

权限门槛与平台实现差异

TUN 模式的代价首先体现在权限上。创建虚拟网卡并修改系统路由表需要管理员或 root 级别权限。在 Windows 上，Clash Verge 首次启用 TUN 时会触发用户账户控制提权，并安装或更新一个轻量级网络驱动；在 macOS 上，系统会要求用户在「系统设置 › 隐私与安全性」中授权 Clash Verge 修改系统网络配置；在 Linux 上，除了以 root 启动外，更常见的做法是给二进制文件赋予 CAP_NET_ADMIN 能力位，以便在无 root 权限下创建 TUN 设备。

平台差异还体现在与既有网络栈的共存上。经验性观察显示，Windows 的某些更新版本与第三方 TUN 驱动存在兼容性摩擦，表现为系统不稳定或网络断流，社区通常建议保持驱动版本与客户端版本匹配。macOS 用户在开启 TUN 后，若同时使用公司提供的全局 privacy tool 客户端，可能出现路由表互抢现象，导致网络完全中断，此时需要手动调整接口跃点数或关闭其中一个隧道。Linux 用户则需关注网络管理器与系统解析服务对 DNS 的接管顺序，避免 TUN 模式的 Fake-IP 解析与公司内网域名服务产生冲突。

核心差异对照：从兼容性到性能表现

为了更直观地权衡，下表从多个维度对比两种模式。请注意，性能数据受本地硬件、节点质量与规则集规模影响较大，表内描述为经验性观察，具体请以实测为准。

对比维度	系统代理模式	TUN 模式
工作层级	应用层	网络层
协议覆盖	主要为 HTTP/HTTPS	TCP、UDP、ICMP 全域
应用感知	需应用主动跟随	对应用完全透明
权限要求	普通用户即可	管理员/Root/特定内核能力
性能开销	极低，无额外封装	中低，增加一次路由与解封装
典型冲突	企业安全软件重置代理	与其他 privacy tool 路由表互抢

从性能角度看，系统代理模式因为少了一层虚拟网卡的收发与 IP 报文重组，在纯 HTTP 下载或浏览器场景中通常表现出更低的处理器占用和略快的响应速度。TUN 模式虽然增加了内核态与用户态的数据拷贝，但在现代硬件上这一开销通常处于可接受范围；其真正需要权衡的是兼容性与稳定性——当用户需要同时运行公司 privacy tool、虚拟机网桥或网络安全软件时，TUN 模式引入的路由复杂度可能成为故障高发区。

场景化决策：何时启用哪一种模式

浏览器与即时通讯为主的日常办公

如果你的主要场景是浏览网页、收发邮件、使用协作软件，系统代理模式通常是首选。示例：一位日常需要访问代码托管平台与技术论坛的前端开发者，开启系统代理后，浏览器与代码编辑器的内置网络栈会自动跟随系统设置；版本控制工具若配置了代理环境变量同样可走代理，而系统后台的音乐软件、企业通讯工具等国内应用由于不强制走代理，依然保持直连，避免了不必要的绕路。这种「按需转发」的策略对延迟敏感且规则集简单的用户最为友好。

游戏加速与 UDP 流量

对于使用游戏主机或电脑端游戏平台的用户，TUN 模式往往是唯一可行的方案。多数游戏客户端使用 UDP 协议传输实时对战数据，且不提供代理配置入口。在 Clash Verge 中开启 TUN 后，配合支持 UDP 转发的节点，可以将游戏报文完整封装并通过代理服务器中转，从而降低跨国线路的丢包率。经验性观察显示，在晚间网络高峰时段，通过 TUN 模式配合新型传输协议节点，部分地区的 UDP 丢包情况可见改善。但需注意，若规则集中未将游戏服务器地址或进程名加入直连白名单，全部流量走代理反而可能增加路由跳数，导致延迟上升。

命令行开发、容器与系统更新

云原生开发者常面临容器镜像拉取、包管理器安装等命令行操作。容器引擎在 Windows 与 macOS 上可配置 HTTP 代理，但 Linux 下的守护进程与系统服务默认不读取用户环境变量，容易造成拉取超时。此时启用 TUN 模式可实现无感知全局转发，无需逐个配置工具链的代理环境变量。同理，部分操作系统的应用商店或系统更新组件在某些网络环境下也会绕过系统代理，TUN 模式能确保这些系统级流量按规则集分流。不过，这种全域接管也意味着一旦规则集编写不当，国内内容分发网络流量可能被误送出国再绕回，出现「负优化」。建议在初期通过连接面板密切观察镜像站与更新服务器的命中规则，及时调整分流策略。

共存与切换：双栈启用的实践路径

Clash Verge 允许系统代理与 TUN 模式同时启用，这种双栈共存策略在混合办公场景中颇为实用。示例：高校科研人员白天使用浏览器查资料时，系统代理已足够应对学术数据库的访问；晚间需要下载大体积数据集或运行依赖 UDP 的仿真软件时，再叠加 TUN 模式即可补全命令行与系统组件的流量盲区。在图形界面中，用户通常可在设置页分别开启两个独立开关，二者互不排斥。

然而，共存也带来了规则优先级与域名解析的复杂度。当 TUN 开启时，所有 DNS 请求可能被内核的 Fake-IP 模块拦截；而系统代理模式下，浏览器可能仍然使用自己的加密 DNS 通道。经验性观察发现，部分用户在双栈开启后遇到「国内网站解析慢」的问题，原因往往是 DNS 解析路径发生了双重劫持。一个可复现的验证方法是：在仅开启系统代理时访问国内测速站记录解析时间，随后开启 TUN 并观察解析耗时变化。若明显变长，可在 Clash Verge 的 DNS 设置中显式指定国内 DNS 服务器并开启「解析国内域名时直连」的选项，以消除不必要的远程查询。

回退方案应当始终保持在手边。建议将「关闭 TUN」与「关闭系统代理」的入口熟记于心。若 TUN 导致全网中断，而图形界面又因权限问题无法响应，Windows 用户可打开网络连接界面直接禁用名为 mihomo 的虚拟网卡；macOS 用户可在系统网络设置中移除对应的虚拟接口；Linux 用户则可执行网络接口关闭命令（具体接口名视实际而定）以快速恢复网络。这些物理层面的回退手段能在客户端卡死时挽救连接。

验证方法：如何确认流量实际走向

配置完成后，验证流量是否按预期进入代理通道是必不可少的一步。Clash Verge 内置的「连接」面板是最直接的观测窗口。开启系统代理但不开启 TUN 时，你应该看到大量目标端口为常规网页端口的连接，且进程名主要是浏览器、通讯软件等图形界面应用。如果在仅开启系统代理的情况下执行 ping 命令，却在连接面板中看不到 ICMP 记录，这说明系统代理确实不接管网络层报文，符合预期。

验证 TUN 模式是否生效的方式略有不同。开启 TUN 后，首先观察系统网络接口列表，确认出现了一块新的虚拟网卡。随后，在命令行中执行路由追踪命令，第一跳应当指向虚拟网卡侧的本地地址（如 198.18.0.1 或 172.19.0.1，视 Fake-IP 网段配置而定），而非你的物理网关。对于进程级验证，可在连接面板中查看进程名字段：一个原本不跟随系统代理的终端应用，在 TUN 开启后应当显示其进程名与目标地址，这证明网络层拦截已生效。

若你怀疑存在 DNS 泄漏，可在 TUN 模式下访问公开的 DNS 泄漏检测网站，观察返回的 DNS 服务器是否为你配置的远程 DNS。若显示本地运营商 DNS，则说明 TUN 未能完全劫持 DNS 报文，可能需要检查防火墙是否放行虚拟网卡，或操作系统是否存在其他 DNS 客户端服务在争抢解析权。对于系统代理模式，验证 DNS 泄漏时还应检查浏览器是否启用了独立的安全 DNS 功能，因为这会绕过系统代理的解析路径。

常见冲突、限制与回退策略

系统代理被重置与部分应用脱管

系统代理最常见的故障是企业环境或安全软件导致的配置回写。某些终端管理软件会每隔数分钟扫描网络配置，一旦检测到非授权代理地址便自动清空。经验性观察表明，在加入域的 Windows 设备上，这一现象尤为突出。若你的 Clash Verge 系统代理开关反复跳回关闭状态，可尝试在设置中寻找「守护系统代理」类选项（若客户端提供），或改用 TUN 模式彻底绕过应用层代理依赖。另一个典型问题是现代应用平台应用（如官方应用商店）在 Windows 上默认不走系统代理，这是系统网络隔离机制所致，TUN 模式或配置本地回环豁免可作为变通方案。

TUN 驱动冲突与网络层异常

TUN 模式的高权限特性使其更容易与底层驱动产生摩擦。在 Windows 上，虚拟化平台网卡、其他 privacy tool 客户端都可能与 Clash Verge 的 TUN 驱动竞争路由表或适配器绑定顺序。若遇到开启 TUN 后立即出现系统不稳定或网络适配器显示异常状态，建议先卸载或暂停其他虚拟网卡，再逐个排查。近期社区讨论中，有用户反馈 Windows 的特定更新与 TUN 驱动存在兼容性警示，临时缓解办法包括使用社区维护的更新版驱动或回退到稳定内核版本。

macOS 用户则需关注系统完整性保护与网络扩展的授权状态。虽然 Clash Verge 在 macOS 上通常以用户态网络扩展实现 TUN，无需关闭系统完整性保护，但若你此前为了其他需求调整了保护状态，经验性观察显示某些网络栈行为可能出现细微差异。不过，这一差异对普通用户的感知度较低，通常无需因此改动系统安全设置。

规则集失效与流量误杀

无论采用哪种代理模式，规则集都是决定流量去向的大脑。在 TUN 模式下，由于流量全量经过内核，规则集规模过大或地理位置 IP 数据库老旧可能导致处理器占用升高或国内站点误判。一个可复现的排查步骤是：在连接面板中筛选出直连或拒绝记录，若发现本应直连的国内视频加速节点走了代理，或反之，应首先更新地理位置 IP 与域名分类规则集。Clash Verge 近期引入的规则集市场允许一键订阅维护度较高的分流规则，对于不想手动维护大量域名规则的用户，这是一个可见降低维护成本的选择。

不适用场景与合规边界

系统代理与 TUN 模式并非万能，存在明确的准入禁区。首先，在已部署零信任架构或强制全局 privacy tool 的企业内网中，叠加 TUN 模式会导致双重封装、路由环路，甚至触发安全审计告警。此时应优先使用企业提供的网络通道，或在获得网络管理员明确许可后再做测试。其次，部分高校与公共机构的网络准入系统在检测到虚拟网卡或路由表异常时可能直接踢下线，TUN 模式在此类环境中风险较高。

第三，从合规与隐私角度，TUN 模式的全域拦截能力意味着所有流量——包括银行客户端、医疗系统或政府内网——都可能被代理服务器可见。虽然 Clash Verge 的规则集可以精细排除这些域名，但配置失误的代价远大于系统代理模式下的漏网。因此，处理敏感数据的设备上，如果仅需要访问特定外部资源，系统代理配合浏览器扩展或代理自动配置脚本往往是更保守、更可控的方案。

最佳实践检查表

在结束技术细节之前，以下检查表可帮助你快速落地决策：

• 轻量浏览场景：仅开启系统代理，关闭 TUN，保持最低系统侵入性。
• 游戏/UDP/主机加速：开启 TUN，确保节点支持 UDP 转发，并在规则集中将游戏平台进程名或地址段设为代理。
• 命令行与容器开发：若不想逐个配置环境变量，开启 TUN；同时检查容器网络模式是否与 TUN 网段冲突。
• 企业环境：先确认公司是否允许虚拟网卡与路由表修改；若不允许，仅使用系统代理并配合浏览器代理扩展。
• 双栈共存验证：开启后访问一个国内测速站与一个海外站点，观察连接面板中的进程名、规则命中与延迟差异，确认分流逻辑正确。
• 紧急回退：将「禁用 TUN」的快捷键或托盘入口熟记于心，遇到全网中断时能在数十秒内恢复。

这份检查表的核心逻辑是「先轻量后全域，先验证后依赖」。建议在新设备或新网络环境中，从系统代理起步完成基础连通性测试，确认规则集运行正常后，再根据实际需求决定是否叠加 TUN。如此一来，即便遇到冲突，也能通过分层回退迅速定位问题根因，避免同时调整多个变量导致排查困难。

常见问题（FAQ）

结语

Clash Verge 的系统代理模式与 TUN 模式并非互斥的替代关系，而是针对不同网络层级、不同应用生态的互补工具。系统代理以低侵入、低开销见长，适合浏览办公与轻量开发；TUN 模式以全域透明、协议无差别拦截为优势，服务于游戏加速、命令行容器以及任何需要强制全局分流的场景。真正的高效使用，取决于你对当前设备权限环境、网络栈冲突风险以及规则集维护成本的综合评估。

对于刚接触 Clash Verge 的用户，建议从系统代理起步，先熟悉规则分流与节点切换逻辑；当发现特定应用漏网、UDP 流量无法转发或需要主机级全局代理时，再逐步启用 TUN 模式，并通过连接面板与路由追踪等工具验证效果。保持「最小够用」原则，在满足需求的同时降低系统复杂度和潜在故障面，是长期稳定使用代理工具的最佳策略。随着 Mihomo 内核在跨平台网络扩展与 eBPF 方向上的持续迭代，未来两种模式的边界可能会进一步模糊，但现阶段理解它们的底层差异，仍然是构建可靠代理工作流的基础。