Clash TUN 模式开启教程：虚拟网卡接管全局流量的原理与各平台设置

TUN 与系统代理：接管入口不同

Clash TUN 模式通过虚拟网络接口接收 IP 数据包，再交给内核解析、匹配规则并建立出站连接。系统代理则向应用提供 HTTP 或 SOCKS 代理入口，需要应用主动遵守代理设置。因此，浏览器能联网而命令行工具、游戏或部分桌面软件没有走代理时，问题可能出在接管入口，而不是节点本身。

本文配置面向 Clash Meta 后续演进的 mihomo 内核。名称带有 Clash 的客户端不一定使用同一种内核；旧版 Clash、旧版 Premium 与 mihomo 的配置能力也不能直接等同。开始前先在客户端的内核信息或启动日志里确认正在运行 mihomo，并以当前内核对配置字段的支持情况为准。

检查项	系统代理	TUN 模式
接管位置	应用的代理接口	系统路由与虚拟网络接口
应用要求	需要遵守系统代理或单独配置	进入对应路由的流量可被接管
UDP 流量	常规 HTTP 系统代理无法统一覆盖	可接管，代理出站仍需支持 UDP
权限要求	通常不需要创建网卡的权限	通常需要管理员、特权服务或网络能力授权
分流依据	由内核规则决定	仍由内核规则决定

开启前检查：节点、权限与配置持久化

验证基础连接。先使用系统代理访问一个已知可用的网站，确认订阅已导入、策略组已有可用节点。TUN 不能修复过期订阅、节点认证失败或服务器离线。
备份生效配置。记录当前模式、DNS 设置和原有路由。客户端可能用订阅内容生成运行配置，直接修改生成文件会在更新后丢失；应使用客户端提供的覆写、合并或持久化配置入口。
暂停其他接管工具。先退出其他 VPN、加速器和虚拟网卡代理，减少默认路由、DNS 和防火墙规则的冲突。排查完成后再逐个恢复。
保留本地操作通道。远程桌面或 SSH 会话可能因路由修改中断。首次开启应在设备本地操作，不要在唯一的远程连接中直接试改路由。

菜单名称随客户端变化。应确认三个实际状态：特权服务可用、TUN 开关开启、运行配置中存在正确的 tun 段。仅看到界面开关变亮，不能证明虚拟网卡已经创建成功。

mihomo TUN 配置：stack、路由与 DNS

下面是一段可合并到现有 mihomo 配置的示例，不是包含节点和策略组的完整订阅。它保留现有代理与规则，只展示接管入口和 DNS。已有顶层 dns 或 tun 时，应合并字段，不要重复声明同名键。

mode: rule

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

stack：先用 mixed，再按故障切换

mihomo 提供 system、gvisor、mixed 等 TUN 协议栈选项。mixed 将 TCP 交给 system 栈、UDP 交给 gVisor 栈，是一个明确的起点。不同系统与内核构建的兼容表现可能不同；遇到连接异常时，每次只切换一个栈，并用同一个目标复测，不要同时更换节点、DNS 和路由。

切换栈不会改变节点的传输能力。即使本机成功接管 UDP，选中的代理协议或服务器不支持 UDP 转发，游戏语音、QUIC 等连接仍可能失败。此时应检查出站能力，而不是反复安装虚拟网卡。

auto-route：安装路由，不是更改分流规则

auto-route: true 让内核自动设置通往 TUN 的路由。auto-detect-interface: true 用于自动识别出站网络接口，避免代理服务器连接再次进入 TUN 形成回环。在有线、无线和虚拟网卡并存的设备上，自动识别可能受到既有路由影响；如需手动指定出站接口，应先确认真实接口名称，并按当前内核支持的配置方式设置。

dns-hijack：接收传统 DNS，不等于覆盖加密 DNS

any:53 匹配进入 TUN 的 UDP 53 请求，tcp://any:53 对应 TCP 53。它们将匹配流量交给内核 DNS 处理，但不能把浏览器内置的 DoH、应用自建的 DoT 自动还原为普通 DNS。测试阶段可暂时关闭浏览器的“安全 DNS”，先确认系统解析链路。

示例中的 127.0.0.1:1053 是本地 DNS 监听地址，不是系统代理端口，也不要求把网卡 DNS 填成带端口的地址。TUN 劫持与本地监听是不同入口。fake-ip 会返回供内核映射使用的虚拟地址，看到 198.18.0.0/16 范围内的解析结果并不直接代表故障。

Windows：先确认服务权限，再检查虚拟网卡

退出其他 VPN。进入「设置」→「网络和 Internet」→「代理」，记录原有手动代理设置，避免测试时混淆两种接管入口。
在客户端中安装或启用其提供的服务模式，按 Windows 用户账户控制提示授权。没有服务模式时，可按客户端说明临时以管理员身份运行，用于确认是否为权限问题。
启用 TUN，保持规则模式，观察日志中是否出现创建接口或配置路由失败。不要从未知来源单独下载网卡驱动替换客户端配套组件。
在客户端内关闭系统代理，再运行下方命令查看接口和路由，并测试实际联网。测试结束后按需要恢复系统代理。

Get-NetAdapter -IncludeHidden |
  Format-Table Name, InterfaceDescription, Status

Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Format-Table DestinationPrefix, InterfaceAlias, NextHop, RouteMetric

Resolve-DnsName example.com
curl.exe --noproxy "*" -I https://example.com

上述命令在 PowerShell 中执行。--noproxy "*" 让 curl 忽略应用层代理设置，但不会绕过系统路由，因此适合辅助检查 TUN。网卡名称取决于客户端配置，不应以是否出现某一个固定名称作为唯一标准。应同时核对内核连接记录中是否出现这次访问。

如果日志报告访问被拒绝，先处理服务权限；如果接口存在但没有请求进入内核，再检查路由、其他 VPN 和安全软件的拦截记录。不要把关闭整个防火墙当作长期解决方案。

macOS：授权辅助服务，识别 utun 接口

macOS 创建 TUN 接口和调整路由需要相应权限。桌面客户端通常通过特权辅助服务完成；按应用提示安装或授权，并在系统提示要求时进入「系统设置」→「隐私与安全性」核对。不同分发方式使用的授权机制不同，不要因为系统中没有某个固定开关就判断安装失败。

先在普通代理模式验证节点，然后启用客户端提供的特权辅助服务与 TUN。
为单独验证 TUN，可在「系统设置」→「网络」→ 当前网络连接 →「详细信息」→「代理」中检查 HTTP、HTTPS 和 SOCKS 代理状态。
使用终端查看接口、路由与 DNS；通过内核连接记录确认测试请求的规则和出站。

ifconfig
netstat -rn -f inet
scutil --dns
curl --noproxy '*' -I https://example.com

utun 接口也可能由系统功能或其他 VPN 创建，单看接口数量无法判断 Clash TUN 是否工作。应对比开启前后的路由变化与日志时间。macOS 具有按接口和域名分配的解析器，scutil --dns 比只查看 /etc/resolv.conf 更适合排查系统 DNS 状态。

Linux：检查 /dev/net/tun 与服务身份

Linux 上需要可用的 TUN 设备，以及创建接口、修改路由所需的权限。通常涉及 CAP_NET_ADMIN，具体要求还受内核功能、服务沙箱与运行环境影响。桌面客户端可通过配套服务执行这些操作；直接运行 mihomo 时，应使用已审阅的服务配置，而不是随意给未知二进制添加权限。

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

resolvectl 适用于使用 systemd-resolved 的系统；其他发行版应检查实际使用的解析服务。若已安装名为 mihomo.service 的 systemd 单元，可用以下命令查看服务状态和本次启动日志；单元名称不同则以安装时使用的名称为准。

systemctl status mihomo.service
journalctl -u mihomo.service -b --no-pager -n 100

检查路由时不要只看主路由表。自动路由可能配合策略路由使用，因此需要同时读取 ip rule show 和所有路由表。容器中的 root 也不等于宿主机完整权限；容器还需要正确暴露 TUN 设备并配置所需能力，不应以直接启用特权容器代替权限分析。

验证步骤：接管、规则与出口分别确认

确认接管。关闭系统代理，执行前述 curl 请求，查看内核连接记录。能看到目标域名或目标 IP，说明请求已进入内核；仅网页能打开还不足以判断。
确认规则。分别访问预期直连和预期代理的服务，记录命中的规则、策略组和最终节点。TUN 工作正常但命中 DIRECT，属于分流结果，不是接管失败。
确认 DNS。执行系统解析测试，再进行 DNS 泄漏检测。检测站显示的是递归解析出口，不必与代理出口 IP 相同；应判断它是否符合预先设定的 DNS 路径。
确认 IPv6。若系统启用 IPv6，分别检查 IPv4 与 IPv6 的访问结果及内核记录。只验证 IPv4 不能代表双栈流量都已接管。
确认 UDP。使用实际需要的游戏、语音或支持 HTTP/3 的应用复测，并核对节点 UDP 能力。普通网页的 TCP 请求成功不能证明 UDP 正常。

建议记录“开启前、开启后、关闭后”三组结果，包括系统代理状态、命中规则、DNS 上游和错误日志。延迟受节点、目标站点、网络路径和缓存影响，不能用一次测速数值推断 TUN 比系统代理更快。

常见故障与安全回退

现象	优先检查	处理方向
启用后立即断网	接口权限、路由回环、上游 DNS 可达性	关闭 TUN 恢复网络，再逐项查看启动日志
域名失败，IP 可连	内核 DNS、53 端口劫持、应用加密 DNS	单独验证解析链路，避免同时更改节点
浏览器正常，游戏异常	UDP 出站、节点能力、目标规则	核对 UDP 连接记录与服务端支持
局域网设备无法访问	私网路由、目标地址、域名映射	按具体网段设置路由排除或直连规则
切换 Wi-Fi 后异常	出站接口识别、旧路由、网络变化日志	网络稳定后重启内核并重新检查路由

局域网直连与绕过接管是两件事

将某个私网地址匹配到 DIRECT，只代表流量进入内核后直接出站；把该网段排除在 TUN 路由之外，则代表流量不经过内核。这两种方式的日志可见性与 DNS 行为不同。打印机、NAS 或公司内网异常时，先确定目标的真实地址和网段，不要为解决一个设备的问题直接排除整个未知地址范围。

关闭后的恢复顺序

先关闭 TUN，等待客户端撤销接口和路由，再恢复原来的系统代理与 DNS 设置。若仍无法联网，正常退出客户端并检查残留代理、路由及其他 VPN 状态；不要直接清空全部路由表。若更换 DNS 或 fake-ip 设置后仍命中旧地址，可在确认配置正确后刷新系统 DNS 缓存，并重启相关应用。

最终应保留一份已验证可工作的配置：明确内核类型、TUN 栈、DNS 上游、出站接口选择和必要的局域网例外。后续订阅更新只应改变预期内容；每次修改接管或 DNS 参数后，都按相同顺序重测，才能区分配置问题、节点问题与系统网络变化。