Clash TUN 模式和系统代理区别：流量入口、覆盖范围与选择方法

系统代理和 TUN 模式解决的是同一个入口问题：怎样把设备产生的连接送入 Clash 或 mihomo 内核。两者都不会直接决定某个网站走代理还是直连。流量进入内核后，仍要按当前运行模式、规则集、策略组和节点状态完成匹配。因此，“开启 TUN”不等于切换到 Global 全局模式，“开启系统代理”也不等于所有应用都会被接管。

流量入口：系统代理读取设置，TUN 接收网络包

系统代理的工作路径

启用系统代理时，Clash 客户端通常会把操作系统的 HTTP、HTTPS 或 SOCKS 代理地址写为本机回环地址，并指向内核监听端口。例如内核运行在 127.0.0.1:7890，支持系统代理的浏览器或桌面应用读取该设置后，会主动把请求交给这个端口。客户端关闭系统代理时，再恢复先前的操作系统设置。

这种方式位于应用层。应用必须读取系统代理，或者明确使用操作系统提供的网络接口，流量才会进入 Clash。常见浏览器、办公软件和一部分桌面客户端通常可以直接工作；自行实现网络栈、忽略代理设置、只支持特定协议的程序，则可能继续直接连接。命令行工具也存在差异：有些读取环境变量，有些需要单独指定 HTTP_PROXY、HTTPS_PROXY 或 SOCKS 地址。

TUN 模式的工作路径

TUN 模式会建立虚拟网络接口，并通过系统路由把符合条件的 IP 流量送入该接口。mihomo 内核从虚拟接口读取网络包，识别目标地址与协议，再根据规则决定直连、拒绝或转发到代理节点。因为入口更接近操作系统网络层，应用通常不需要理解 HTTP 或 SOCKS 代理，也不必主动读取系统代理设置。

这使 TUN 更适合接管游戏启动器、终端程序、部分商店应用、使用 UDP 的程序，以及忽略系统代理的桌面软件。不过，TUN 的覆盖范围仍受路由表、排除项、内核协议支持和操作系统限制影响。局域网网段、默认网卡、虚拟机网卡、容器网络或其他 VPN 都可能改变实际路径，不能只根据开关状态判断是否已经接管。

四项关键差异：覆盖、协议、DNS 与权限

比较项	系统代理	TUN 模式
工作层级	应用读取操作系统代理设置后，连接本地代理端口	虚拟网络接口接收经过系统路由的 IP 流量
应用覆盖	主要覆盖遵循系统代理的程序	可覆盖更多忽略系统代理的程序
协议范围	以应用支持的 HTTP、HTTPS、SOCKS 代理能力为准	通常可统一处理 TCP，并按内核和配置处理 UDP
DNS 路径	取决于应用、代理协议和 Clash DNS 配置	可配合 DNS 劫持与增强模式统一送入内核
系统权限	通常只需修改系统代理设置	通常需要管理员权限、系统服务或网络扩展
冲突来源	浏览器扩展、手动代理、遗留代理地址	其他 VPN、虚拟网卡、安全软件、路由优先级

应用兼容性不是简单的“浏览器与非浏览器”

浏览器通常遵循系统代理，但具体行为还会受到安全 DNS、QUIC、浏览器扩展和企业策略影响。部分基于 Chromium 的应用会复用系统网络设置，另一些应用则内置独立代理选项。游戏平台可能由启动器、更新器、登录组件和游戏进程共同组成，其中只有部分组件读取系统代理。此时网页能打开，并不能证明下载、登录和实时通信都进入了同一条链路。

TUN 模式能够从更低层接收这些连接，覆盖通常更完整。对于 UDP 流量，是否能够正常转发还取决于节点协议、代理服务端、策略规则以及内核配置。开启 TUN 只是提供入口，不会自动补齐上游节点不支持的能力。

DNS 处理决定域名规则能否稳定匹配

系统代理场景下，DNS 可能由应用本地查询，也可能通过代理协议交给内核处理。不同程序的行为并不统一。如果域名在进入 Clash 前已经被解析为 IP，内核能获得的信息可能与直接接收域名请求时不同，规则匹配结果也可能发生变化。浏览器自己的加密 DNS 设置还可能绕开操作系统 DNS 路径。

TUN 常与 mihomo 的 DNS 模块、dns-hijack、Fake-IP 或 Redir-Host 模式配合。DNS 请求先进入内核后，内核可以将域名映射关系与后续连接关联，再执行域名规则。Fake-IP 返回的是本地映射使用的虚拟地址，真实目标解析与代理选择由内核继续完成。局域网设备发现、游戏平台和依赖特殊 DNS 结果的应用可能需要加入 Fake-IP 排除列表，或者改用更适合当前环境的 DNS 增强模式。

权限与系统改动范围不同

系统代理主要修改操作系统保存的代理地址，所需权限相对较少。TUN 需要创建虚拟接口并调整路由，因此 Windows 客户端常通过管理员权限或后台服务运行，macOS 可能要求批准网络扩展，Android 与 iOS 则通常借助系统 VPN 接口完成接管。首次启用时出现权限确认属于建立网络入口的正常步骤。

权限申请完成后，仍要确认服务是否实际启动。客户端界面显示 TUN 已开启，不一定代表路由写入、DNS 劫持和默认接口识别都成功。mihomo 日志中的接口创建、路由设置和监听错误，比单独观察开关更有判断价值。

选择方法：按设备和应用范围判断

日常浏览与办公：先使用系统代理

如果主要需求是浏览器访问、文档同步和遵循系统代理的桌面应用，系统代理通常更直接。它对路由表影响较小，开启和关闭路径清晰，也便于判断某个应用是否主动使用代理。出现问题时，可以先检查本地端口、操作系统代理地址和策略组，不必同时处理虚拟网卡与路由冲突。

游戏、命令行与独立网络栈：优先检查 TUN

应用明确忽略系统代理，或者包含 UDP、更新器、子进程和独立登录组件时，可以使用 TUN 作为主要接管入口。常见场景包括终端包管理器未读取代理变量、游戏平台下载正常但游戏连接直连、商店应用无法使用系统代理，以及同一程序的不同组件路径不一致。

移动设备：系统 VPN 接口通常承担 TUN 角色

移动系统中的 Wi-Fi 手动代理通常只对当前无线网络生效，而且应用是否遵循该设置仍由应用实现决定。蜂窝网络也不使用这项 Wi-Fi 代理设置。需要设备范围接管时，兼容 Clash 或 mihomo 的客户端一般通过系统 VPN 接口建立通道。系统状态栏显示 VPN 后，还应在客户端日志中确认连接确实由规则处理。

开发环境、虚拟机与容器：先确认路由边界

虚拟机和容器通常拥有独立网卡、网关或网络命名空间。宿主机打开 TUN 后，来宾系统流量是否进入该接口，取决于桥接、NAT 和默认路由关系。容器访问宿主机回环地址时，127.0.0.1 指向容器自身，并不等于宿主机上的 Clash 端口。此类环境应先画出宿主机、虚拟网卡、容器网桥和出口网卡之间的路径，再决定使用 TUN、局域网监听或应用级代理。

系统代理和 TUN 是否需要同时开启

多数情况下，选择一个主要入口更容易排查。TUN 已稳定接管目标应用时，系统代理并非必需；只使用浏览器和常规桌面应用时，也不必为了覆盖范围而固定开启 TUN。部分客户端允许两者同时运行，内核通常会处理本地连接与路由排除，但复杂环境可能出现流量绕行、回环或难以判断实际入口的问题。

需要同时开启时，应确认系统代理指向的是当前内核端口，TUN 已排除必要的本地地址，并检查日志中同一连接是否只被接收一次。切换接管方式进行测试时，建议先关闭旧入口，再启动新入口，避免遗留系统代理或旧路由干扰结果。

设置顺序：先验证配置，再扩大接管范围

更新订阅。确认配置能够成功加载，代理节点与策略组已经显示，避免把订阅错误误判为接管失败。
选择规则模式。日常使用通常先设为 Rule，并检查默认策略组已有可用节点。Global 与 Direct 可用于短时定位问题，不适合作为判断 TUN 是否生效的唯一依据。
先测试系统代理。开启系统代理后，使用明确遵循系统设置的浏览器访问目标站点，并观察 Clash 连接记录是否出现域名、规则和策略组。
识别未接管应用。如果特定程序没有任何连接记录，确认它是否提供独立代理设置，是否需要环境变量，或者是否使用 UDP 与独立网络栈。
再启用 TUN。完成系统权限确认，检查虚拟接口、自动路由、默认网卡识别和 DNS 设置。
逐项恢复其他网络工具。先在单一网络环境下验证，再启动其他 VPN、虚拟机或安全软件，以便定位路由冲突来源。

mihomo 配置中常见的 TUN 基础结构如下。不同客户端可能通过图形界面生成这些字段，实际支持项以客户端集成的内核版本为准。

mixed-port: 7890
mode: rule

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

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

auto-route 用于自动写入必要路由，auto-detect-interface 用于识别当前默认出口，dns-hijack 用于把匹配的 DNS 请求送入内核。stack 的可用值和实现会随内核版本、操作系统及客户端封装方式变化，不应在不了解当前版本的情况下直接复制整段配置覆盖客户端生成项。

系统代理侧主要需要核对监听端口。配置使用 mixed-port 时，同一端口可以接收常见的 HTTP 与 SOCKS 代理连接。客户端写入系统设置的端口必须与内核实际监听值一致。如果修改了配置端口，但操作系统仍保留旧端口，表现通常是所有遵循系统代理的应用突然无法连接，而 TUN 接管的程序可能仍然可用。

故障检查：按入口、DNS、规则、出口四层定位

第一层：流量是否进入内核

打开客户端连接列表或实时日志，再启动目标应用。如果完全没有新连接，优先检查系统代理地址、TUN 服务状态、应用独立代理、路由表和防火墙。此时不要先更换节点，因为节点只会影响已经进入内核并被分配到代理策略的连接。

第二层：域名是否正确解析

连接记录只有 IP、域名规则没有命中，或者应用在域名解析阶段超时，应检查 DNS 模块是否启用、TUN 的 DNS 劫持是否生效、浏览器是否使用独立安全 DNS，以及 Fake-IP 排除规则是否过宽。局域网域名和设备发现协议还需要保留本地解析路径。

第三层：规则与策略组是否选对

流量已经出现但走向不符合预期时，查看最终命中的规则、策略组和节点。规则通常按配置中的顺序匹配，较宽的规则放在前面可能覆盖后续精确规则。订阅更新也可能重建策略组选择，需要重新确认当前组内选中的节点。

第四层：节点与物理网络是否可达

规则命中代理但连接超时，才进入出口检查。依次确认节点状态、节点协议对 TCP 或 UDP 的支持、当前网络对目标端口的限制，以及默认出口网卡是否正确。设备从有线网络切换到 Wi-Fi，或者从 Wi-Fi 切换到移动热点后，TUN 可能需要重新识别默认接口。

结论：用最小覆盖范围满足当前设备

系统代理依靠应用主动读取操作系统设置，结构简单，适合浏览器和常规桌面软件。TUN 通过虚拟接口接收网络包，覆盖范围更广，适合忽略系统代理、使用 UDP 或包含多个网络组件的应用，但同时增加了权限、路由、DNS 和虚拟网卡冲突的检查项。

选择时不必固定追求某一种模式。先用系统代理验证订阅、节点和规则链路；确认目标应用没有进入内核后，再启用 TUN 扩大接管范围。无论使用哪种入口，都应通过连接日志确认流量已进入内核，并继续核对 DNS、规则、策略组和实际出口。按这四层检查，比只切换开关更容易找到具体故障点。