打开呀 .co

海外网站与 AI 访问解决方案
客户端配置教程 • • 更新：2026-09-25 • 实操配置指南

Clash Verge TUN 虚拟网卡模式详解

为什么有些应用（终端命令行、部分游戏、应用商店）不走系统代理？打开呀深度拆解 Clash Verge Rev 的 TUN 虚拟网卡（Wintun）工作模式、服务模式授权与全局流量接管。

Clash Verge TUN 虚拟网卡模式详解：原理、服务模式与游戏/CLI代理

Clash Verge TUN 虚拟网卡模式详解

Answer Block

Clash Verge 的 TUN 模式通过 Wintun（Windows）/ utun（macOS）创建一块三层（L3）虚拟网卡，把整机 IP 数据包（含 TCP、UDP、ICMP）重定向进 Clash 内核，从而接管那些不遵循系统代理规范的应用（游戏、CLI 工具、ping、Docker、部分 Electron 客户端）。它与”系统代理”的本质区别在于拦截层级：系统代理工作在应用层（L7），依赖应用主动读取 HTTP_PROXY/HTTPS_PROXY 或 WinINET 设置；TUN 工作在网络层（L3），对应用完全透明。TUN 生效的硬性前提是管理员权限或安装 Service Mode 服务（以 SYSTEM 身份常驻，避免每次 UAC 提权）。DNS 层面需配合 fake-ip 或 redir-host 模式，并防止 TUN 网卡自身 DNS 请求回环造成死循环。常见冲突源包括 Hyper-V/WSL2 虚拟交换机、网银安全控件、残留的 TAP/Wintun 驱动。

一、系统代理 vs TUN：本质是 L7 与 L3 的分野

1.1 系统代理（System Proxy）——应用层协作

Clash Verge 开启”系统代理”时，实际做的是两件事：

  • Windows：改写注册表 HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings 下的 ProxyEnable、ProxyServer，并广播 WM_SETTINGCHANGE 通知 WinINET/WinHTTP 栈。
  • macOS：调用 networksetup -setwebproxy / -setsecurewebproxy / -setsocksfirewallproxy 修改网络服务配置。

这意味着：

流量类型系统代理能否接管原因
浏览器 HTTP/HTTPS✅读取系统代理或环境变量
curl / wget⚠️ 部分需 http_proxy 环境变量，否则直连
ping (ICMP)❌ICMP 无”代理”概念，协议层不支持
游戏 UDP 包❌硬编码 socket，无视系统代理
Docker 容器流量❌独立 netns，不继承宿主代理
硬编码 IP 的 CLI❌不查系统代理设置

一句话：系统代理是”君子协定”，应用不遵守就完全失效。

1.2 TUN 虚拟网卡——网络层接管

TUN 模式创建一块虚拟网卡，Clash 内核通过它读写原始 IP 包：

应用 socket → 内核路由表 → TUN 网卡 → Clash 内核 → 出站策略 → 物理网卡

关键机制：

  • 路由劫持：Clash 向系统路由表注入 0.0.0.0/1 和 128.0.0.0/1 两条路由（比默认路由 0.0.0.0/0 更精确），把默认流量导向 TUN 网卡，同时保留原默认路由用于 Clash 自身出站，避免环路。
  • Wintun 驱动：Windows 上使用 WireGuard 项目开源的 Wintun（wintun.dll），性能远优于老旧的 TAP-Windows，支持多队列、零拷贝。
  • utun：macOS 上使用系统原生 utun 接口，无需第三方驱动。

因为工作在网络层，ICMP、UDP、任意 TCP 都被无差别接管，应用完全无感知。

1.3 验证命令

Windows PowerShell（管理员）：

# 查看 TUN 网卡是否创建
Get-NetAdapter | Where-Object {$_.InterfaceDescription -like "*Wintun*"}

# 查看路由表是否被劫持
route print 0.0.0.0

# 查看监听端口（Clash 混合端口默认 7890）
netstat -ano | findstr :7890

macOS：

# 查看 utun 接口
ifconfig | grep -A 5 utun

# 查看路由
netstat -rn | grep default

# 查看端口占用
lsof -iTCP:7890 -sTCP:LISTEN

二、TUN 生效的前提条件

2.1 权限模型

TUN 需要创建虚拟网卡并修改系统路由表，这是特权操作：

  • Windows：必须管理员权限。Clash Verge 提供两种方案：

    1. 每次 UAC 提权：简单但每次启动弹窗。
    2. Service Mode（推荐）：安装一个 Windows 服务（clash-verge-service），以 LocalSystem 身份常驻，GUI 通过命名管道与之通信。安装后普通用户即可开关 TUN，无需 UAC。
    # 检查服务状态
Get-Service clash_verge_service

# 手动启动
Start-Service clash_verge_service

  • macOS：需要 sudo 或安装特权帮助工具（com.github.zzzgydi.clash-verge.helper），通过 SMJobBless 机制注册 LaunchDaemon。

2.2 内核与驱动

  • Clash Verge 使用 Mihomo（Clash.Meta） 内核时，TUN 支持更完整（含 gVisor 栈、system 栈切换）。
  • Windows 首次启用 TUN 会自动释放 wintun.dll 并安装驱动；若失败，检查 C:\Windows\System32\wintun.dll 是否存在。

2.3 配置片段

tun:
  enable: true
  stack: mixed          # gvisor / system / mixed
  dns-hijack:
    - any:53
    - tcp://any:53
  auto-route: true
  auto-detect-interface: true
  mtu: 9000
  • stack: system：性能最高，但兼容性略差。
  • stack: gvisor：用户态网络栈，兼容性最好，性能略低。
  • stack: mixed：TCP 走 system，UDP 走 gvisor，平衡之选。

三、DNS 劫持与防泄漏

3.1 fake-ip vs redir-host

模式原理优点缺点
redir-host真实解析域名得到 IP，用 IP 反查域名做规则匹配兼容性好，IP 真实首次解析慢，DNS 泄漏风险高
fake-ip立即返回 198.18.0.0/16 段的假 IP，连接时用假 IP 反查域名解析快，无 DNS 泄漏部分应用不兼容（如硬编码 IP 校验）

fake-ip 工作流：

应用查询 example.com
  → Clash DNS 返回 198.18.0.5（假 IP）
  → 应用连接 198.18.0.5
  → Clash 查映射表得知是 example.com
  → 按规则走代理，真实 DNS 在远端解析

3.2 DNS 回环与死循环预防

TUN 模式下最危险的问题是 DNS 请求回环：

应用 → TUN 网卡 → Clash → 需要解析 DNS → 又走 TUN → 死循环

防护措施：

  1. dns-hijack：Clash 在 TUN 层直接劫持 any:53，DNS 请求不再出网卡。
  2. nameserver 走直连：配置中 nameserver 必须走物理网卡，不能走代理。
  3. fallback-filter：过滤污染结果。
dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "stun.*.*"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - tls://8.8.8.8:853
  fallback-filter:
    geoip: true
    geoip-code: CN

3.3 防泄漏检查

# Windows：确认 DNS 未泄漏
Resolve-DnsName example.com -Server 198.18.0.2

# 查看 DNS 客户端缓存
ipconfig /displaydns | Select-String "example"
# macOS
scutil --dns | head -30
sudo dscacheutil -flushcache

四、常见冲突排查

4.1 Hyper-V / WSL2 冲突

Hyper-V 会创建 vEthernet (Default Switch) 虚拟交换机，与 TUN 的 auto-route 争夺路由优先级，表现为部分流量绕过 TUN。

排查：

Get-NetAdapter | Where-Object {$_.Virtual -eq $true}
Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric

解决：

  • 在 Clash 配置中设置 interface-name 显式指定物理网卡。
  • 或调整 route-metric，让 TUN 网卡 metric 低于 vEthernet。

4.2 网银安全插件冲突

国内网银控件（如工行、建行 U 盾驱动）会安装 NDIS 中间层驱动或 LSP，拦截所有网络流量做加密校验。与 TUN 同时存在时，可能出现：

  • 网银页面无法加载；
  • Clash 日志大量 connection reset。

解决：在规则中把网银域名/IP 段走 DIRECT，或临时关闭 TUN 使用系统代理。

4.3 驱动残留排查

卸载 Clash Verge 后若 TUN 网卡仍存在：

# 列出所有 Wintun 网卡
Get-NetAdapter | Where-Object {$_.InterfaceDescription -like "*Wintun*"}

# 强制删除
pnputil /enum-drivers | Select-String "wintun"
pnputil /delete-driver oemXX.inf /uninstall /force

macOS 检查残留 utun：

ifconfig | grep utun
# utun 由系统管理，重启即清理

4.4 端口占用

# 查找占用 7890 的进程
netstat -ano | findstr :7890
tasklist | findstr <PID>
# macOS
lsof -iTCP:7890 -sTCP:LISTEN
kill -9 <PID>

五、高价值长尾 FAQ

H3：为什么开启 TUN 后 ping 通了但浏览器打不开网页？

这是典型的 DNS 与路由分离问题。ping 走 ICMP，TUN 直接接管，所以通；浏览器需要 DNS 解析，若 dns-hijack 未生效或 nameserver 配置错误，域名解析失败，网页自然打不开。排查顺序：① 确认 dns.enable: true 且 listen: 0.0.0.0:53；② 检查 dns-hijack 是否包含 any:53；③ 用 nslookup example.com 127.0.0.1 测试本地 DNS 是否响应；④ 若使用 fake-ip，确认 fake-ip-filter 未误伤目标域名。另一个隐蔽原因是 IPv6 泄漏：TUN 只劫持了 IPv4 路由，浏览器优先走 IPv6 直连导致失败，需在配置中 ipv6: false 或补充 IPv6 路由劫持。

H3：Service Mode 安装失败或服务无法启动怎么办？

Service Mode 依赖 Windows 服务注册与命名管道通信，失败常见于三类原因：① 杀毒软件拦截——360、火绒会阻止服务创建命名管道，需加白名单；② 权限不足——安装服务本身需管理员，若当前账户是标准用户，先切换到管理员账户安装；③ 旧版本残留——之前安装过同名服务未卸载干净。排查命令：sc query clash_verge_service 查看状态，sc delete clash_verge_service 强制删除后重装。若日志显示 Access is denied，检查 C:\Program Files\Clash Verge\ 目录 ACL 是否被篡改。macOS 上对应问题是 SMJobBless 失败，通常因 helper 的代码签名与主程序不匹配，需重新下载官方签名版本。

H3：TUN 模式下 Docker 容器流量为什么还是直连？

Docker Desktop 在 Windows 上默认使用 WSL2 后端，容器运行在独立的 Linux netns 中，其流量经 vEthernet (WSL) 虚拟网卡 NAT 后出宿主，不经过宿主默认路由，因此 TUN 无法接管。解决方案有三：① 在 Docker 容器内单独配置代理环境变量 HTTP_PROXY；② 使用 --network host 模式（仅 Linux 容器）；③ 在 Clash 配置中把 WSL 网段 172.16.0.0/12 显式路由到 TUN。macOS 上 Docker 使用 vmnet 框架，情况类似。根本原因是 网络命名空间隔离，TUN 只能接管宿主 netns 的流量。

H3：fake-ip 模式导致某些应用无法连接，如何精准排除？

fake-ip 的本质是”用假 IP 换真域名”，但部分应用会做 IP 合法性校验（如检测到 198.18.x.x 直接拒绝）或 硬编码 IP 直连（不查 DNS，fake-ip 无从介入）。典型受害者：Steam 部分服务、部分游戏反作弊、企业 VPN 客户端。解决方法是把这些域名加入 fake-ip-filter，让它们走真实 DNS 解析：

fake-ip-filter:
  - "*.steampowered.com"
  - "*.epicgames.com"
  - "+.lan"
  - "+.local"
  - "geosite:private"

注意 fake-ip-filter 中的域名会走 nameserver 真实解析，因此要确保 nameserver 本身可靠且不泄漏。若某应用仍异常，可临时切换 enhanced-mode: redir-host 验证是否为 fake-ip 引起。

H3：如何判断 TUN 是否真正接管了全部流量，而非部分泄漏？

需要从路由表、DNS、实际连接三个维度交叉验证。① 路由层：route print 0.0.0.0（Windows）或 netstat -rn（macOS）应看到 0.0.0.0/1 和 128.0.0.0/1 指向 TUN 网卡；② DNS 层：nslookup example.com 应返回 fake-ip 段地址（若用 fake-ip），或返回 Clash 配置的 nameserver 结果；③ 连接层：访问 https://ipleak.net 或 https://browserleaks.com/ip，检查出口 IP、DNS 服务器、WebRTC 是否全部为代理侧。若发现 IPv6 地址泄漏，说明 IPv6 路由未被劫持；若 DNS 显示本地 ISP，说明 dns-hijack 失效。最严格的验证是抓包：tcpdump -i utun0（macOS）或 Wireshark 抓 TUN 网卡，确认所有出站包都经过虚拟接口。任何一层不通过，都意味着存在泄漏路径。