Clash Verge 如何启用 TUN 模式实现全局代理？

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

在 Clash Verge 中，TUN 模式之所以能实现真正的全局代理，关键在于它将流量转发从「应用层」下沉到了「网络层」。传统系统代理依赖操作系统暴露的 HTTP 或 SOCKS 接口，仅当应用程序主动读取系统代理变量时，流量才会进入代理链路；而 TUN 模式则通过在系统内核中创建一块虚拟网卡，将所有 IP 数据包截获后注入 Clash 内核。无论目标程序是遵循代理规范的浏览器，还是不读取系统代理的独立游戏客户端、命令行工具或后台服务，其出站流量都会被无差别接管，整个过程对应用完全透明。

示例：某用户需要加速 Steam 平台下载与外服联机。Steam 客户端对系统代理的适配并不完整，部分下载节点与游戏服务器连接不会自动走 HTTP 代理，导致开启系统代理后仍出现「商店能打开但下载慢」或「联机匹配失败」的情况。此时启用 TUN 模式，流量在虚拟网卡层即被统一拦截，既无需修改 Steam 启动参数，也省去了为每个不兼容程序单独配置代理规则的繁琐。不过，这种全局能力并非零成本——TUN 模式需要在用户态与内核态之间做一次额外的数据包拷贝和协议栈处理，同时对 DNS 解析、路由表乃至防火墙规则都有侵入性修改。在点击开启之前，先厘清它的能力边界与潜在代价，能帮你避开后续大量的排障时间。

版本差异与前置条件

Clash Verge 基于 mihomo（原 Clash.Meta）内核构建，TUN 功能完全由该内核提供。如果你当前加载的是早期导入的原版 Clash 内核（Dreamacro/clash），TUN 相关选项将无法启用，甚至可能直接触发配置报错。因此，在开启之前务必确认当前使用的内核类型。目前主流发行版已默认捆绑 mihomo，但从旧版迁移而来的配置文件中，仍可能残留指向 legacy 内核的路径。建议在「设置」中检查内核信息，必要时重新下载二进制文件，确保 TUN 能力处于可用状态。

权限是另一道前置门槛。Windows 平台通常需要管理员身份或安装系统服务，才能创建名为 Meta 的虚拟网卡并修改系统路由表；macOS 受系统完整性保护（SIP）机制约束，首次启用 TUN 时几乎必然弹出管理员密码授权框，用于注册 utun 虚拟接口；Linux 的情况则更为复杂，除了需要访问 /dev/net/tun 设备节点，部分采用 NetworkManager 管理网络的发行版还可能与 Clash 创建的路由产生优先级竞争。若你使用的是 immutable 发行版（如 Fedora Silverblue），还需额外确认应用沙盒对网络设备的访问权限是否已正确映射。明确这些平台差异后，接下来就可以按最短路径完成配置了。

操作路径：分平台最短入口

以下路径基于 Clash Verge 的通用界面逻辑整理。由于社区版本迭代较快，菜单命名可能存在细微差异，请以实际安装的界面为准。核心逻辑遵循同一条主线：先确认 mihomo 内核就绪，再在网络设置中开启 TUN，随后处理系统权限请求，最终检查虚拟网卡是否成功生成。掌握这条主线后，无论界面如何微调，你都能快速定位入口。

Windows 平台配置

在 Windows 10/11 环境下，启动软件后进入设置页（通常位于侧边栏或顶部工具栏的齿轮图标内）。在设置中定位与 TUN 模式、虚拟网卡或系统服务相关的配置分组，打开对应开关。若当前进程未提升权限，软件通常会提示需要安装系统服务（Service）才能完成内核层数据包转发；此时请根据弹窗指引完成安装，并在结束后重启客户端，确保服务挂载真正生效。示例：在某些精简版或深度定制的系统上，服务写入可能因 UAC 策略或组策略限制而失败。若遇此情况，可尝试直接以右键「管理员身份」运行主程序，绕过权限瓶颈。

权限就绪后，返回主界面确认代理模式。若希望所有流量无条件走代理，可将模式切换为「全局」；若仅需代理被规则命中的目标，保持「规则」模式即可。这里存在一个常见的决策分支：Windows 上「系统代理」与「TUN 模式」理论上可并行开启，但经验性观察显示，两者同时作为全局拦截主力时容易因双重劫持导致偶发性延迟波动，甚至个别应用出现循环连接。因此建议在同一时间仅保留一种全局机制，测试 TUN 时可先临时关闭系统代理，验证通过后再根据实际稳定性决定是否共存，避免将变量堆叠在一起导致问题归因困难。

macOS 平台配置

macOS 用户的配置流程与 Windows 相似，但权限链路更长。在设置中启用 TUN 开关后，系统会弹出输入管理员密码的对话框，这是 macOS 为虚拟网卡创建 utun 接口时的标准安全机制。请注意输入的是本地管理员密码（非 Apple ID 密码）。授权完成后，打开「系统设置」-「网络」，应能看到新增的 utun 接口。若你使用的是 Apple Silicon 设备，经验性观察表明 TUN 性能与 Intel 版本无明显差异，且官方发行版通常已提供原生 ARM64 构建，无需通过 Rosetta 转译运行，也不必担心指令集兼容带来的额外开销。

配置完成后，若出现「部分网站间歇性无法打开」的诡异现象——例如国内网站正常，但海外站点反复解析失败——应优先怀疑 DNS 竞争。macOS 的 mDNSResponder 对解析器顺序极为敏感，当 TUN 模式的 Fake-IP 劫持未能排在系统解析器首位时，查询请求可能绕开 Clash 直接流向运营商 DNS，导致污染或劫持结果进入应用层。可复现的验证方法是：在终端执行 scutil --dns 查看 resolver 列表，确认 Clash 虚拟 DNS 是否处于最上方。若发现运营商 DNS 仍优先，可尝试在 Clash 配置中将 DNS 增强模式设为 Fake-IP，并暂时关闭 IPv6 解析，观察问题是否缓解。这一调整在多数由解析顺序引发的异常中收效明显。

Linux 平台配置

Linux 桌面发行版的多样性决定了 TUN 配置最为复杂。通过 deb/rpm 包安装时，安装脚本通常已处理好 TUN 设备权限；但若使用 AppImage 或压缩包直接运行，启用 TUN 后往往会遇到「operation not permitted」错误。此时应先关闭软件，在终端中为二进制文件赋予 CAP_NET_ADMIN 与 CAP_NET_RAW 能力，或在启动命令前加 sudo。具体命令取决于二进制存放路径，请以实际安装位置为准执行 setcap。示例：若主程序位于 /opt/clash-verge/clash-verge，可运行 sudo setcap cap_net_admin,cap_net_raw=+ep /opt/clash-verge/clash-verge，随后以普通用户身份启动即可保留图形环境变量并同时拥有网络设备操作权。

在基于 NetworkManager 的发行版中，TUN 网卡启用后可能自动获得较高的路由优先级，导致物理网卡的默认网关被覆盖。典型表现是「代理节点连通正常，但国内直连网站全部无法访问」。验证方法是执行 ip route show，检查 default 路由是否仅指向 TUN 设备。缓解方案是在 Clash 配置文件的 TUN 段落中，明确设置 route-exclude-address 字段，将国内保留地址段与局域网子网排除；或者调整 TUN 接口的 metric 值，使其低于物理网卡，确保直连流量优先走真实网关。示例：在配置文件中追加 route-exclude-address: [0.0.0.0/8, 10.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4, 240.0.0.0/4] 是常见的排错起点。

DNS 劫持与 Fake-IP 工作流

TUN 模式生效后，DNS 解析流程会发生根本性改变。在 Fake-IP 模式下，当任何应用发起域名查询时，Clash 内核会先在本地返回一个 198.18.x.x 段的虚拟地址——该段属于 RFC 2544 定义的测试地址空间，不会与公网真实 IP 冲突——随后在后台静默完成真实 DNS 解析，并将虚拟地址与真实 IP 的映射关系维护在内存中。整个过程对应用程序完全透明，却能从根本上解决 DNS 污染问题：应用程序拿到的「解析结果」已被 Clash 净化，不再受运营商 DNS 劫持或投毒影响。

示例：当浏览器访问某被污染的国际域名时，若未启用 TUN，操作系统可能先向本地运营商 DNS 查询，拿到一个错误的污染地址，导致即便代理隧道已连通，页面依然无法加载。启用 TUN 并配置 Fake-IP 后，查询请求被虚拟网卡截获，直接由 Clash 内核通过安全的 DNS 上游（如 DoH/DoT）完成解析，再返回虚拟地址给浏览器。浏览器向该虚拟地址发起 TCP 连接时，数据包进入 TUN 网卡，Clash 根据内存中的映射表将目标替换为真实 IP，并转发至代理节点。要验证此流程是否生效，可在浏览器访问公开的 DNS 泄漏检测服务（如 dnsleaktest.com），观察返回的 DNS 服务器是否为你的代理出口，而非本地运营商。若结果显示为代理节点所属地的解析服务器，则说明 Fake-IP 劫持链路已完整生效。

验证与观测：确认全局生效的方法

验证 TUN 是否真正生效，建议采用三层递进法，逐层缩小问题范围。第一层是「设备层」：Windows 用户在「网络连接」中查找名称包含 Meta 或 Clash 的新适配器；macOS 与 Linux 用户在终端执行 ifconfig 或 ip link show，寻找 utun 或 clash 开头的接口。若虚拟网卡缺失，说明 TUN 初始化失败，应优先排查权限提升是否成功、系统服务是否正确挂载，或安装包是否完整。

第二层是「路由层」。在 Windows 命令提示符中执行 route print，应能看到指向虚拟网卡的默认路由或细粒度路由；macOS/Linux 则使用 netstat -rn 或 ip route 查看。若 TUN 已创建但路由表未更新，流量仍会从物理网卡逃逸，此时全局代理实际上处于「假性生效」状态——系统代理部分正常，但底层程序依然直连。第三层是「应用层」：打开一个明确不读取系统代理的应用（如某些独立游戏、UWP 应用，或 WSL2 中的 curl），同时在 Clash Verge 的「连接」页观察是否出现该进程产生的目标域名记录。若日志中捕获了对应请求，则证明内核层拦截已成功，TUN 的透明劫持链路彻底打通。

对于 DNS 层面的验证，建议对比开启 TUN 前后的解析结果。在 Fake-IP 模式下，本地应首先拿到 198.18.x.x 段的虚拟地址，再由 Clash 内核向外发起真实解析；若你看到的仍是运营商本地 DNS 结果，说明 DNS 劫持未生效，此时即便网页能打开，也可能存在解析泄漏风险。走完设备层、路由层、应用层与 DNS 层这四步验证，才能最大限度排除「假性生效」的陷阱，确保没有流量死角。

性能与成本：TUN 模式的资源阈值

从性能视角审视，TUN 模式相当于在用户空间增加了一层网络数据包转发平面。Clash Verge 基于 Rust + Tauri 构建，其基础内存占用经验性观察明显低于传统 Electron 方案；但 TUN 开启后，内存开销将随活跃连接数线性增长。对于一个普通办公场景——浏览器多标签、即时通讯、邮件客户端并行——TUN 模式额外消耗的内存通常在数十到百余兆范围内波动，具体取决于 mihomo 内核的连接池大小与规则集复杂程度。若你加载了上万条规则且保持大量长连接，内存占用可能进一步攀升，这在资源紧张的旧设备上需要提前评估。

CPU 方面，日常浏览与流媒体场景下 TUN 的转发延迟几乎无感知；但在高并发短连接或 UDP 打洞场景（如外服游戏语音、P2P 下载）中，频繁的用户态与内核态上下文切换可能导致 CPU 占用出现可见脉冲。经验性观察表明，在低功耗轻薄本上开启 TUN 并进行大文件下载时，整体转发吞吐可能较纯系统代理方案略有下降。要量化这一影响，可在开启与关闭 TUN 的状态下，通过同一节点下载同一文件，对比稳定后的平均速率；若降幅超出可接受范围，应在该场景下临时回退到系统代理，而非让 TUN 全程常驻。

电池续航是移动端不可忽视的隐性成本。虚拟网卡持续活跃意味着网络栈无法进入深度休眠，后台进程必须维持数据平面的持续转发。经验性观察发现，在 macOS 笔记本上长时间开启 TUN 模式，活动监视器中的网络相关进程会持续占用少量 CPU 周期，对离电续航产生可感知的影响。因此，移动办公用户若仅需间歇性访问国际网络，建议养成「用完即关」的习惯，或通过快捷指令、脚本在 TUN 与系统代理之间快速切换，在连通性与续航之间找到动态平衡。

MTU 与协议栈调优

TUN 虚拟网卡的 MTU（最大传输单元）设置直接影响大包分片行为与传输效率。默认值通常由 mihomo 内核在初始化时根据平台特性自动设定，但在某些网络环境下，默认 MTU 可能高于实际路径允许值，导致数据包在传输过程中被静默分片甚至丢弃。一个典型的症状是：开启 TUN 后，视频会议软件出现画面卡顿或音频断续，而网页浏览却完全正常。这往往是因为视频流使用了较大的 UDP 包，超出了当前路径的 MTU 上限，而 TUN 接口未能正确触发路径 MTU 发现机制，导致接收端重组失败。

针对此类问题的可复现验证方法是：在开启 TUN 时，使用 ping 命令配合不分片标志（Windows 为 -f，Linux/macOS 为 -M do）测试最大通过尺寸。示例：ping -M do -s 1472 example.com。若发现超过某一大小的包无法到达，可尝试在 Clash 配置文件的 TUN 段中将 mtu 值从默认设定调低至 1400 甚至 1300，重启 TUN 后再次测试。经验性观察显示，在部分运营商 QoS 策略较严格的网络中，适当降低 MTU 能显著改善 UDP 重传率与实时音视频体验。反之，若你仅进行网页浏览与文件下载，默认 MTU 通常无需调整，盲目缩小反而可能降低吞吐。

常见故障与回退方案

故障排查应遵循「现象 → 归因 → 验证 → 处置」的闭环，避免盲目尝试配置项。最常见的现象是「开启 TUN 后整机断网」。首要归因方向是权限与服务：Windows 检查系统服务列表中是否存在 Clash 相关服务；macOS 确认虚拟网卡处于「已连接」状态；Linux 检查 /dev/net/tun 访问权与 capabilities 是否到位。若权限无异常但仍断网，第二步应检查 DNS 配置，确认 Clash 的 DNS 监听地址未被其他程序（如本地广告拦截工具、企业 privacy tool）占用，因为这些工具同样会劫持 53 端口，形成冲突。

第二个高频问题是「代理节点连通，但部分国内应用或局域网设备无法访问」。此现象多由路由优先级冲突引起。例如，企业 privacy tool 客户端通常也会创建虚拟网卡，与 Clash TUN 在路由表上竞争 0.0.0.0/0 的默认网关。可复现的验证步骤是：先关闭 Clash TUN，确认企业 privacy tool 正常；再单独开启 Clash TUN，观察冲突是否复现。若确认冲突，处置方案是在 Clash 配置中利用 exclude-interface 排除企业虚拟网卡，或调整 TUN 接口的 metric，确保内网流量优先走企业隧道，避免「两条隧道互抢流量」导致的环路或黑洞。

当需要紧急恢复直连网络时，回退路径必须清晰且可执行。首选方案是在 Clash Verge 设置中一键关闭 TUN，软件会自动卸载虚拟网卡并恢复原始路由。若遇极端情况（如客户端卡死导致网卡残留），Windows 用户可进入「网络连接」手动禁用 Meta 网卡；macOS 用户在「系统设置」-「网络」中移除对应的 utun 接口；Linux 用户执行 ip link set dev [设备名] down 手动关闭。提前熟悉这些手动回退手段，能避免在紧急会议、在线考试或重要提交场景下陷入被动断网的困境。

适用场景与边界判断

TUN 模式的启用应建立在明确的准入条件之上，而非「开了总比不开好」的惯性思维。最典型的适用场景可归纳为三类：第一类是不遵循系统代理的桌面应用，如部分使用自定义网络栈的游戏启动器、老旧 C/S 软件，它们既不会读取系统代理变量，也不提供手动代理入口；第二类是命令行与开发环境，如 WSL2、Docker Desktop、终端包管理器，这些环境读取 HTTP_PROXY 变量的机制往往不可靠，甚至完全忽略；第三类是对 UDP 流量有强制代理需求的游戏加速，系统代理通常仅覆盖 TCP，而 TUN 可透明承接 UDP 报文，满足语音联机与反作弊验证的底层需求。当你面临上述任一情形时，TUN 几乎成为必选项。

与此同时，以下场景建议避免使用 TUN：第一，高吞吐、低延迟敏感的局域网文件传输，如向 NAS 拷贝大文件，TUN 的额外转发跳数与潜在分片会不必要地拖累内网性能；第二，受严格合规审计的企业环境，虚拟网卡与全局流量劫持可能触发终端安全软件（EDR/XDR）告警，甚至直接违反网络准入策略（NAC）；第三，仅需浏览器访问海外资源的轻量需求，系统代理配合 PAC 规则已足够，无需引入内核级修改。简言之，只有当「系统代理确实无法覆盖目标流量」且「设备性能与权限条件均允许」这两个前提同时成立时，启用 TUN 才是合理决策。任何单一条件不满足，都意味着你应该寻找更轻量的替代方案。

最佳实践与风险清单

基于上述分析，可将决策流程固化为一份前置检查表。在点击 TUN 开关前，请先回答三个问题：目标流量是否确实无法通过系统代理满足？当前设备性能（尤其是内存与 CPU）是否足以承担额外转发开销？是否已经验证过关闭 TUN 后的回退路径？三者均为肯定时，才具备启用的最小安全集。此外，建议为 TUN 模式单独维护一份配置文件副本，而非直接修改主用的系统代理配置；这样即便实验性参数（如自定义 MTU 或激进的路由排除规则）导致异常，也能通过切换配置迅速回到稳定基线，缩短故障半径。

权限最小化原则同样不可忽视。TUN 模式虽需管理员权限以创建虚拟网卡，但日常运行时无需始终保持最高权限进程。Windows 用户可通过安装系统服务的方式，让数据平面以受限服务账户运行，降低攻击面；macOS 与 Linux 用户应避免长期以 root 启动整个图形界面，而是在首次授权后利用系统机制（如 pkexec 或 setcap）完成提权分离，让 GUI 层以普通用户身份工作。对于多节点用户，建议在启用 TUN 前进行节点测速，优先选择 TCP 与 UDP 均稳定的节点作为默认出口。经验性观察表明，部分仅支持 TCP 的中转节点在承载 UDP 游戏流量时可能严重丢包，而在 TUN 全局模式下，这种丢包会被放大为「整机网络卡顿」的体感——因为所有流量共享同一出口，UDP 的劣化会直接影响你对网络质量的综合判断。

FAQ