TUN 模式的流量接管原理

普通的系统代理模式依赖操作系统向应用公布 HTTP 或 SOCKS 代理地址。浏览器、部分下载工具和遵循系统网络设置的软件会主动把连接交给 Clash，但游戏客户端、命令行程序、独立更新器以及自行实现网络栈的应用可能直接访问目标地址。此时即使客户端界面显示“系统代理已开启”，这些连接仍可能绕过代理端口。

TUN 模式会创建一张虚拟网络接口，并配合路由规则把指定流量送入该接口。Clash 内核从虚拟接口读取 IP 数据包，还原连接目标，再按照配置文件中的代理规则选择 DIRECT、REJECT 或某个代理策略。返回数据经过同一链路交还应用，因此应用通常不需要知道本地代理端口，也不需要单独支持 HTTP 或 SOCKS 协议。

这里的“全局流量接管”描述的是流量进入 Clash 的范围，不等于代理模式中的 GLOBAL。启用 TUN 后仍可使用 Rule 规则模式：局域网地址走直连、特定域名走代理、广告域名拒绝，其余连接按兜底规则处理。只有将运行模式切换为 Global，才会让可处理的连接统一使用所选代理策略。

TUN 主要处理三层 IP 流量。域名匹配还依赖 DNS 解析结果与内核的域名映射机制；UDP、QUIC、IPv6 能否完整工作，则与客户端所用内核、节点协议、系统权限和配置内容有关。现代 mihomo 内核通常提供较完整的 TUN 能力，但不同桌面客户端对配置项的暴露方式并不相同。

开启 TUN 前的检查项目

先确认当前订阅能够正常使用。选择一个可用节点，在仅开启系统代理的状态下访问网页，并检查规则列表是否能命中预期策略。如果订阅本身解析失败、节点不可达或规则配置错误，开启 TUN 只会扩大故障范围，不会修复基础连接问题。

  1. 确认客户端内核：查看客户端的内核信息或关于页面。较新的 mihomo 内核支持 TUN、自动路由和 DNS 劫持等参数；较早的 Clash 内核或精简客户端可能缺少部分选项。
  2. 保留当前配置：导出正在使用的配置文件，或记录订阅名称、代理模式和 DNS 设置。修改 YAML 时要保持空格缩进一致，不能使用制表符代替缩进。
  3. 检查权限方式：Windows 常通过服务模式或管理员权限操作虚拟网卡，macOS 可能要求管理员授权，Linux 通常需要 root 权限或为进程授予网络管理能力。
  4. 退出其他 VPN：同一系统中同时运行多个虚拟网卡工具，容易发生默认路由、DNS 和防火墙规则竞争。移动平台通常还限制同一时间只能启用一个系统 VPN 通道。
  5. 记录局域网环境：如果需要访问打印机、NAS、开发设备或公司内网，应记录其地址段，启用后重点验证这些直连资源。

mihomo TUN 配置参数

多数图形客户端会提供一个 TUN 开关，并自动生成基础参数。需要手动维护 YAML 时，可以从较小的配置开始，再根据系统情况增加严格路由、MTU 等选项。下面展示的是常见结构，实际可用字段应以客户端所集成的内核版本为准。

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

enable 与 stack

enable 控制 TUN 功能是否启动。stack 决定内核处理网络数据的方式，mihomo 常见值包括 system、gvisor 和 mixed。系统栈通常性能直接，gVisor 用户态网络栈在部分环境中兼容性更合适，mixed 则组合处理 TCP 与 UDP。客户端已经提供推荐值时，优先保留客户端默认设置；遇到特定应用无法联网或 UDP 异常，再逐项切换并测试。

auto-route 与 auto-detect-interface

auto-route 让内核自动添加必要路由，把系统流量引向虚拟接口。auto-detect-interface 用于识别真实出口网卡，避免代理服务器连接再次进入 TUN 形成回环。设备在有线、无线和移动热点之间切换后，如果所有连接突然中断，可以先重启 TUN，让内核重新判断出口接口。

dns-hijack 与 DNS 配置

dns-hijack 中的 any:53 用于接管传统的 53 端口 DNS 查询，使域名解析更容易与 Clash 规则保持一致。它不能直接拦截应用内置的 DoH 或 DoT，因为加密 DNS 使用的端口和协议不同。只配置 DNS 劫持而没有启用内核 DNS 模块，也可能造成查询失败，因此应同时确认配置中的 dns.enable 以及 nameserver、fallback 或策略解析项是否有效。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

fake-ip 模式会为域名返回保留地址段中的映射地址，内核据此保留域名信息并匹配规则。少数局域网设备、游戏登录服务或依赖真实 DNS 返回值的程序可能不适应 fake-ip，可将相关域名加入过滤列表，或根据客户端能力改用其他增强模式。不要随意更改 fake-ip 地址段后又与局域网路由使用相同网段，否则会产生地址冲突。

strict-route 与 MTU

strict-route 会强化路由约束，在部分系统上有助于减少流量绕行，但也更容易暴露公司 VPN、虚拟机网卡和特殊路由之间的冲突。建议先使用客户端默认值，确认基础连接稳定后再开启。MTU 控制单个数据包大小；网页可打开但上传卡住、部分站点持续超时或游戏在登录后断线时，可以测试 1400 至 1500 范围内的值，每次只修改一个参数并重新连接。

Windows、macOS、Linux 与移动平台设置

Windows：服务模式与虚拟网卡

Windows 图形客户端通常把 TUN 放在设置页、服务模式页或主界面的网络开关中。先安装客户端提供的服务组件，再以管理员权限确认安装。服务模式可以让后台服务负责创建虚拟网卡和修改路由，日常启动客户端时不必反复提升整个界面进程的权限。

  1. 关闭正在运行的其他 VPN、游戏加速器和可能接管网络的安全工具。
  2. 在客户端设置中安装或启用 Service Mode、服务模式或系统服务。
  3. 选择 Rule 模式并确认订阅节点可用，然后打开 TUN Mode。
  4. 接受系统权限提示，等待虚拟网卡创建完成。
  5. 依次测试网页、命令行工具、目标应用和局域网资源。

如果开关立即复位，可检查服务是否正在运行，以及客户端日志中是否出现创建接口、写入路由或访问驱动失败的信息。Windows 的 Hyper-V、WSL、虚拟机软件会增加虚拟交换机和网卡，但存在这些组件并不代表一定冲突；应根据路由表和实际出口判断，而不是直接删除所有虚拟适配器。

macOS：授权与 utun 接口

macOS 上的客户端通常通过系统网络扩展或具有权限的辅助进程建立 TUN。首次开启时可能出现管理员密码、VPN 配置或网络扩展授权提示。完成授权后，可在系统网络设置中看到对应的 VPN 状态，终端执行 ifconfig 时也可能出现新的 utun 接口。

如果 TUN 已连接但没有流量，先检查系统中是否仍启用了另一项 VPN，再确认客户端没有把代理服务器自身连接重新送入虚拟接口。使用企业网络配置描述文件的 Mac 可能受到管理员策略限制，此类限制需要在系统管理范围内处理，反复重装客户端通常不能改变策略结果。

Linux：权限、路由与转发

Linux 需要系统提供 /dev/net/tun，并允许进程创建接口和修改路由。以 root 运行可以用于短期验证，但长期部署更适合通过 systemd 服务、容器权限或 capabilities 明确授予所需能力。最小化系统、容器和受限服务器还要确认内核是否启用了 TUN 设备。

ls -l /dev/net/tun
ip addr show
ip route show
ip rule show

这些命令可用于确认设备节点、虚拟接口、默认路由和策略路由。Linux 上常见问题还包括 nftables 与 iptables 规则并存、Docker 网桥地址段重叠、服务器已有策略路由，以及防火墙未允许 TUN 接口流量。排查时应先保存现有网络规则，不要在远程服务器上直接清空防火墙或默认路由，以免失去管理连接。

Android 与 iOS：系统 VPN 通道

移动客户端通常借助 Android VPNService 或 Apple Network Extension 建立本地 VPN 通道，界面中的“VPN”“增强模式”或“TUN”名称可能不同。首次连接需要接受系统 VPN 授权。Android 可根据客户端能力设置分应用代理或排除应用；iOS 和 iPadOS 的具体选项取决于客户端实现与系统权限。

移动系统通常只允许一个普通 VPN 配置处于活动状态，因此 Clash 类客户端与公司 VPN、其他代理工具不能同时占用通道。系统省电策略也可能暂停后台客户端，表现为锁屏一段时间后连接中断。可为客户端保留后台运行权限，并避免同时启用会重复修改 DNS 的网络工具。

如何确认 TUN 已经接管流量

仅观察开关状态不足以判断链路是否完整。可靠的验证方式应同时检查虚拟接口、客户端日志、规则命中和实际应用连接。建议按以下顺序操作：

  1. 查看系统是否出现新的 TUN、utun 或客户端虚拟接口，并确认接口处于启用状态。
  2. 打开客户端连接列表，使用一个原本不遵循系统代理的程序发起请求，观察是否出现对应目标地址或进程记录。
  3. 检查规则命中结果。局域网地址应按 LAN 或私有地址规则直连，目标站点应进入预期策略组。
  4. 暂时关闭系统代理但保留 TUN，再测试浏览器和命令行连接。如果连接仍由客户端记录，说明流量不是仅靠系统代理进入内核。
  5. 分别测试 TCP、UDP、IPv4、IPv6 和 DNS。并非所有节点都支持相同的 UDP 或 IPv6 能力，应把节点限制与 TUN 故障区分开。

Windows 可以使用 route print 或 PowerShell 的 Get-NetAdapter 查看接口，macOS 可用 route -n get default 和 ifconfig，Linux 可使用 ip route 与 ip rule。诊断时应对照开启前后的差异，而不是只看到一条默认路由就判断配置正确。

常见冲突与分步排查

开启后所有应用都无法联网

先关闭 TUN，确认系统网络能够恢复，再检查代理节点本身。随后查看日志中是否出现接口创建失败、默认网卡识别错误、路由回环或 DNS 超时。若设备同时连接有线与无线网络，可暂时只保留一个真实出口，然后重新开启 TUN。手动指定接口应作为自动检测失败后的处理方式，网卡名称改变后还要同步更新。

网页能打开，游戏或语音无法连接

这类情况通常要检查 UDP。确认所选节点和协议支持 UDP，策略组没有选择仅适合 TCP 的链路，并查看客户端是否记录到对应 UDP 会话。若应用使用 QUIC，可以临时禁用应用内 QUIC 进行对照测试，但最终应从节点能力、规则命中和 TUN 栈兼容性定位原因。

开启后无法访问 NAS、打印机或路由器

检查私有地址段是否被错误发送到代理。常见局域网段包括 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16，但企业内网还可能使用其他地址。确保配置允许局域网路由直连，并检查 fake-ip 地址段没有与实际网络重叠。按域名访问失败而按 IP 可访问时，应重点检查本地域名解析与 fake-ip 过滤。

休眠、切换 Wi-Fi 后连接失效

网络恢复后真实出口接口和默认路由可能已经变化，而 TUN 仍保留旧状态。先停止 TUN，等待系统获得新的 IP 与 DNS，再重新开启。频繁发生时，可升级到客户端支持的稳定内核版本，并检查自动检测接口是否启用。移动设备还需要检查后台运行和省电限制。

与 Docker、虚拟机或公司 VPN 冲突

先比较各虚拟网卡使用的地址段和路由优先级。Docker 网桥、虚拟机 NAT、公司 VPN 和 TUN 若声明相同网段，系统可能把流量送往错误接口。处理方向包括调整本地虚拟网段、为公司内网增加明确直连路由、关闭不使用的网络组件，或在不能同时运行的情况下按场景切换。不要同时大范围修改 DNS、路由、MTU 和防火墙，否则很难判断是哪项调整生效。

TUN 模式常见问题

开启 TUN 后还需要开启系统代理吗？

通常不必同时依赖系统代理，因为 TUN 已通过虚拟接口接管符合路由条件的流量。部分客户端会同时开启两者以兼容特定应用，但这不是判断 TUN 是否工作的必要条件。排查时可以关闭系统代理、保留 TUN，再观察连接列表。

TUN 模式会让所有流量都走代理节点吗？

不会自动改变规则模式。TUN 决定流量如何进入 Clash，Rule、Global 和 Direct 决定进入后如何处理。使用 Rule 模式时，连接仍按配置文件自上而下匹配，可以分别走直连、拒绝或代理策略。

为什么开启后客户端显示 TUN 设备创建失败？

常见原因包括系统权限不足、服务组件未安装、TUN 设备不可用、已有 VPN 占用接口，或安全策略阻止修改网络。应先查看日志中的具体错误，再检查服务状态和系统授权，不要只重复点击开关。

system、gvisor 和 mixed 应该选哪个？

优先使用客户端针对当前平台提供的默认值。基础网络正常但特定 TCP、UDP 应用异常时，再切换其他栈进行对照。不同内核版本和操作系统的表现可能不同，不存在适用于所有设备的固定选择。

TUN 模式是否能接管应用内置的加密 DNS？

传统的 53 端口 DNS 可以通过 dns-hijack 接管，但应用内置的 DoH 或 DoT 使用加密连接，不能仅靠 any:53 直接拦截。可在应用中关闭独立安全 DNS，或通过域名规则、策略和系统级管理能力处理。

稳定启用的建议顺序

先保证订阅、节点和 Rule 模式在系统代理下正常，再安装所需服务并开启 TUN。首次测试只保留自动路由、自动识别接口和基础 DNS 配置，确认浏览器、命令行、UDP 应用和局域网资源都能按规则访问。之后再根据实际问题调整 stack、strict-route、MTU 或 fake-ip 过滤项。

TUN 的核心价值是把原本不会主动使用代理的应用连接纳入统一规则处理。稳定性取决于路由、DNS、权限和代理节点共同工作，因此排查时应把“虚拟接口是否建立”“流量是否进入内核”“规则是否命中”“节点是否可传输”分成四层检查。逐层确认比反复切换全部选项更容易找到故障位置。