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

功能定位：TUN 模式与系统代理的边界

许多用户在使用 Clash Verge 时会遇到一种割裂的困境：浏览器已通过代理正常访问目标站点，但命令行里的 curl、Docker 镜像拉取，或是某些桌面游戏的联机流量，依然固执地走直连出口。这种差异的根源在于传统“系统代理”（System Proxy）的工作方式——它依赖操作系统暴露的 HTTP 代理变量或 PAC 脚本，仅对主动读取该配置的应用生效；而大量基于底层 Socket 编程的软件根本不会理会这层提示。TUN 模式的出现正是为了弥合这一断层：它在操作系统内核与用户空间之间插入一张虚拟网卡，将所有准备从物理网卡发出的 IP 数据包先行引入 Clash 内核，再依据规则集裁决是直连还是转发至远端节点。这种工作在网络层的隧道（Network TUNnel）技术，覆盖了系统代理难以触及的流量盲区。但凡事皆有两面，正因为 TUN 模式触及驱动层与路由表，启用前必须厘清权限要求、平台差异以及与企业级安全软件的潜在冲突，否则极易陷入“一开 TUN 就断网”的尴尬局面。

与系统代理相比，TUN 模式的核心差异体现在“流量捕获粒度”上。系统代理属于应用层方案，它温和地告知软件“请把流量发给我”；而 TUN 模式则是网络层的强制引流——无论目标应用是否支持代理，其 IP 包都会先经过 Clash 内核的裁决。这种能力特别适合代理那些没有代理配置入口的程序，例如 Windows 上的部分 UWP 应用、依赖独立网络栈的 P2P 工具，以及各类命令行开发环境。但代价是系统侵入性更强：它会修改路由表、创建虚拟网络接口，并在部分平台上注册数据包过滤驱动。因此，如果你只是通过浏览器偶尔查阅资料，系统代理已足够；只有当你发现“总有几个应用绕过了代理”，才是考虑启用 TUN 模式的合理时机。

启用前的三项准入检查

在点击 TUN 开关之前，建议先完成三项基础检查，这能避免后续九成以上的不明原因故障。第一项是操作系统权限。由于 TUN 模式需要创建虚拟网卡并修改系统路由表，Windows 端必须拥有管理员权限，macOS 和 Linux 端则要求当前用户具备修改网络接口的能力。若你在企业分配的办公设备上操作，开启开关后却未见任何虚拟网卡出现，很可能是因为组策略（Group Policy）或 MDM 配置禁止了非管理员驱动安装。第二项是现有网络软件的冲突排查。经验性观察表明，其他具备网络过滤功能的客户端——如企业级终端检测与响应（EDR）软件、远程办公隧道工具，甚至某些广告拦截工具——可能已在系统内核层注册了网络过滤驱动。在 Windows 上表现为 WFP（Windows Filtering Platform）优先级冲突，在 macOS 上则可能体现为 utun 接口资源被占用。第三项是规则集准备。TUN 模式一旦启用即为“真全局”劫持，若未事先配置好直连规则，国内流量也会被一并转发，进而触发视频网站版权区域限制、网银风控拦截或局域网设备失联。

这三项检查的逻辑顺序不可颠倒：先确保“我能改”，再确认“没人拦”，最后验证“规则是否够用”。不少新手在规则集尚未完善时就贸然开启 TUN，结果整机网络异常，反而误以为是 Clash Verge 本身存在缺陷。实际上，TUN 模式仅提供流量入口，出口行为完全取决于你预先设定的规则。对于从其他 Clash 客户端迁移过来的用户，还需核对配置文件中是否包含 tun 字段，并确认 Clash Verge 当前使用的内核（如 mihomo）是否已编译进 TUN 支持——截至当前的最新版本，桌面端主流发行版通常默认包含该能力，但极其精简的自定义编译版本可能将其剔除。

Windows 平台配置路径与驱动授权

在 Windows 上启用 TUN 模式的路径通常最为直接。打开 Clash Verge 主界面后，进入 Settings（设置）面板，找到标有 TUN Mode、TUN 模式或 System Service 的开关区域——不同版本的界面命名可能存在细微差异，请以实际安装版本为准。首次开启时，系统会立即弹出 UAC（用户账户控制）对话框，要求授予管理员权限，以便向系统注册虚拟网卡驱动并写入新的路由表项。点击同意后，程序会自动尝试安装 WinTUN 驱动或注册 WFP 过滤规则。等待数秒，可进入 Windows 的“网络连接”控制面板（运行 ncpa.cpl）查看是否出现一张名为“Clash”或“Meta”的虚拟网卡。若该网卡已出现且状态为“已启用”，说明驱动层初始化成功。

配置完成后，建议通过一个命令行场景验证效果：在 PowerShell 或 CMD 中执行 curl -v https://api.ip.sb/geoip，观察返回的 IP 所属地是否与代理节点一致。在仅开启系统代理时，这类未读取 HTTP_PROXY 变量的请求通常会返回本地运营商 IP；而 TUN 模式生效后，它们应当被正确劫持。需要特别注意的是，Windows 平台上 TUN 模式与某些第三方安全软件的兼容性最差。经验性观察显示，当系统中存在其他 WFP 驱动（如部分企业 privacy tool 客户端、终端安全管理软件）时，Clash Verge 的数据包可能被更高优先级的过滤器拦截，表现为 TUN 开关已打开但特定应用依旧直连，甚至直接报错无法启动虚拟网卡。处置方法是临时退出冲突软件，或在 Clash Verge 的高级设置中查看是否支持切换 TUN 协议栈实现（例如从 system 切换为 gvisor），以降低与底层驱动的耦合。

macOS 平台配置路径与系统扩展

macOS 用户的路径则多了几层系统授权。进入 Clash Verge 设置界面开启 TUN 开关后，系统通常会弹出提示，要求你前往“系统设置 → 隐私与安全性”中允许“系统扩展”或“辅助功能”权限。具体需要授权的项可能因版本而异，但核心目的都是让 Clash Verge 获得创建 utun 虚拟接口的能力。与 Windows 的 WinTUN 不同，macOS 依赖内核自带的 utun 框架，因此无需额外安装第三方网卡驱动，但系统对非 App Store 软件的扩展控制极为严格。若开启 TUN 后发现网络没有任何变化，首先应检查“系统设置”中是否有被阻止的扩展提示，点击“允许”后通常需要重启应用才能生效。

一个常见障碍是，从网络直接下载的 Clash Verge 可能在较新的 macOS 版本中被 Gatekeeper 标记为“已损坏”，导致不仅 TUN 模式无法启动，连主程序都难以运行。经验性观察表明，此时需要在“系统设置 → 隐私与安全性”中允许从任何来源下载的应用，并在终端执行 sudo xattr -dr com.apple.quarantine 命令移除应用的隔离属性，具体路径以实际安装位置为准。完成授权并重启应用后，可通过终端执行 ifconfig | grep utun 查看是否出现由 Clash 创建的 utun 接口。此外，macOS 上的 TUN 模式还可能与某些企业级网络客户端（如部分 SSL privacy tool 或零信任终端）产生 utun 序号争夺。若你发现开启 TUN 后企业内网断开，而关闭 TUN 后恢复，大概率是两类工具抢占了同一个虚拟接口编号，此时只能通过错开使用时段或调整企业客户端配置来缓解。

Linux 平台配置与权限管理

Linux 发行版的多样性决定了 TUN 模式的路径差异化最大，但核心原理不变：Clash Verge 需要创建 /dev/net/tun 设备节点并写入系统路由表。在 Clash Verge 的设置面板中开启 TUN 后，程序通常会自动检测当前用户权限。若以普通用户身份运行时发现 TUN 无法启动，首先应确认当前用户是否属于 network、wheel 或系统管理员组，或者是否具备 CAP_NET_ADMIN 能力。在基于 systemd 的发行版上，若 Clash Verge 以服务形式后台运行，还需确保服务单元文件（Unit File）中未过度限制网络权限。与 Windows 和 macOS 不同，Linux 端极少出现驱动冲突，但更容易遇到路由表优先级问题——例如系统自带的 NetworkManager 或 systemd-resolved 可能会覆盖 Clash 写入的路由，导致 TUN 接口虽然存在，流量却并未真正经过它。

验证 Linux 端 TUN 是否生效，建议使用 ip addr 或 ip route show 观察是否出现由 Clash 管理的虚拟网卡及对应的默认路由项。一个典型的场景是：开发者在 WSL2 或 Docker Desktop 环境中拉取镜像，发现即使宿主机浏览器已走代理，容器内依旧超时。这是因为容器往往运行在独立的网络命名空间，不继承宿主机的 HTTP_PROXY 变量。在宿主机开启 Clash Verge 的 TUN 模式后，由于 TUN 工作在 IP 层，容器发出的数据包同样会被宿主机的路由表牵引至虚拟网卡，从而实现全局纳管。不过，这一场景的边界在于：如果 Docker 使用了自定义网桥或 privacy tool 套娃，路由表可能产生环路，此时需要手动将 Docker 的网段排除在 Clash 的劫持范围之外。

规则分流：避免全局劫持的副作用

TUN 模式一旦开启，默认会劫持几乎所有出站 IP 包，这会带来一些意想不到的副作用。例如，国内视频平台可能因出口 IP 变更而触发版权限制，网银客户端可能因检测到“非常用网络环境”而拒绝交易，局域网内的打印机或 NAS 也可能因流量被错误转发而无法访问。因此，配置精细化的规则集（Rule Set）是使用 TUN 模式的前提，而非可选项。在 Clash Verge 的规则面板中，建议为大陆常用域名、局域网段（如 192.168.0.0/16、10.0.0.0/8、172.16.0.0/12）以及特定进程名（PROCESS-NAME）设置 DIRECT 规则。规则匹配的优先级通常从上至下，因此应将最精确的直连规则置于最前，避免被下方的兜底代理规则提前命中。

以游戏场景为例：Steam、Epic Games 或战网客户端的下载节点通常具备完善的 CDN 调度，若强制通过代理转发，反而可能降低下载速度并增加延迟。经验性观察表明，部分游戏平台在检测到代理出口 IP 后，甚至会拒绝连接或限制下载速率。此时，通过在规则集中为 steam.exe、EpicGamesLauncher.exe 或对应的 CDN 域名（如 *.steamcontent.com）添加 DIRECT 规则，就能让游戏更新流量直连，而其他系统流量继续走代理。另一个典型场景是远程办公：Zoom、Microsoft Teams 或企业微信的视频会议流量若全部绕路海外节点，可能造成严重的抖动和丢包。为这些进程配置直连或走专用线路规则，能显著改善通话质量。规则分流的本质是“该直连的绝不绕路，该代理的绝不漏网”，这在 TUN 模式下比在系统代理模式下更为重要——后者的漏网流量本就是少数，而前者的误伤流量可能是全部。

DNS 解析模式的选择与验证

TUN 模式对 DNS 的劫持往往比系统代理更彻底。在默认配置下，Clash 内核会接管所有发往 53 端口的查询请求，并根据配置返回 fake-ip 或真实 IP。fake-ip 模式通过返回一个虚拟的 IPv4（通常为 198.18.x.x 段）来强制应用将连接交给 Clash 处理，响应速度快，且能有效避免 DNS 污染，但可能导致部分依赖真实 DNS 解析结果的局域网设备异常。若你在开启 TUN 后发现某些内网管理页面无法打开，或网银插件提示网络异常，可尝试在 Clash Verge 的 DNS 设置中将模式从 fake-ip 切换为 redir-host，或针对特定域名配置 nameserver-policy 指定本地 DNS 服务器。redir-host 模式虽然解析速度略慢，但兼容性更好，适合网络环境复杂的用户。

验证 DNS 是否被正确劫持的方法也很简单：访问公开的 DNS 泄漏检测站点，若返回的解析服务器与代理节点所在地区一致，则说明 TUN 栈已成功拦截 UDP 53 流量；若仍显示本地运营商 DNS，则需检查 TUN 接口是否已正确接管系统默认出站接口。另一个常见陷阱是“DNS 死循环”：某些配置中，Clash 自身的 DNS 查询被错误地指向了一个需要代理才能访问的远端 DNS，而远端 DNS 的查询又因为规则配置不当被再次转发，形成循环。解决思路是在 nameserver 列表中保留一个可直接访问的本地 DNS（如路由器网关地址或运营商 DNS），作为解析 Clash 自身所需域名的兜底。需要强调的是，fake-ip 与 redir-host 的选择没有绝对优劣，只有场景适配：追求低延迟和抗污染选前者，追求最大兼容性与局域网互通选后者。

生效验证与回退方案

配置完成后，验证比“感觉能访问”更可靠。第一步，打开 Clash Verge 的 Connections（连接）面板，观察是否有非 HTTP/HTTPS 端口的连接出现——例如 UDP 53 的 DNS 查询、游戏进程的 TCP/UDP 会话，这些通常是系统代理无法捕获的流量。若你看到大量 UDP 会话被正确标记为代理或直连，说明 TUN 的劫持范围已覆盖传输层。第二步，在终端执行 traceroute（Windows 为 tracert）一个公网地址，观察第一跳或第二跳是否指向虚拟网卡分配的网关地址（如 198.18.0.1 或 172.19.0.1，具体网段因配置而异）。若首跳即为本地路由器，则表明流量并未进入 TUN 接口，需回头检查路由表或驱动状态。第三步，通过第三方 IP 检测网站确认出口 IP 与所选代理节点所在地一致，这一步可以排除“规则漏配导致直连”的侥幸心理。

典型故障排查：现象、根因与处置

尽管操作路径明确，实际使用中仍可能遇到几类典型故障。第一类是“开启 TUN 后整机断网”。这通常源于 WFP 驱动冲突或 DNS 死循环：经验性观察表明，某些企业安全客户端（如终端检测与响应 EDR、其他网络隧道软件）已在 Windows 过滤平台注册了高优先级驱动，导致 Clash Verge 的数据包被拦截或丢弃。处置方法是暂时退出冲突软件，或在 Clash Verge 的高级设置中尝试切换 TUN 的协议栈实现（例如从 system 切换为 gvisor 或 lwIP，若当前版本界面提供此选项），这些用户空间协议栈实现绕过了部分内核过滤层，兼容性更好但性能略有折损。第二类是“特定应用依旧绕过代理”。此类应用可能使用了硬编码 IP、独立的网络协议栈，或运行在与 TUN 网卡不同的网络命名空间中；可通过 Clash Verge 的连接日志确认该进程是否出现，若未出现，则需补充 PROCESS-NAME 规则或 IPCIDR 规则将其强制纳入，或检查该应用是否具备“禁用系统代理”的自我保护机制。

第三类是“订阅更新超时或提示连接失败”。在 TUN 模式下，若 DNS 初始化尚未完成，或节点延迟过高，Clash 内核向订阅地址发起请求时可能超时。经验性观察显示，此时可尝试临时关闭 TUN 模式完成订阅更新，待配置刷新后再重新开启；另一种做法是在规则集中确保订阅域名所在的服务商域名优先走 DIRECT，或延长请求的超时阈值。第四类是 macOS 上的“应用损坏”或“系统扩展被阻止”。这并非 TUN 模式本身的缺陷，而是 macOS Gatekeeper 对非签名应用的阻拦，前文已述其处置方式。排查故障时务必养成查看 Clash Verge 日志面板的习惯，内核日志中的 tun、dns、inbound 标签往往直接指向根因，比盲目重装软件高效得多。

适用场景与决策边界

并非所有用户都需要长期开启 TUN 模式。对于仅通过浏览器访问网络、且所有工具都支持系统代理变量的用户，保持默认的系统代理即可，无需承担虚拟网卡带来的额外复杂性与潜在冲突。TUN 模式真正的价值场景包括：代理命令行编译工具（如 Docker、npm、pip）、P2P 下载、游戏流量，或对整个系统的出站流量进行统一审计和分流。例如，一名后端开发者在本地同时运行 Homebrew、Terraform 和多个 Docker 容器，若逐一为这些工具配置代理变量极为繁琐，此时开启 TUN 模式属于“一劳永逸”的合理选择。同样，当你需要确保某款没有代理设置入口的独立游戏或语音软件走特定节点时，TUN 模式几乎是唯一可靠的方案。

反过来，以下场景建议慎用或避免使用：接入强合规审计的企业内网——虚拟网卡与流量重定向极易触发安全告警，甚至导致内网准入系统强制断网；对电池续航极度敏感的移动设备——虚拟网卡持续运行会增加额外的内核态计算与上下文切换，虽然单次开销不大，但累积续航影响在数小时使用后可能变得明显；以及延迟要求低于毫秒级的竞技类游戏——虚拟网卡引入的一跳转发可能带来可感知的抖动，且规则集逐条匹配本身也有微秒级开销。在决定是否启用 TUN 模式前，可以先用下面这张简化的决策清单自评：你是否遇到了“系统代理无法覆盖”的硬性需求？设备上是否存在已知的驱动冲突软件？规则集中是否已完善直连与局域网例外？如果三项均为“是”，那么 TUN 模式将显著提升你的网络代理覆盖率；若任一项为“否”，建议先解决前置条件，而非强行开启。

常见问题（FAQ）

结语与下一步行动

从“部分应用代理”迈向“全局网络接管”，TUN 模式是 Clash Verge 提供给高阶用户的核心能力，但它从来不是简单的“一键开关”。完整的落地路径应当是：先评估权限与冲突环境，再分平台完成驱动授权，随后通过精细化的规则集隔离直连流量，最后借助连接面板与 traceroute 完成验证。建议初次配置时保持日志窗口开启，从小范围规则测试开始，逐步扩大代理范围，而不是一上来就追求“所有流量全走 TUN”。如果在企业设备或生产环境中使用，请务必先与网络管理员确认合规要求，避免触发安全审计告警。

你的下一步行动可以非常具体：首先，打开 Clash Verge 的设置面板，确认当前版本是否支持 TUN（截至当前的最新版本通常默认支持），然后按本文的平台路径尝试开启；其次，花十分钟整理你的规则集，为常用的国内应用、游戏进程和局域网段添加 DIRECT 规则；最后，使用命令行工具做一次 traceroute 验证，确保 TUN 确实在生效。保持配置的整洁与可回退，才能让 TUN 模式真正成为提升网络体验的工具，而非排不完的故障源头。如果你在验证过程中遇到无法解释的现象，优先导出 Clash 内核日志并锁定 tun 与 dns 标签，这通常比在网络社区泛泛提问更能快速定位答案。展望未来，随着 Clash 内核（如 mihomo）的持续迭代，TUN 模式的协议栈实现与跨平台兼容性仍在不断优化；经验性观察表明，后续版本可能会进一步简化驱动授权流程，并提升与容器化环境及企业安全软件的共存能力，值得持续关注官方发行日志。