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

先确认是否需要 TUN 模式

先用系统代理验证节点和配置，再开启 TUN。浏览器已经能正常访问，但命令行、游戏或不读取系统代理的应用仍然直连时，才需要考虑由虚拟网卡接管流量。TUN 不会修复失效节点，也不会把不支持 UDP 转发的节点变成可用的 UDP 出口。

TUN 是操作系统提供的三层虚拟网络接口。应用发出的 IP 数据包被路由到该接口后，内核读取数据包、识别连接，再按规则选择直连或代理。它与只处理部分应用代理请求的系统代理处于不同层次。

检查项目	系统代理	TUN 模式
接管入口	应用读取系统的 HTTP 等代理设置	操作系统路由把 IP 数据包送入虚拟网卡
常见应用	浏览器及遵循系统代理的应用	不支持代理设置的应用、部分游戏与终端工具
UDP 流量	普通 HTTP 系统代理通常不覆盖	可处理，但仍取决于节点协议和远端能力
权限要求	通常只需修改用户级代理设置	桌面端通常需要服务权限、管理员权限或网络管理能力
常见故障点	代理端口错误、应用忽略系统设置	路由冲突、DNS 异常、权限不足、其他 VPN 干扰

开启前检查内核、配置与权限

优先使用明确提供 TUN 设置、且仍在维护的客户端。下面的 YAML 字段以 mihomo 为例；旧版 Clash、不同分支内核及移动端客户端的字段支持并不完全一致。先在客户端“关于”或内核信息页确认实际运行的内核，不要仅凭应用名称判断兼容性。

保留可用配置。导出当前配置，记录系统代理端口、当前模式和所选策略。订阅更新可能覆盖直接写入订阅文件的修改，优先使用客户端提供的覆写或合并配置功能。
验证节点。先开启系统代理并打开一个实际需要代理访问的网页。仅看到延迟测试返回毫秒数，还不足以证明目标网站和 UDP 业务都可用。
暂停其他接管工具。暂时断开其他 VPN、游戏加速器和另一套 TUN 客户端。企业设备上的安全软件或 VPN 应按管理要求处理，不要擅自移除。
确认本地访问。记下路由器、NAS、打印机的地址，例如 192.168.1.1。开启后要复测这些目标，避免只验证外网。

系统代理端口和 DNS 监听端口不是同一个用途。例如混合代理端口可以设为 7890，DNS 可以监听 127.0.0.1:1053。实际值以当前生效配置为准；不要把代理端口填入系统 DNS 地址。

分平台开启虚拟网卡

Windows：先安装服务，再打开 TUN

在使用 mihomo 的桌面客户端中，先进入“设置”，查找“服务模式”或“服务管理”，完成安装并确认服务正在运行。安装服务时通常会出现 Windows 用户账户控制提示。随后回到首页或代理设置，打开“TUN 模式”或“虚拟网卡模式”。具体入口名称以当前客户端界面为准。

先保持“规则模式”，选择已经验证可用的策略。
启用服务模式，再启用 TUN；如果客户端提供“自动路由”与“自动检测出口网卡”，先使用默认启用状态。
检查日志是否出现权限拒绝、网卡创建失败或路由添加失败。开关显示开启，但日志报错，不能算接管成功。
关闭系统代理，重新建立应用连接，测试浏览器、终端及局域网访问。

客户端没有服务模式时，可能要求以管理员身份运行；应先阅读该客户端的权限说明。不要同时启动普通权限和管理员权限的两个客户端实例，否则容易发生端口占用与路由竞争。

macOS：完成辅助程序或网络权限授权

进入客户端的 TUN 或网络设置，按提示安装特权辅助程序、输入管理员密码，或批准系统要求的网络相关权限。不同客户端可能使用不同实现，只有系统实际弹出对应授权时才需要批准，不必手动安装来历不明的扩展。

开启后用 ifconfig 检查网络接口，再结合客户端日志确认创建结果。macOS 上的 utun 接口也可能由系统服务或其他 VPN 创建，单独看到 utun0、utun1 并不能证明当前 Clash 的 TUN 已经正常工作。

Linux：确认 TUN 设备和网络管理权限

先检查系统是否提供 /dev/net/tun。内核需要具备创建虚拟网卡、修改路由所需的权限；图形客户端通常通过辅助服务获取权限，命令行部署则需要正确的服务权限配置。仅给普通用户配置文件的读写权限，不能解决路由操作被拒绝的问题。

test -c /dev/net/tun && echo "TUN 设备存在"
ip link show
ip rule show
ip route show table all
ip route get 1.1.1.1

这些命令用于读取状态，不会修改网络。若在 Docker、LXC 或受限 VPS 中运行，还需要宿主环境允许使用 TUN 设备并授予所需网络能力；容器内的 root 身份并不自动具备宿主机网络管理权限。远程服务器修改默认路由前，应准备控制台等带外恢复入口。

Android 与 iOS：使用系统 VPN 授权入口

Android 上支持相应功能的客户端通常通过系统 VPN 服务接管流量，首次连接会出现 VPN 连接请求，一般不需要 root。若启用了分应用代理，只有选中的应用会进入接管范围。系统通常只允许一个普通 VPN 服务处于活动状态，连接另一款 VPN 可能使当前客户端断开。

iOS 应使用客户端提供的 VPN 配置与连接入口，按系统提示添加配置。桌面端的服务安装步骤不适用于 iOS，也不应直接套用桌面端完整 TUN YAML。移动端还应检查按应用排除、局域网访问和后台运行设置。

配置 mihomo TUN 与 DNS 劫持

先合并字段，再重新加载配置。下面是已有可用节点、策略组和规则时的配置节选，不是能够独立使用的完整订阅。相同顶层字段只保留一份，尤其不要重复添加两个 dns: 或两个 tun:。

mixed-port: 7890
mode: rule

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

理解三个关键开关

auto-route：让内核自动设置接管所需路由。关闭后通常需要自行维护路由，不适合初次排查时随意切换。
auto-detect-interface：自动识别对外连接使用的网卡，帮助代理出站避开接管回环。多网卡、其他 VPN 或特殊路由环境仍需检查实际出口。
dns-hijack：把进入 TUN 的指定 DNS 流量交给内置 DNS 处理。示例覆盖常规 UDP 53 和 TCP 53；它不会自动解密或接管所有应用内置的 DoH、DoT。

stack: system 指定使用系统协议栈方案。mihomo 也提供其他协议栈选择，但实际支持与行为取决于内核版本和平台。先用客户端推荐默认值；遇到兼容问题时再单独切换协议栈并复测，避免同时改变路由、DNS 和 MTU。

区分 Fake-IP 地址和真实出口地址

Fake-IP 模式会为域名分配用于内部映射的地址，例如 198.18.0.1/16 范围内的地址。内核借助映射恢复域名信息并执行规则，因此解析结果落在该网段，不等于网站服务器真的位于这个网段，也不等于解析失败。

上例使用两个 IPv4 DNS 上游便于说明配置结构，实际网络应选用可达、符合分流需求的解析方案。dns.ipv6: false 用于限制该 DNS 模块返回 AAAA 记录，不等于关闭操作系统 IPv6，也不保证所有 IPv6 流量都已被接管。应用自己的加密 DNS、缓存和硬编码 IP 仍可能走不同路径。

确认流量确实经过 TUN

关闭系统代理后再测试，才能把两条接管路径区分开。若终端之前设置了 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，测试时也要避开这些变量；否则请求成功只能说明显式代理可用。

curl --noproxy "*" -I --connect-timeout 10 https://example.com

在 Windows PowerShell 中可使用 curl.exe 调用实际的 curl 程序。这里的 --noproxy "*" 用于绕开 curl 的显式代理设置，并不能绕开操作系统的 TUN 路由，因此适合配合客户端连接面板观察接管情况。示例网站只用于基础 HTTPS 检查，还应换成实际使用的目标复测。

查看连接面板。找到刚建立的连接，核对目标域名或 IP、命中规则以及最终策略。
验证直连目标。访问路由器或 NAS，确认局域网连接正常，且没有误走远端节点。
验证代理目标。检查实际需要代理的应用，确认命中的策略与预期一致。
单独测试 UDP。使用实际语音、游戏或其他 UDP 业务验证；HTTP 请求成功和节点延迟正常都不能代替 UDP 测试。

切换模式后要重建连接。浏览器的长连接、游戏会话或下载任务可能继续使用旧连接；只切换开关而不重新发起请求，容易把缓存结果误判为当前状态。

排查开启 TUN 后无法联网

先判断故障发生在哪一层

现象	优先检查	下一步操作
开关开启后全部断网	内核日志、服务权限、其他 VPN、出口网卡	关闭 TUN 恢复网络，再逐项排除路由竞争
域名连接失败，已有 IP 连接仍可用	DNS 上游可达性、劫持配置、应用内置 DNS	查看 DNS 错误，暂时简化解析配置后复测
网页可用，游戏或语音失败	节点 UDP 能力、规则命中、远端限制	使用确认支持 UDP 的出口，并重建业务连接
外网可用，NAS 或打印机不可用	局域网路由、内部域名解析、直连规则	先用局域网 IP 测试，再检查内部 DNS
换 Wi-Fi 后失效	旧出口网卡、路由与 DNS 状态	重新连接客户端，核对新的默认出口
小请求正常，大页面卡住	MTU、路径分片、节点连接质量	保留其他设置，仅调整 MTU 做对照测试

按权限、路由、DNS、策略的顺序检查

先读日志。出现 permission denied 或类似操作被拒绝的提示时，优先解决服务权限；出现端口占用时，检查是否重复运行内核。此时反复更换节点通常不会解决问题。

再看出口和路由。TUN 把应用流量送入内核，但内核连接代理服务器时必须仍能到达物理网络。如果代理出站又被送回 TUN，可能形成回环。多网卡设备应检查实际默认出口，必要时按当前内核文档指定出站网卡，不要直接删除系统全部路由。

随后验证 DNS。可使用 nslookup example.com 查看解析结果，但要结合命令显示的 DNS 服务器与内核日志判断。Fake-IP 返回内部映射地址属于预期行为；超时、拒绝连接、上游不可达才是需要继续定位的线索。浏览器启用安全 DNS 时，还应单独对比系统解析与浏览器解析。

最后检查命中规则和策略。规则模式下直连规则放得过宽，可能使目标绕过代理；选中的策略组也可能仍指向 DIRECT。临时切换到已知可用策略做对照有助于定位，但排查后应恢复原有分流，并核对新连接实际命中的规则。

仅在症状吻合时调整 MTU

只有出现连接已建立但较大数据传输卡住、部分网络稳定复现等现象时，才考虑 MTU。可以记录当前值，再临时测试 mtu: 1400，必要时测试 1280，每次只改一项。这些值是排查用的候选值，不是所有宽带、移动网络或隧道环境的统一最佳值。

关闭 TUN 与恢复网络

先在客户端关闭 TUN，再正常退出客户端，让内核清理自动路由。若之前同时开启了系统代理，还要单独关闭系统代理；TUN 开关关闭，不代表系统代理设置也已恢复。

检查是否还有另一套代理客户端或 VPN 正在运行。
将手动填写的系统 DNS 恢复到原有配置；若原先自动获取，恢复为自动获取。
网络仍异常时，先重新连接 Wi-Fi 或有线网络，再检查默认路由，必要时重启系统。
远程设备优先使用预先准备的控制台恢复，不要盲目执行清空路由或重置防火墙的命令。

重新开启时，保持“可用节点、规则模式、单个 TUN 客户端”的最小组合。依次恢复自定义 DNS、分应用排除和其他网络工具，每恢复一项就测试一次。这样可以明确是哪项配置改变了结果，而不是反复重装客户端。