Clash TUN 模式开启方法：全局流量接管原理与配置步骤

TUN 模式如何接管全局流量

普通的 Clash 系统代理模式主要向操作系统写入 HTTP 或 SOCKS 代理地址。浏览器以及遵循系统代理设置的应用会把连接交给 Clash，但部分游戏、命令行程序、商店客户端和自行实现网络栈的软件可能直接连接目标地址。此时即使系统代理已经开启，这些程序的流量也不一定进入规则引擎。

TUN 模式采用另一条路径。Clash Meta（现常见核心名称为 mihomo）在系统中建立虚拟网络接口，并配合路由规则把符合条件的 IP 流量送入该接口。核心读取数据包的目标信息，再依据配置中的规则、策略组和节点决定直连、代理或拒绝。对应用而言，它仍在发起普通网络连接，不需要单独支持 HTTP 代理。

“全局流量接管”描述的是流量进入核心的范围，不等于所有连接都必须通过同一个代理节点。TUN 负责把流量送入 Clash，最终走向仍由运行模式和规则决定。在规则模式下，局域网地址、国内站点、代理站点和拦截域名可以分别匹配不同策略；在全局模式下，核心通常把可代理流量交给全局策略组；在直连模式下，进入核心的流量也可能被直接放行。

开启 TUN 前的版本、权限与配置检查

首先确认客户端使用的核心支持 TUN。现代 Clash Meta 或 mihomo 核心通常提供较完整的 TUN、自动路由和 DNS 配合能力；较早的 Clash 核心、停止维护的图形客户端或经过裁剪的移动端实现，可能缺少部分字段。配置文件能够成功导入，不代表当前核心一定识别其中所有 TUN 选项，因此需要同时查看客户端的核心名称、核心版本和启动日志。

系统权限

创建虚拟接口、修改路由表和设置 DNS 通常需要提升权限。Windows 客户端可能通过服务模式或管理员权限执行这些操作；macOS 会要求批准网络扩展、VPN 配置或辅助服务；Linux 常涉及 root、CAP_NET_ADMIN、系统服务以及对应的路由权限。权限提示被拒绝后，界面上的 TUN 开关可能看似已经打开，但日志会显示接口创建失败或路由写入失败。

权限应通过客户端提供的服务安装、授权或网络扩展入口完成。反复以管理员身份重启只能帮助判断是否为权限问题，长期使用时更适合采用客户端明确支持的后台服务方案。

订阅与本地覆盖

订阅主要提供节点、策略组和规则，不一定包含适合当前设备的 TUN 配置。有些图形客户端会把 TUN 参数保存在应用设置中，再生成运行时配置；另一些客户端直接读取 YAML 中的 tun 段。手动编辑订阅生成的文件后，下一次更新订阅可能覆盖改动。可靠做法是使用客户端的覆写、混入或配置补丁功能，并保留一份能够正常启动的原配置。

网络环境

• 记录当前使用的 Wi-Fi、有线网络或移动热点，确认未开启其他 VPN。
• 检查本机是否运行虚拟机、容器网络、游戏加速器或企业安全软件。
• 保留当前 DNS 设置，以便出现域名解析故障时恢复。
• 确认订阅中的节点在普通系统代理模式下至少有一个可以连接。
• 关闭配置文件自动更新几分钟，避免排查期间参数被替换。

Clash Meta 与 mihomo 的 TUN 配置步骤

使用图形客户端时，通常可以在网络、服务模式或 TUN 设置页完成开启。建议先安装客户端要求的服务组件，再开启 TUN，随后查看日志中是否出现虚拟接口、路由和 DNS 监听相关记录。若客户端允许选择网络栈，可从兼容性较均衡的选项开始测试，而不是一次修改多个高级参数。

直接维护 mihomo YAML 配置时，可从下面的基础结构开始。不同版本支持的字段和默认值可能变化，最终应以当前核心输出的配置错误与客户端说明为准。

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

基础字段说明

system 倾向使用系统网络栈，通常具有较好的性能与系统协议兼容性；gvisor 使用用户态网络栈，在某些环境中隔离与兼容表现不同；mixed 会按协议采用组合处理方式。哪一种更合适与操作系统、核心版本、UDP 应用和本地安全软件有关。若网页访问正常但游戏语音、UDP 请求或特定程序异常，可以一次只切换一个栈选项，然后重新启动核心比较结果。

按顺序启用

1. 更新到客户端支持的稳定核心，并确认当前配置可以正常载入。
2. 安装或启用客户端所需的系统服务、网络扩展或虚拟网卡组件。
3. 开启 TUN，先使用自动路由与自动识别出口接口。
4. 保持规则模式，选择一个已确认可用的策略节点。
5. 重启核心，查看是否报告配置字段、权限、接口或路由错误。
6. 分别测试浏览器、终端命令和原本不遵循系统代理的应用。
7. 基础连接稳定后，再启用严格路由或调整网络栈。

配置修改后应完整重载核心。仅在文本编辑器里保存 YAML，而客户端仍使用旧的运行时配置，是常见误判来源。可以通过客户端日志中的配置加载时间、核心启动时间和当前工作模式确认新配置是否已经生效。

TUN 模式与 DNS 的配合方式

TUN 接管 IP 数据包，而规则匹配经常依赖域名。应用先查询域名，再连接返回的 IP；如果 DNS 查询绕过 Clash，核心可能只能看到目标 IP，域名规则的匹配能力就会受到影响。更复杂的情况是，本地 DNS 返回了不合适的地址，而代理节点所在网络实际能够解析到另一组结果，最终表现为节点可用但特定网站打不开。

mihomo 的 DNS 模块可以统一处理查询，并与规则分流、Fake-IP 或 Redir-Host 等增强模式配合。以下结构用于说明各部分关系，解析服务器地址应按实际网络与配置来源选择。

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-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

Fake-IP 模式会为域名返回保留地址段中的临时地址，并在核心内部保存域名映射。当应用连接这个临时地址时，核心能够还原原始域名并执行域名规则。这种方式有利于保持规则匹配信息，但少数依赖真实 IP、局域网发现、设备投屏或特殊认证流程的应用可能需要加入过滤列表。过滤项应根据明确故障逐条添加，过大的通配范围会削弱域名映射效果。

dns-hijack 中的 any:53 主要处理传统 53 端口 DNS。应用自带的加密 DNS、浏览器 DoH 或固定外部解析机制未必走相同路径。排查时可以暂时关闭浏览器的安全 DNS功能，让系统查询先进入 Clash，以判断问题是否来自多套 DNS 并行工作。

避免 DNS 回环

核心查询上游 DNS 时，相关流量还需要正确选择出口。如果 DNS 上游域名本身依赖尚未完成的解析，或者查询被路由规则反复送回同一个监听入口，就可能形成启动阶段的解析循环。配置较复杂时，应关注默认解析服务器、代理节点域名解析以及直连上游的可达性。日志中连续重复的 DNS 超时通常比网页错误页更能说明问题。

确认 TUN 已生效的测试方法

界面开关变为开启状态只是第一步。完整验证需要同时确认虚拟接口存在、路由已经写入、流量能够进入核心、规则正确命中以及 DNS 没有绕行。建议使用由浅入深的测试顺序，每一步只回答一个问题。

1. 查看启动日志：确认没有配置解析失败、权限不足、虚拟接口创建失败或路由写入失败。
2. 检查普通网页：访问直连与代理规则对应的站点，观察连接列表中的策略命中。
3. 测试不读取系统代理的程序：先关闭系统代理，仅保留 TUN，再运行终端下载工具或目标应用。
4. 观察连接记录：核对域名、目标地址、进程信息和最终策略，确认流量确实经过核心。
5. 测试 UDP：使用确实依赖 UDP 的应用进行短时测试，判断当前网络栈是否兼容。
6. 检查局域网：打开路由器、NAS 或打印机地址，确保私有网段没有被错误代理。
7. 切换网络：从 Wi-Fi 切换到热点后重新观察默认接口和路由是否自动更新。

连接记录是区分“没有接管”和“接管后规则错误”的关键。如果目标应用运行时完全没有新连接出现，应优先检查 TUN 接口、路由、应用绕过和权限；如果连接已经出现但选择了错误策略，应检查规则顺序、域名识别和策略组；如果策略正确但连接超时，则继续检查节点、DNS、MTU、防火墙和远端服务。

规则模式下的判断

规则从上到下匹配，命中后通常停止继续检查。TUN 并不会改变这一基本顺序。若某个域名应走代理却命中了直连规则，需查看它是以域名、目标 IP 还是进程信息进入规则引擎。宽泛的 IP-CIDR、GEOIP 或提前出现的直连规则，都可能覆盖后续更具体的处理。兜底规则通常放在规则列表末尾。

常见冲突与分层排查顺序

TUN 开启后完全断网

先关闭 TUN，确认基础网络立即恢复，再查看核心日志。完全断网通常与接口创建后核心未正常运行、默认路由指向错误、DNS 无响应或权限状态不完整有关。恢复测试时先关闭 strict-route，保留 auto-route 和 auto-detect-interface，并暂时退出其他 VPN。若设备同时连接有线与无线网络，应确认核心识别到真正能够访问外网的默认接口。

浏览器可用，但游戏或语音失败

浏览器以 TCP 和 HTTPS 为主，游戏、实时语音和部分即时通信功能会使用 UDP。此时应查看 UDP 连接是否进入核心、节点是否支持相应传输，以及当前 TUN 网络栈是否适合该应用。切换 system、gvisor 或 mixed 时应逐项测试，避免同时更改 DNS、节点和规则，否则无法判断改善来自哪一处。

开启后无法访问局域网

确认私有地址段仍被直连处理，并检查严格路由是否改变了本地网段的出口。常见私有网段包括 10.0.0.0/8、172.16.0.0/12 与 192.168.0.0/16，但实际设备还可能使用链路本地地址、IPv6 局域网地址或特定组播协议。能够直接打开设备 IP、但无法使用设备名称时，问题更可能位于本地 DNS、mDNS 或 Fake-IP 过滤。

与其他 VPN、虚拟机或容器冲突

多个网络工具都可能创建虚拟接口并修改默认路由。企业 VPN、游戏加速器、虚拟机桥接、Docker 或容器子网都可能与 TUN 的自动路由重叠。排查时先退出其他接管工具，确认 Clash TUN 单独运行正常，再逐个恢复。若两个工具必须共存，需要明确哪些网段由哪个接口处理，并避免双方都把对方的虚拟网段作为默认出口。

休眠或切换网络后失效

笔记本从休眠恢复、Wi-Fi 漫游或切换热点后，默认接口和网关可能变化。虽然 auto-detect-interface 用于识别出口，但客户端未必会在所有系统事件后立即重建路由。可以先重启核心而不是重装客户端；若重启核心即可恢复，应继续检查客户端的网络变化监听、后台运行权限和服务状态。

订阅更新后 TUN 配置消失

这通常说明参数写在订阅生成文件中，而客户端更新时重新下载并替换了该文件。应把 TUN 与 DNS 参数移到客户端支持的覆写层、混入配置或独立全局设置。调整后手动更新一次订阅并重启核心，确认参数仍存在，才能证明保存位置正确。

按层级缩小问题

分层排查的重点是保留可比较的结果。每次只改一个变量，修改后重启核心，并记录日志中第一条明确错误。直接重装客户端会清除部分现场信息，也无法解释问题究竟来自权限、路由、DNS 还是节点。

TUN 日常使用配置建议

完成基础配置后，不必持续增加参数。自动路由、明确的 DNS 方案、可理解的规则和稳定节点通常比大量实验性选项更容易维护。对于只使用浏览器和常规桌面软件的设备，系统代理已经能够覆盖主要需求；当命令行程序、游戏或特定应用无法遵循系统代理时，再启用 TUN 更有针对性。

需要长期使用 TUN 的设备，应定期关注核心升级后的字段变化，并在升级前保留可工作的配置。出现异常时先比较升级前后的核心版本、网络栈和 DNS 行为。客户端界面中的设置名称可能不同，但底层仍可按接口、路由、DNS、规则和节点这五个环节理解。

最终配置目标并不是让所有流量机械地通过代理，而是让需要接管的连接可靠进入规则引擎，再按用途选择直连、代理或拒绝。理解这一点后，TUN、全局模式和规则模式之间的区别会更清楚，也能避免把节点故障误判为虚拟网卡问题。