Clash Verge 如何配置系统代理模式与 TUN 模式？

功能定位：系统代理与 TUN 模式的本质差异

Clash Verge 的系统代理模式与 TUN 模式代表了两种截然不同的流量接管层级。前者依托操作系统暴露的 HTTP/HTTPS/SOCKS 代理接口，仅对主动适配该契约的应用生效；后者则通过创建虚拟网卡（如 utun、Meta 等接口）在网络层拦截 IP 报文，实现无需应用配合的全局牵引。系统代理工作在应用层，TUN 模式工作在网络层，这一根本分野决定了二者的权限模型、性能特征与适用边界。厘清这层差异，是避免「明明已开启代理，部分应用却依旧走直连」困惑的前提。

系统代理的最大优势在于开销极低、配置即时生效，且不会触碰系统网络栈的深层权限。绝大多数浏览器与终端工具都能识别系统代理变量，开箱即用。然而，其边界也同样清晰：基于 UDP 的游戏流量、不遵循系统代理变量的后台进程，以及采用私有网络协议的应用，往往会绕过这层代理直接外发。更隐蔽的风险在于，若操作系统未将代理设置同步给特定系统服务（如 macOS 的某些守护进程），用户会在「全局代理」的表象下遭遇局部泄漏。

TUN 模式恰好填补了上述盲区。它模拟了一张真实的网卡，操作系统将几乎所有 IP 流量路由至此，再由 mihomo（即 Clash.Meta）内核依据规则分流，决定是否转发给代理节点。代价是需要更高权限、可能引入额外的 CPU 开销（尤其在 gVisor 用户空间协议栈下），并且与部分企业级终端安全软件存在兼容性摩擦。因此，二者的选择并非简单的「哪个更好」，而是「当前场景需要干预到哪一层」。日常办公仅需浏览器与开发工具走代理时，系统代理已足够；若必须接管 UDP 或实现全局加密，TUN 模式才是必要选项。理解这种分层差异后，下一步便是确认你的操作系统是否允许 Clash Verge 触及所需的网络权限。

前置条件：不同平台的权限模型与准备事项

在动手配置之前，必须先厘清各操作系统对网络干预的权限边界。Clash Verge 基于 Tauri 框架构建，虽然主程序本身可在用户态运行，但无论是修改系统代理注册表还是创建虚拟网卡，都必然触及系统级权限。忽略这一点，往往会导致「开关点了没反应」「反复提示安装驱动」等看似诡异的现象。

Windows 平台的权限模型相对直观：开启系统代理通常只需普通用户权限即可写入当前用户的 IE/Edge 代理设置；但 TUN 模式往往需要管理员权限以安装或更新 WFP（Windows Filtering Platform）驱动。若你使用了 CrowdStrike、360 企业安全等 EDR 产品，可能会观察到驱动加载被拦截的情况，此时需要先在安全软件中将 Clash Verge 加入白名单，或改用系统代理模式作为过渡。经验性观察显示，部分企业环境对 WFP 过滤驱动的签名校验极为严格，即便是合法驱动也可能触发告警，这种情况下强行使用 TUN 模式可能导致网络被准入系统切断。

macOS 的权限模型在较新版本（经验性观察涉及 Sequoia 及之后版本）中进一步收紧。除了首次开启 TUN 时需要输入管理员密码安装网络扩展，还必须在「系统设置 → 隐私与安全性 → 本地网络」中手动授予 Clash Verge 访问权限，否则会出现「系统代理开关已打开，但 Safari 或部分系统服务仍走直连」的现象。这并非 Clash Verge 自身缺陷，而是 Apple 变更了网络扩展 API 的权限模型所致。若你仅开启 TUN 而未授予本地网络权限，甚至可能出现虚拟网卡已创建、但本机回环通信被阻断的悖论状态。

Linux 发行版的差异最大。以采用 systemd 的桌面发行版为例，系统代理通常可通过 gsettings 修改 GNOME/KDE 的代理配置；TUN 模式则要求进程具备 CAP_NET_ADMIN 能力，或每次通过 pkexec 提权启动。若你以普通用户身份直接开启 TUN，很可能观察到虚拟网卡创建失败且无明确错误弹窗，此时查看日志中「Operation not permitted」字样即可定位根因。对于长期运行需求，建议为 Clash Verge 二进制文件配置 capabilities，而非全程使用 root 账户启动，以遵循权限最小化原则。权限模型梳理清楚后，我们就可以按平台执行具体配置。

配置系统代理模式的分平台最短路径

系统代理是大多数用户最先接触的代理方式，其配置路径在 Clash Verge 中高度统一。打开主界面后，在左侧或顶部导航栏（视界面布局而定）找到「系统代理」（System Proxy）开关，点击启用即可。此时 Clash Verge 会尝试将操作系统级代理指向本地的 mixed-port（通常为 7890 或 7897，具体以你的配置为准）。这一步的本质，是软件在后台调用各平台 API 写入系统代理变量，无需用户手动翻找系统设置。

在 Windows 上，你可以通过「设置 → 网络和 Internet → 代理」看到「使用代理服务器」已被自动勾选，地址指向 127.0.0.1。需要注意的是，Windows UWP 应用（如 Microsoft Store、Xbox）由于沙盒限制，默认无法访问本地回环地址（127.0.0.1），因此即使系统代理已开启，这类应用仍可能无法联网。解决方法是使用 Windows 自带的 CheckNetIsolation 工具将应用添加到环回豁免列表，或寻找社区提供的辅助脚本。浏览器方面，Chrome 和 Edge 默认遵循系统代理，无需额外操作；而 Firefox 由于其不继承系统代理，需要进入浏览器网络设置中手动指定 SOCKS5/HTTP 代理为 127.0.0.1 对应端口。示例：在终端执行 curl -I https://github.com 前，若未导出 http_proxy 变量，curl 将直接走物理网卡，此时即便浏览器能正常访问，命令行工具仍可能超时。

macOS 用户启用开关后，建议立即打开「系统设置 → 网络 → 详细信息 → 代理」进行交叉验证。若此处未出现勾选，说明 Clash Verge 未能成功写入系统代理，常见原因是本地网络权限未授予。一个可复现的验证方法是：在终端执行 networksetup -listallnetworkservices 查看当前服务名，再执行 networksetup -getwebproxy "Wi-Fi"（将 Wi-Fi 替换为你的服务名），观察是否返回 Enabled: Yes 及 Server: 127.0.0.1。若返回 Disabled，则系统代理实际上未生效，浏览器看似能跨境网络访问可能是因为你之前设置过其他代理插件，造成了误判。

Linux 桌面环境（如 GNOME）用户，开启开关后可通过 gsettings get org.gnome.system.proxy mode 验证，预期返回 'manual'。若返回 'none'，则可能是 Clash Verge 未能通过 dbus 与系统设置通信，此时可尝试手动指定环境变量 http_proxy 与 all_proxy 作为临时替代。对于使用 Wayland 的较新发行版，部分桌面环境不再暴露统一的代理设置接口，系统代理的覆盖率可能低于 X11 环境，这是选择 TUN 模式的一个重要诱因。系统代理配置无误后，若你仍需接管 UDP 或全局 IP 流量，便需要深入 TUN 模式的协议栈取舍。

TUN 模式的核心配置与协议栈取舍

TUN 模式的配置重心不在「开关」本身，而在于虚拟网卡如何与操作系统协议栈协同。在 Clash Verge 主界面中找到「TUN 模式」开关，首次开启时系统会弹出授权对话框（Windows 为 UAC，macOS 为管理员密码），确认后即可创建名为 meta 或 clash 的虚拟网卡。若此处反复弹窗或报错，说明前置的权限或驱动条件未满足，应回到上一章节排查，而非反复点击开关。

进入「设置」或「TUN 设置」面板（不同版本入口可能标记为「系统设置」或「内核设置」），你会看到协议栈（Stack）选项，通常提供 System、gVisor 与 Mixed 三种模式。System 协议栈直接调用操作系统底层网络接口，转发效率最高、延迟最低，适合追求性能的游戏或实时音视频场景；但其兼容性相对脆弱，在部分 Windows 版本或企业安全策略下可能出现驱动加载失败。gVisor 运行在用户空间，不依赖内核驱动，兼容性最强，能绕过大多数 EDR 拦截，代价是 CPU 占用在高吞吐下会有可见提升（经验性观察在千兆流量下差距可被感知）。Mixed 模式则由内核自动在 System 不可用时 fallback 到 gVisor，是稳妥的默认选择。示例：若你在 Windows 企业版中遭遇 CrowdStrike 对 WFP 驱动的拦截，将 Stack 切换为 gVisor 通常能绕过内核驱动限制，代价是牺牲部分转发效率（经验性观察，具体因硬件与流量模型而异）。

MTU（最大传输单元）设置同样值得关注。以太网标准 MTU 为 1500 字节，但代理协议（如 VMess、VLESS）的加密头部会占用额外空间。在 TUN 模式下，如果原始数据包已经是 1500 字节，封装后可能超过物理网卡 MTU，导致 IP 层分片或丢包。将 TUN MTU 设为 9000（Jumbo Frame）仅在底层物理网卡支持时才有意义，否则应保守设置为 1420 至 1500 之间。严格路由（Strict Route）选项建议保持开启，它能防止流量通过物理网卡泄漏，但若你同时运行了其他 privacy tool 软件（如公司提供的 WireGuard），则可能出现路由表冲突，此时应关闭严格路由并手动调整接口跃点数（Metric），避免两条默认路由相互覆盖。协议栈与网卡参数只解决了「能不能通」的问题，而流量真正走向何方，还取决于 DNS 与路由表的协同策略。

DNS 与路由表：TUN 模式看不见的底层逻辑

许多用户将 TUN 模式简单理解为「全局 privacy tool」，却忽略了它本质上是通过修改 DNS 解析行为与系统路由表来实现流量牵引的。在 Clash Verge 的 TUN 配置中，DNS 模式通常涉及 fake-ip 与 redir-host 两种机制，选错机制往往是「能上 QQ 但打不开网页」或「国内网站变慢」的根源。

fake-ip 是较新版本的默认方案。其工作原理是：当系统内任何应用发起 DNS 查询时，mihomo 内核不会立即向外网 DNS 服务器转发，而是返回一个预设的虚拟 IP 段（如 198.18.0.0/15）。应用拿到这个 fake-ip 后尝试建立 TCP/UDP 连接，流量自然被引导至 TUN 虚拟网卡；内核在收到该连接请求后，再根据规则决定访问哪个真实目标，并由远端代理节点或本地直连完成最终解析。这种机制的优点是 DNS 查询零泄漏、连接建立速度快；缺点是部分依赖真实 IP 进行 P2P 握手或局域网发现的应用（如某些下载工具、局域网游戏）可能出现异常。示例：qBittorrent 在开启 fake-ip 后可能出现 DHT 节点无法连通的情况，因为 DHT 握手依赖于真实的公网 IP 交换，而 198.18.x.x 的虚拟地址无法被外部节点路由。如果你发现某款应用在开启 TUN 后无法连接，但在系统代理下正常，fake-ip 的虚拟化极有可能是罪魁祸首。

redir-host 则是更传统的方案：DNS 查询依然由内核代理解析，但返回的是真实 IP 地址。这保证了应用层拿到的 IP 是准确的，代价是每一次连接前都需要一次额外的 DNS 往返，且若配置不当，DNS 请求本身可能先于 TCP 流量被错误地路由。对于普通用户，fake-ip 的综合体验更优；只有当你明确观察到某款应用因 IP 虚拟化而断连时，才需要在配置文件中切回 redir-host。

路由表层面，开启 TUN 后，mihomo 会注入一条高优先级的默认路由指向虚拟网卡，同时通过接口跃点数（Metric）确保物理网卡不被首选。你可以在 Windows 的 route print 或 macOS/Linux 的 netstat -rn 中观察到这些变化。若你同时运行了其他 privacy tool 客户端，多条默认路由的 metric 竞争将导致不可预测的网络行为——例如公司 privacy tool 的虚拟网卡与 Clash 的 TUN 网卡同时声称自己拥有 0.0.0.0/0 路由，操作系统会按 metric 选择其一，另一方的流量将被静默丢弃。这也是 TUN 模式与企业 privacy tool 难以共存的技术根源，遇到此类场景，回退到系统代理是唯一稳妥的解法。理解了底层逻辑，再来看双模式并存时的冲突与规避，就能避免大量似是而非的网络异常。

双模式并存时的优先级与冲突规避

许多进阶用户会尝试同时开启系统代理与 TUN 模式，以期「双重保险」。这种做法在特定场景下合理，但若不厘清优先级，极易引发流量回环或 DNS 解析异常。在 mihomo 内核的逻辑中，TUN 接管的是网络层流量，而系统代理作用在应用层；当某款应用（如 Chrome）既遵循系统代理、又产生被 TUN 截获的 IP 包时，内核必须能够识别并避免重复转发。

一个具体的例子是 Steam 客户端在双模式下的行为：Steam 的下载进程（steam.exe）既会读取 Windows 系统代理设置，也会发起普通的 TCP 连接被 TUN 截获。如果内核规则将 Steam 下载标记为 DIRECT，理论上应直连；但如果系统代理变量导致 Steam 先尝试通过 127.0.0.1:7890 连接，而 TUN 又将该连接再次拦截，就可能出现「本应由 DIRECT 规则处理的流量，却在连接面板上显示为多次跳转」。虽然现代 mihomo 内核已有防回环机制，但这种双重干预增加了排查复杂度。工作假设：若你同时开启双模式，并在浏览器访问 ip.sb 等检测站点时，发现 Clash Verge 连接面板中出现大量指向 127.0.0.1 的循环连接，或 CPU 占用异常飙升，则表明发生了回环。

此时的缓解方案是：在 TUN 配置中排除 Clash Verge 自身的 mixed-port 与 redir-port，或在「直连域名/进程」规则中加入 clash-verge、clash.meta 等进程名，确保代理软件自身的控制流量不被二次拦截。更务实的做法是二选一。对于以浏览器、终端、IDE 为主的办公场景，系统代理已足够，无需承受 TUN 的权限与兼容性开销；对于游戏、海外流媒体盒子、或是不支持代理配置的智能硬件模拟器，TUN 才是必要选项。若你的场景确实混合了这两类需求，可以日常仅开启系统代理，在启动游戏前临时打开 TUN，并通过界面快捷键快速切换，而非长期双开。若你已经在实践中遭遇了具体故障，以下分平台排查手册提供了可直接落地的诊断路径。

分平台故障排查：现象、根因与处置

macOS 开启系统代理后部分应用仍直连

现象：Clash Verge 面板显示系统代理已启用，但 Safari、邮件或 App Store 无法访问目标站点，连接面板中无相关日志。根因排查：较新 macOS 版本收紧了本地网络权限，Clash Verge 未被授予「本地网络」访问权，导致其无法在本机回环地址上为系统服务提供代理。验证步骤：进入「系统设置 → 隐私与安全性 → 本地网络」，确认 Clash Verge 已列入并开启；若列表中无此应用，可尝试重装或手动添加。若权限正确仍无效，可作为临时替代，在终端执行 sudo networksetup -setwebproxy 'Wi-Fi' 127.0.0.1 7890（将 Wi-Fi 替换为实际服务名，端口号以你的配置为准），观察 Safari 是否恢复。

TUN 模式反复提示驱动安装或无法创建虚拟网卡

现象：开启 TUN 后弹窗要求「安装驱动」且循环出现，或日志中报「create tun: error」。根因：Windows 平台可能是 WFP 驱动未成功注册，或被杀毒软件拦截；macOS 则可能是网络扩展未正确授权；Linux 通常是权限不足。验证方法：Windows 下以管理员身份重新启动 Clash Verge，并在事件查看器中筛选「Application」日志寻找 WFP 相关错误码；Linux 下执行 ip link 查看是否存在 utun 或 meta 接口。处置建议：Windows 可尝试在安装目录下查找服务安装脚本手动执行（具体文件名因版本而异，请以实际文件为准）；Linux 建议使用 pkexec 启动，或为用户配置 CAP_NET_ADMIN 能力。

开启 TUN 后出现 DNS 泄漏或国内网站访问变慢

现象：访问国内视频网站（如哔哩哔哩、腾讯视频）缓冲变慢，或 dnsleaktest.com 显示运营商 DNS。根因：TUN 模式默认会劫持所有 DNS 查询到 Clash 内核，若你的规则集中缺少「GEOIP,CN 直连」或匹配顺序不当，国内域名也会被发往代理节点解析；另一种可能是系统原始 DNS 与 TUN 的 fake-ip 冲突。验证步骤：在 Clash Verge 的「连接」面板中，按规则筛选，观察国内域名的最终策略是否为 DIRECT；在终端执行 nslookup baidu.com，查看返回 IP 是否为 fake-ip 段（如 198.18.x.x）。处置：检查配置文件中的规则顺序，确保「DOMAIN-SUFFIX,cn DIRECT」或「GEOIP,CN,no-resolve DIRECT」位于代理规则之前；同时确认 TUN 设置中启用了「自动路由」与「自动设置 DNS」。

TUN 模式 CPU 占用异常高

现象：开启 TUN 后，Clash Verge 进程 CPU 占用持续处于高位。根因：若你选择了 gVisor 协议栈并处于高吞吐场景（如 BT 下载、4K 流媒体），用户空间网络栈的数据拷贝与协议解析会带来显著开销；另一种可能是日志级别设为 debug，大量写入拖慢性能。验证方法：在「设置」中将日志级别切换为 info 或 warning，观察 CPU 是否回落；再将协议栈切换为 System，对比占用差异。处置：日常使用中保持 System 或 Mixed，仅在驱动被拦截时临时使用 gVisor。若你使用的是 Apple Silicon 设备，经验性观察显示较新版本对原生架构的优化可降低 TUN 的 CPU 占用，因此保持软件更新也是缓解手段之一。排障完成后，必须通过系统化的验证手段确认修复效果，而非仅凭主观感受。

验证与观测：确认流量确实被正确接管

配置完成后，必须通过可复现的手段验证，而非仅凭「能打开网页」的主观感受。以下三层验证方法建议组合使用，以建立对网络路径的完整认知。

第一层：接口层验证。在终端执行 ip addr（Linux）、ifconfig（macOS）或 ipconfig /all（Windows），查找是否存在由 Clash 创建的虚拟网卡（名称通常包含 meta、utun 或 clash）。若不存在，说明 TUN 未能成功初始化。同时观察默认路由表：执行 route print（Windows）或 netstat -rn（Unix-like），应看到 0.0.0.0/0 或 ::/0 被指向该虚拟网卡接口。若默认路由仍指向物理网卡，说明自动路由注入失败，TUN 实际上处于空转状态。

第二层：应用层验证。使用 curl 命令行工具进行精确测试。执行 curl -v http://ip.sb，观察返回的 IP 地址是否为代理节点出口 IP；再执行 curl -v --resolve ip.sb:80:127.0.0.1 http://ip.sb（绕过 DNS），确认连接面板上出现对应日志。若你仅开启了系统代理而未开启 TUN，应在终端先 export http_proxy=http://127.0.0.1:7890，否则 curl 默认不走代理。对于 UDP 流量的验证，可使用 dig 或游戏内延迟测试，观察 TUN 是否成功截获 UDP 报文。

第三层：可视化验证。Clash Verge 主界面通常提供「连接」或「日志」面板。在「连接」面板中，可按进程名、目标域名、规则类型进行筛选。例如，启动微信或某款游戏，观察其进程名是否出现在连接列表中，且命中规则为「DIRECT」或「REJECT」而非预期代理。若未出现，说明该应用流量未被接管——在系统代理模式下这属于正常现象，但在 TUN 模式下则需排查路由表或虚拟网卡状态。通过接口、应用、可视化这三板斧，你可以排除「假代理」状态，确保每一类流量都走在预期的路径上。验证手段建立后，最终仍需回到场景本身，判断当前模式是否选对了战场。

适用场景与不适用场景的决策清单

并非所有用户都需要同时掌握两种模式。以下基于典型使用场景的准入条件与边界说明，可帮助你快速决策，避免为不需要的功能付出兼容性代价。

应优先选择系统代理的场景：日常办公以浏览器、VS Code、终端为主；设备为公司配发且 EDR 策略严格限制虚拟网卡；仅需代理 HTTP/HTTPS 流量，无需处理 UDP 游戏或 P2P 流量；对系统资源占用极度敏感（如老旧笔记本）。在这些场景下，系统代理的即时开关、低权限要求与零驱动依赖，使其成为最稳妥的起点。特别是当你只是临时查阅技术文档或访问 GitHub 时，开启系统代理数十分钟后关闭，几乎不会对系统产生任何副作用。

应优先选择 TUN 模式的场景：需要代理 Steam、Epic 等游戏的 UDP 流量；使用 Apple TV、Android 模拟器等无法设置系统代理的终端；在公共 Wi-Fi 下需要强制全局加密以防止 DNS 劫持；配合 Netflix、Disney+ 等流媒体进行跨区域解锁时，需要确保 DNS 与 IP 流量完全一致性。此时 TUN 的系统级接管是唯一可靠的解法。以流媒体为例，若仅使用系统代理，电视端的 Netflix 应用可能因不识别系统代理而直接解析到本地 CDN，导致无法解锁目标区域内容；TUN 模式则从根本上消除了这种泄漏可能。

不建议使用 TUN 模式的场景：设备处于高度合规的企业内网，且运行了强制路由检测的准入系统（如深信服、奇安信等），虚拟网卡可能触发断网或告警；同时运行了公司提供的 WireGuard/Openprivacy tool，双网卡路由表极易冲突；对网络延迟极度敏感的竞技游戏（如 CS2、Valorant），TUN 的额外处理跳数可能带来可感知的延迟波动（经验性观察，具体因设备性能与协议栈选择而异）。在这些边界条件下，强行使用 TUN 不仅无法提升体验，反而会导致网络可用性下降。场景边界清晰之后，日常使用中的一些高频疑问便可迎刃而解。

常见问题（FAQ）

最佳实践与下一步行动建议

经过上述配置与排查，你应该已经能够让 Clash Verge 在系统代理与 TUN 模式之间稳定切换。为了避免重复踩坑，建议将以下检查表固化为个人工作流：

1. 每次更新 Clash Verge 后，首次开启 TUN 前备份现有配置，防止新 schema 导致规则语法不兼容。备份通常只需复制配置目录下的 YAML 文件即可（具体路径因版本和安装方式而异，请以实际为准）。
2. 在 macOS 上，将「本地网络」权限检查作为系统代理失效时的第一排查点，而非盲目重装应用。
3. Windows 用户若处于企业环境，优先在沙盒或备用机上测试 TUN 的 WFP 驱动兼容性，确认无 EDR 拦截后再部署到主力工作机。
4. 使用「连接」面板建立对流量路径的直觉：定期观察哪些进程走了代理、哪些走了直连，据此微调规则，而不是依赖「全局」或「GFWList」等粗放策略。
5. 当不需要全局代理时，养成关闭 TUN 的习惯，减少虚拟网卡对系统网络的潜在干扰。系统代理则可在下班后随手关闭，避免影响次日开机时的网络自检。

如果你当前仍处于「无法确定该用哪种模式」的阶段，最稳妥的下一步是：先仅开启系统代理，用浏览器和终端完成日常工作的绝大部分需求；当遇到游戏 UDP 流量或某款应用无法被代理时，再启用 TUN 模式作为针对性补充。Clash Verge 的设计哲学正是提供分层工具，而非强制用户接受全盘接管。理解每一层的能力边界，远比记住几个开关位置更有长期价值。当你能根据具体应用的行为，迅速判断其流量应当走系统代理还是虚拟网卡时，你便真正掌握了这套工具的核心用法。

展望未来，随着 mihomo 内核对 eBPF 与 WireGuard 集成的持续探索，以及各大桌面操作系统对网络扩展 API 的迭代演进，TUN 模式的性能开销与兼容性摩擦有望进一步降低。经验性观察表明，社区对 System 协议栈在 Apple Silicon 上的调度优化已使部分高吞吐场景的 CPU 占用显著下降。对于普通用户而言，保持 Clash Verge 与内核版本处于较新稳定版，通常意味着更少的驱动冲突与更优的分流性能。无论技术栈如何演进，分层代理的思想——在应用层与网络层之间按需选择最小干预手段——仍将是长期适用的核心策略。