Clash TUN 模式与系统代理区别：流量接管机制对照

先确认层级：代理设置与虚拟网卡

系统代理和 TUN 模式都能把流量送入 Clash，但入口所在的网络层级不同。系统代理是在操作系统中登记 HTTP、HTTPS 或 SOCKS 代理地址，应用程序读取该设置后，主动把请求交给 Clash 的监听端口。TUN 模式则创建虚拟网络接口，并配合系统路由把 IP 数据包导向 Clash 内核。前者依赖应用是否遵循代理设置，后者主要依赖路由是否覆盖目标流量。

这一区别决定了实际覆盖范围。浏览器、部分桌面通信软件和遵循系统网络接口的程序，通常能直接使用系统代理。命令行工具、游戏、独立更新器、采用自有网络栈的软件，以及只发送 UDP 的程序，可能忽略系统代理。TUN 位于更低层，通常能够接收这些程序产生的 TCP 或 UDP 流量，再由 mihomo 等内核按照规则选择代理、直连或拒绝。

两种模式也不是速度档位。打开 TUN 不会自动提高节点带宽，使用系统代理也不代表连接性能更差。速度仍取决于本地网络、节点负载、线路质量、传输协议、目标站点和 DNS 结果。模式选择主要解决“哪些流量进入内核”以及“域名信息如何与连接对应”的问题。

系统代理：应用主动连接本地端口

Clash 图形客户端中的“系统代理”开关，通常会把操作系统的 HTTP 与 HTTPS 代理地址设置为本机回环地址和内核监听端口，例如 127.0.0.1:7890。如果客户端使用 mixed-port，该端口可以同时接受 HTTP 和 SOCKS 连接。应用取得代理设置后，会先连接这个本地端口，再由 Clash 读取目标地址并执行规则匹配。

以浏览器访问 HTTPS 网站为例，浏览器一般会向 HTTP 代理发送 CONNECT 请求，其中包含目标域名与端口。Clash 可以用该域名匹配 DOMAIN、DOMAIN-SUFFIX 或规则集。建立隧道后，HTTPS 内容仍保持端到端加密；流量接管不等于解密网页内容。对于普通 HTTP 请求，代理同样可以从请求目标中取得域名信息。

系统代理的优势是改动范围明确。只要程序遵循系统设置，就不必改写系统路由，也不必创建虚拟网卡。首次配置、浏览器访问、文档下载和常见桌面应用通常可以先采用这种方式。关闭开关后，客户端应恢复原有系统代理状态，因此也适合用来快速判断问题发生在代理链路还是本地直连链路。

系统代理常见的覆盖缺口

• 应用忽略系统设置：部分程序内置独立代理选项，未配置时会直接连接网络。
• 命令行环境未继承代理：终端工具可能只读取 HTTP_PROXY、HTTPS_PROXY 或自身配置文件。
• UDP 流量不经过 HTTP 代理：游戏、语音和部分实时通信功能可能继续直连。
• 后台服务运行在不同账户：系统服务未必读取当前桌面用户的代理设置。
• 应用固定使用自己的 DNS 与连接策略：域名解析和后续连接可能绕开系统代理入口。

因此，出现“浏览器正常，但某个程序无法连接”的情况时，不应立即更换节点。先查看程序是否提供代理选项，再检查它是否支持 HTTP 或 SOCKS5。若程序完全不支持代理，或者必须同时接管 UDP，才需要考虑 TUN 模式。

TUN 模式：路由把 IP 数据包送入内核

TUN 是三层虚拟网络接口。启用后，客户端或 mihomo 内核会创建虚拟网卡，并根据配置添加路由，使符合范围的 IP 数据包进入该接口。内核从数据包中读取源地址、目标地址和协议类型，再结合 DNS 映射、连接嗅探及规则进行判断。代理节点负责转发时，内核会把原始连接转换为对应的代理协议连接；规则命中 DIRECT 时，则通过真实网络接口直连目标。

由于涉及虚拟接口、路由表和网络栈，TUN 通常需要更高权限。Windows 客户端可能要求以管理员身份安装或启动服务；macOS 可能要求批准网络扩展或输入系统凭据；Linux 一般需要访问 /dev/net/tun、配置路由所需的能力，或由系统服务承担这些操作。具体方式由客户端实现决定，不能只根据界面上是否出现开关判断 TUN 已经生效。

mihomo 配置中的 TUN 段通常包含栈类型、自动路由、接口探测和 DNS 劫持选项。以下片段用于说明字段关系，实际使用时仍应以客户端生成的配置及当前内核文档为准：

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
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

auto-route 用于自动设置接管路由，auto-detect-interface 用于识别实际出站接口，避免把代理节点自身的连接再次送回 TUN。不同操作系统和内核版本支持的栈类型可能不同，常见值包括 system、gvisor 与 mixed。栈类型影响数据包在本机的处理路径，但不能替代节点质量与规则配置。

防止代理回环

TUN 接管范围过大时，必须确保 Clash 到代理服务器的连接能够从真实接口发出。如果该连接再次被路由回虚拟网卡，就会形成代理回环，表现为启用 TUN 后全部连接超时、日志重复建立相同目标，或者系统网络短时间内完全不可用。自动路由与接口探测通常会处理这一点，但多网卡、VPN、虚拟机、容器和手工路由环境仍可能需要明确排除。

DNS 处理：域名规则能否准确命中

代理规则经常按域名编写，但 TUN 接收到的原始数据包主要包含目标 IP。为了让 DOMAIN-SUFFIX 等规则正确工作，内核需要建立“域名查询结果与后续连接”之间的对应关系。DNS 劫持、fake-ip 和连接嗅探都是解决这一问题的手段，但三者职责并不相同。

在 fake-ip 模式下，Clash DNS 会为域名返回保留地址段中的临时地址，并保存域名与该地址的映射。应用随后连接这个临时地址时，内核可以还原原始域名，再执行域名规则并向远端建立真实连接。常见默认网段属于基准测试用途的保留地址范围，不是公网服务器地址。这个机制可以减少“先在本地解析为某个 IP，再按 IP 规则误判”的情况。

部分局域网设备发现、打印服务、游戏平台或依赖真实 DNS 答案的程序不适合 fake-ip。此时可用 fake-ip-filter 排除相应域名，让它们获得真实解析结果。过滤项不宜随意扩大；如果把大量普通域名排除，域名与连接的关联会减弱，规则匹配可能退回 IP 判断。

redir-host 模式通常返回真实 IP，并由内核记录解析关系。它与部分应用的兼容方式更直接，但当一个 IP 对应多个域名、DNS 缓存来自其他解析器，或者应用绕过 Clash DNS 时，域名映射可能不够稳定。连接嗅探可以从 TLS ClientHello 的 SNI 或 HTTP Host 等信息补充域名，但无法保证每种协议都能取得域名，也不会解密 HTTPS 内容。

避免 DNS 请求绕过接管

1. 确认 Clash DNS 已启用，并查看客户端显示的监听地址。
2. 启用 TUN 时检查 DNS 劫持规则是否覆盖普通 53 端口查询。
3. 使用加密 DNS 的应用可能直接访问指定服务器，需要依靠路由和域名规则继续接管其连接。
4. 排查时清理操作系统与浏览器 DNS 缓存，避免旧结果影响判断。
5. 局域网域名解析异常时，检查 nameserver-policy、fallback 与 fake-ip-filter，而不是直接停用全部规则。

系统代理模式下，浏览器通过 CONNECT 提交域名时，Clash 可以直接取得目标名称，因此对 fake-ip 的依赖通常较低。不过应用若先自行解析并只向 SOCKS 代理提交 IP，仍可能失去域名信息。SOCKS5 支持提交域名，但是否采用该方式由应用决定。

使用场景：按覆盖需求选择入口

日常网页访问和支持系统代理的桌面软件，可以优先启用系统代理。它的网络改动较少，出现问题时也容易通过关闭开关恢复直连。对于刚完成订阅导入的用户，这种方式便于先验证节点、策略组和规则是否正常，再决定是否增加 TUN 层。

如果需要接管不支持代理设置的软件、UDP 应用、游戏平台、后台更新器或多个命令行程序，TUN 更合适。它可以减少逐个应用填写代理地址的工作，并让不同网络栈的连接统一经过规则系统。使用前应确认客户端搭载支持 TUN 的内核；当前常见实现以 Clash Meta 延续项目 mihomo 为主，不同客户端暴露的选项名称与权限管理方式会有差异。

服务器和开发环境还需考虑容器、远程连接与管理链路。通过 SSH 远程修改默认路由时，一旦 TUN 路由配置错误，管理连接可能立即中断。此类环境应先保留独立终端，设置自动回滚任务，并明确排除管理网段。容器流量是否进入 TUN，则取决于宿主机路由、网络命名空间与转发规则，不能只看宿主机浏览器是否代理成功。

推荐的渐进配置顺序

1. 导入有效订阅，选择一个可连接的节点或策略组。
2. 使用规则模式开启系统代理，验证浏览器与常见应用。
3. 查看连接日志，确认域名规则、直连规则和代理规则符合预期。
4. 确有覆盖缺口时再开启 TUN，并授予客户端所需系统权限。
5. 分别测试 TCP、UDP、局域网访问、DNS 解析和系统休眠恢复。
6. 保留可工作的原配置，修改路由或 DNS 选项后逐项复测。

一般不需要为了“更彻底”而同时依赖两套入口。很多桌面客户端在开启 TUN 后仍保留系统代理开关，这不一定造成错误，但会让部分应用先走显式代理、其他应用再走 TUN，排障时难以判断实际入口。若客户端文档没有特殊要求，可以先只启用一种接管方式，确认稳定后再评估是否需要组合。

故障排查：从入口到出站逐层检查

模式切换后无法联网，应按数据路径检查，而不是一次修改多个 DNS、节点和规则选项。第一步确认 Clash 内核正在运行，本地 mixed-port 或其他监听端口没有被占用。第二步确认当前使用的入口：系统代理地址是否指向正确端口，或者 TUN 虚拟接口是否已经创建。第三步再查看请求是否出现在连接记录中。

最后再比较节点。如果同一节点在系统代理下可用、TUN 下不可用，问题更可能位于虚拟接口、路由、DNS 或权限；如果两种模式都无法建立代理连接，应检查订阅状态、策略选择、节点可达性和本地网络。如果只有某个目标异常，则查看它命中的具体规则与策略组，避免把单站问题误判为整个 TUN 功能失效。

结论：覆盖范围决定模式，不由名称决定

系统代理位于应用层入口，配置直接、排障路径短，适合遵循操作系统代理设置的程序。TUN 位于 IP 路由入口，可以覆盖更多 TCP、UDP 和不提供代理选项的应用，但需要处理权限、虚拟接口、路由、DNS 映射及代理回环。二者最终都把连接交给 Clash 或 mihomo 的规则引擎，并不会改变订阅本身的节点质量。

合理顺序是先用系统代理验证基础配置，再根据明确的应用覆盖需求启用 TUN。遇到异常时，依次检查应用入口、DNS、规则、策略组、代理出站和真实网络接口。保持每次只修改一个选项，通常比频繁切换节点和网络栈更快定位问题。