Clash TUN 模式开启教程:虚拟网卡接管全局流量的原理与步骤

TUN 与系统代理：接管入口不同，分流规则仍然有效

浏览器能访问目标网站，终端、游戏或某个桌面程序却不能连接，常见原因是这些程序没有使用系统代理。系统代理主要向应用提供 HTTP 或 SOCKS 代理入口；应用是否读取这项设置，由应用自身决定。TUN 则创建虚拟网卡，借助路由将 IP 数据包交给代理内核处理，不要求每个应用都支持代理设置。

这里的“全局流量接管”描述的是入口范围，不等于所有连接都走代理节点。使用 mode: rule 时，进入 TUN 的连接仍会匹配 rules，可以分别交给 DIRECT、代理策略组或 REJECT。局域网、排除路由、其他 VPN 和 IPv6 路径，也可能影响实际接管范围。

对比项	系统代理	TUN 模式
流量入口	应用连接本地代理端口	系统路由导向虚拟网卡
应用配合	应用需要支持并使用代理	通常不需要单独填写代理地址
UDP 流量	受应用和代理协议支持情况限制	可交给内核处理，出站节点仍需支持 UDP
权限要求	通常只需修改用户代理设置	需要创建网卡、修改路由的系统权限
分流方式	进入内核后按当前模式处理	进入内核后同样按当前模式处理

开启前检查：节点、权限与配置覆盖

先用系统代理验证订阅和节点可用，再开启 TUN。这样出现故障时，可以把问题缩小到虚拟网卡、路由和 DNS，而不是同时怀疑订阅内容与节点连通性。建议记录当前模式、策略组选择和 DNS 配置，并保留一份能够正常连接的配置备份。

确认基础连接：使用规则模式，选择已知可用节点，打开一个需要代理的网站。节点延迟测试成功只说明测试目标可达，不能代替实际网页访问。
确认内核权限：桌面端检查服务模式或辅助服务状态；Android 检查 VPN 授权。普通用户启动的内核不一定能创建虚拟网卡。
暂时退出其他 VPN：企业 VPN、游戏加速器和另一个 TUN 客户端都可能写入路由。先建立单客户端基线，再测试共存。
确定编辑位置：优先使用客户端提供的覆写配置或合并配置。直接修改订阅缓存文件，可能在下一次更新时被覆盖。
检查实际生效配置：界面开关可能重写 tun.enable、stack 或 DNS 设置。保存后检查运行配置，而不仅是编辑器里的文本。

本地代理端口与 TUN 是两条入口。示例中的 mixed-port: 7890 供应用连接 HTTP/SOCKS 代理；DNS 监听端口 1053 供 DNS 服务使用。修改 7890 并不能解决虚拟网卡创建失败，也不要把 DNS 监听端口填写到浏览器代理栏。

Windows、macOS、Linux 与 Android 的开启步骤

Windows：先运行服务，再启用 TUN

以 Clash Verge Rev 的常见界面为例，进入「设置」→「服务模式」，按提示安装服务并确认系统授权；服务运行后再打开「TUN 模式」。不同版本可能将相关选项放在设置卡片中，名称和分组会变化，重点是确认服务已运行，而不是只看到开关处于开启状态。

开启后到 Windows「设置」→「网络和 Internet」→「高级网络设置」检查适配器，或运行下面的 PowerShell 命令。虚拟网卡名称可由配置指定，不一定含有 Clash 字样。网卡存在只是第一步，还需要查看日志中的路由和 DNS 初始化是否成功。

Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
route print

如果日志出现权限不足或设备创建失败，先重新检查服务安装状态；管理员启动可用于诊断，但日常使用更适合通过客户端支持的服务机制运行内核。防火墙处理应针对具体程序或服务授权，不建议长期关闭整个系统防火墙。

macOS：确认辅助服务和网络权限

选择支持 mihomo TUN 的客户端，按其设置页提示安装辅助服务，再启用 TUN。出现系统授权提示时核对程序来源并完成授权。如果服务安装成功但开关无法保持开启，查看客户端日志以及「系统设置」→「网络」中的网络服务状态；部分权限提示也会出现在「系统设置」→「隐私与安全性」。

ifconfig
netstat -rn -f inet
route -n get 1.1.1.1

macOS 上常见的虚拟接口名称是 utun 加数字，但系统或其他 VPN 也会创建这类接口。不能根据出现一个 utun 就断定当前客户端已接管流量，应结合启动日志和目标地址的路由判断。

Linux：检查 TUN 设备和服务权限

Linux 通常需要可用的 /dev/net/tun，以及创建接口和修改路由所需的权限。发行版软件包、桌面客户端和独立内核服务的授权方式不同，应使用对应项目的服务安装说明。容器中还需要额外的设备映射和网络权限，不能按普通桌面流程直接推断。

ls -l /dev/net/tun
ip link show
ip rule show
ip route show table all

检查路由时同时看策略路由和所有路由表。有些实现不会简单替换主表中的默认路由，只运行 ip route 可能漏掉实际接管路径。不要为省步骤把长期服务统一改为最高权限运行。

Android 与 iOS：先区分平台接管方式

Android 图形客户端通常通过系统 VPN 接口接管流量，首次连接会请求 VPN 授权。以支持 mihomo 的客户端为例，导入配置后启用其 VPN/TUN 运行方式，再确认系统状态栏的 VPN 标识。Android 普通用户通常只能同时使用一个 VPN 服务，另一款 VPN 启动后可能中断当前连接。

如果只有部分应用无法连接，检查客户端的应用访问控制或分应用代理设置，被排除的应用可能不进入接管范围。iOS 客户端多通过 Network Extension 提供接管功能，配置格式和可用字段由具体客户端决定；不要把桌面 mihomo 的 YAML 片段原样当成所有 iOS 客户端的开启方法。

TUN 配置片段：stack、auto-route 与 DNS 劫持

下面是用于已有 mihomo 配置的顶层合并片段，不是完整配置。它没有节点、订阅提供器、策略组和规则，需要保留原配置中的这些部分。若原文件已有 dns 或 tun，应合并字段，不能再复制一个同名顶层键。

mode: rule
mixed-port: 7890

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.cloudflare.com/dns-query

字段	示例值	用途与注意点
`enable`	`true`	请求启用 TUN，仍依赖系统权限。
`stack`	`mixed`	TCP 使用 system 栈，UDP 使用 gVisor 栈。
`auto-route`	`true`	自动设置接管所需路由，不代表全部连接选择代理节点。
`auto-detect-interface`	`true`	自动检测出站接口，多网卡或多 VPN 时需核对结果。
`dns-hijack`	`any:53`	接管进入 TUN 的 UDP 53 请求，交给内置 DNS。
`enhanced-mode`	`fake-ip`	以映射地址关联域名和后续连接。

stack 如何选择

system：使用系统网络栈。适合作为兼容性测试选项，表现受操作系统和具体环境影响。
gvisor：使用用户态网络栈。遇到特定系统栈问题时可以对照测试，但不能承诺所有设备上速度更快。
mixed：结合 system 的 TCP 与 gVisor 的 UDP 处理方式，可作为起点，再根据日志与应用表现调整。

一次只更改一个字段，并在重新连接后测试同一应用。游戏语音失败时，还要检查节点协议、服务端和出口网络是否支持 UDP；更换 stack 无法补足出站节点缺少的能力。

default-nameserver 用于解析 DNS 上游的域名，proxy-server-nameserver 用于代理服务器域名解析。示例将这两类解析单独列出，是为了减少启动时的解析依赖环；实际应选择当前网络可达、符合自身隐私要求的解析器。DoH 上游的 HTTPS 连接是否经过代理，还取决于 DNS 路由相关配置，不能仅凭 URL 中有 https 判断出口位置。

开启后验证：分别检查流量入口、规则与 DNS

测试时暂时关闭系统代理，保留 TUN 开启，避免浏览器仍通过本地端口访问而掩盖接管失败。也要清除测试程序自身的代理设置。先测试普通网页，再测试原本不读取系统代理的程序，并在客户端「连接」或「日志」页面观察对应目标。

确认进入内核：发起一个新的连接，查看连接页面是否出现目标域名或 IP。浏览器复用旧连接时可能不会立即产生新记录，可关闭页面后重试。
确认规则命中：查看匹配规则和最终策略。大陆站点命中直连、境外服务命中代理组，与 TUN 接管并不冲突。
确认域名解析：在客户端提供 DNS 查询功能时优先使用该功能。也可对本地 DNS 监听端口发起查询，验证内置 DNS 是否响应。
确认 UDP：用实际语音、游戏或其他 UDP 应用检查，不要把一次 HTTP 网页访问当作 UDP 成功的证据。

# macOS / Linux：测试示例中的本地 DNS 监听端口
dig @127.0.0.1 -p 1053 example.com A

# 查看域名访问是否成功
curl -I https://example.com

若使用 Fake-IP，查询得到 198.18.0.0/16 范围内的地址可能是预期映射结果，不能直接当成解析错误。域名在过滤列表中时也可能返回真实地址。不要用“映射地址能否被 ping 通”作为网页访问的唯一判断标准。

公开 IP 或 DNS 检测网页只能反映它们所观察到的请求。出口地址符合预期，并不能证明所有应用、所有 DNS 和 IPv6 都已接管。需要同时核对应用记录、规则命中与系统路由。

TUN 开启后无法联网：按顺序定位故障

第一步：关闭 TUN，确认基础网络仍可用

如果关闭 TUN 后也无法联网，先处理 Wi-Fi、网关、订阅或节点问题。若关闭后立刻恢复，则保留当前配置备份，集中查看 TUN 启动日志中的权限、接口、路由和 DNS 错误。临时把日志等级设为 log-level: debug，复现一次后恢复常用等级，避免长期记录过多连接信息。

第二步：检查网卡创建与路由出口

日志中出现 permission denied、operation not permitted 等信息，通常应回到服务权限检查。多网卡环境则检查自动检测的出站接口：它应指向真实联网接口，而不是另一个 VPN 或当前虚拟网卡。只有确认自动检测选错后，再按当前内核支持的方式指定出口接口。

第三步：区分 DNS 故障与连接故障

若内置 DNS 查询超时，检查 dns.enable、1053 端口占用、上游 DNS 可达性和配置是否生效。若查询成功但网站连接失败，再查看代理节点、规则和 TLS 连接日志。简单比较“IP 能打开、域名打不开”只能提供线索，因为很多网站需要正确的 Host 和 TLS SNI，直接访问 IP 也可能正常失败。

第四步：排除 VPN、IPv6 与特殊路由冲突

退出其他 VPN 后重新测试；若问题只在 IPv6 连接出现，检查 IPv6 DNS 返回、系统路由和节点出口支持是否一致。临时限制 IPv6 可以用于定位，但应把它记录为诊断措施，而不是不加说明的长期修复。公司内网或局域网设备不可达时，检查相应网段是否被接管，以及既有规则是否选择直连。

第五步：最后调整 stack 与 MTU

若连接能建立，但大文件传输停顿、部分网页长期加载或特定 UDP 应用异常，再分别测试不同 stack。怀疑路径 MTU 时，可在原配置基础上测试 tun.mtu: 1400，记录是否改善；1400 是排查起点，不是所有网络的最佳值。不要同时修改 DNS、MTU、规则与节点，否则无法确定是哪项变化解决了问题。

恢复连接与日常使用：保留一条可验证的回退路径

需要回退时，先关闭 TUN，确认内核完成退出或重新加载，再按需启用系统代理。正常退出通常会清理自动创建的路由；若客户端异常终止后网络没有恢复，先重启对应服务或客户端，再检查残留接口和路由。不熟悉路由表时，不要批量删除系统路由。

只需要浏览器代理：系统代理通常足够，配置范围较小，排查也更直接。
需要接管终端或桌面程序：TUN 更适合，但要确认权限、DNS 与规则三部分都正常。
需要游戏或语音：除 TUN 外，还要验证节点 UDP 能力、出口网络和实际应用连接。
经常连接企业 VPN：分别测试启动顺序、出站接口和局域网访问，不把一次成功当成永久兼容。

完成配置后，保留客户端名称、内核信息、系统版本、启用字段与复现步骤。更换客户端或更新订阅后，重新检查运行配置是否保留覆写。关于代理入口和常用字段，可继续查看使用教程；关于端口与配置结构，可对照进阶手册的端口说明。