Clash TUN 模式和系统代理有什么区别：接管范围、DNS 路径与适用场景

Clash 客户端里的“系统代理”和“TUN 模式”不是两种规则模式，也不决定连接最终选择哪个节点。它们解决的是同一个更靠前的问题：应用产生的流量如何进入 Clash 或 mihomo 内核。流量进入内核以后，才会继续经过域名嗅探、DNS、规则匹配、策略组选择和出站连接。

系统代理工作在应用与操作系统提供的代理接口一侧。浏览器、支持系统代理的桌面软件会读取代理地址，再主动把请求交给 Clash。TUN 模式则创建虚拟网络接口，通过系统路由把 IP 数据包送进内核，因此能够覆盖更多没有代理设置的软件。两者可以使用相同订阅和相同规则，但接管范围、DNS 路径、权限要求以及故障表现并不相同。

两种模式的请求路径

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

开启系统代理后，图形客户端通常会把操作系统的 HTTP、HTTPS 或 SOCKS 代理地址指向本机监听端口，例如 127.0.0.1:7890。浏览器读取该设置后，不再直接连接目标网站，而是先连接本地 Clash 端口。内核取得目标主机名或目标地址，再按当前规则决定使用 DIRECT、REJECT 或某个代理策略组。

这条路径依赖应用配合。大多数主流浏览器和读取系统网络设置的桌面程序可以正常进入代理，但以下流量可能绕过系统代理：

• 软件自行实现网络栈，并明确忽略操作系统代理设置。
• 游戏、语音、同步工具等直接使用 UDP，且没有 SOCKS 或应用内代理支持。
• 终端程序只读取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 等环境变量。
• 虚拟机、容器或子系统拥有独立网络环境，无法把宿主机回环地址当作自身代理地址。
• 应用使用硬编码地址、私有协议或独立的安全 DNS 通道。

因此，系统代理已开启不等于所有进程都已被接管。它更接近一份交给应用读取的连接指示，而不是对系统全部数据包进行强制改道。

TUN：系统路由把数据包交给虚拟接口

TUN 模式会创建虚拟三层网络接口。系统根据路由表把符合条件的 IPv4 或 IPv6 数据包发送到该接口，mihomo 等内核再通过用户态网络栈还原连接、执行规则并建立出站。应用通常仍认为自己在直接访问目标地址，不需要单独支持 HTTP 或 SOCKS 代理。

典型路径可以简化为：应用发起连接 → 操作系统路由选择 → TUN 虚拟接口 → Clash 内核 → 规则与策略组 → 直连或代理出站。因为入口位于 IP 层，TUN 对 UDP、命令行程序、部分游戏启动器和忽略系统代理的软件覆盖更完整。覆盖更完整并不代表所有流量都会自动代理，最终动作仍取决于规则。局域网、保留地址和特定进程仍可配置为直连。

DNS 路径为何会改变结果

很多“节点能连通但网站打不开”“规则没有按域名命中”“关闭 Clash 后无法解析”的问题，实际出现在 DNS 路径。判断 DNS 是否经过 Clash，不能只看界面里的 DNS 开关，还要确认应用把查询发到哪里、系统使用哪个解析器、53 端口是否被劫持，以及浏览器是否启用了独立的加密 DNS。

系统代理下可能存在本地解析

应用通过 HTTP CONNECT 或 SOCKS 传递域名时，Clash 可以看到目标主机名并执行域名规则。但并非所有连接都保留域名。有些程序先调用系统 DNS 得到 IP，再把 IP 地址交给代理；另一些程序直接使用浏览器内置的 DNS over HTTPS。此时，系统解析器、浏览器解析器和 Clash DNS 可能同时存在。

如果请求在进入内核前已经被解析为 IP，域名规则的命中能力会受到影响。内核可能通过嗅探恢复部分 HTTP、TLS 或 QUIC 主机信息，但嗅探不是对所有协议都有效，也不应被当成错误 DNS 配置的替代方案。

TUN 下通常配合 DNS 劫持

TUN 配置常把普通 UDP 或 TCP 53 端口查询送到内核的 DNS 模块。mihomo 的具体字段会随版本和客户端封装变化，常见结构如下，实际使用时应以当前客户端生成的配置为准：

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

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

fake-ip 会向应用返回保留地址范围中的映射地址，内核据此保留域名与连接之间的对应关系。数据包进入 TUN 后，内核再使用原始域名匹配规则并连接实际目标。部分局域网设备、连通性检测、游戏平台或依赖真实地址返回值的服务不适合 fake-ip，需要加入过滤列表，或根据客户端能力改用其他增强模式。

DNS 劫持主要针对传统 53 端口查询。应用自行访问 DoH 或 DoT 服务时，那些查询表现为普通 HTTPS 或加密连接，并不会仅因写了 dns-hijack 就自动转换成 Clash DNS 请求。可以通过规则控制已知解析服务的出站，也可以关闭应用内安全 DNS，让解析路径统一交给系统与内核。

权限、路由与平台差异

系统代理通常只修改当前用户的网络代理设置，关闭时恢复原值即可。TUN 需要创建虚拟接口、添加路由、调整 DNS 或调用系统服务，因此权限要求更高。不同客户端可能通过管理员启动、特权辅助服务或安装网络扩展来完成这些动作。

Windows

Windows 客户端启用 TUN 时，通常需要管理员权限或预先安装并运行具有相应权限的服务。若界面显示 TUN 已打开，但流量仍走原网络，应检查虚拟网卡是否创建、默认路由是否写入，以及安全软件或防火墙是否拦截内核进程。休眠、网络切换和异常退出后，还应确认系统 DNS 与路由是否恢复。

macOS

macOS 上的实现可能使用系统网络扩展、虚拟接口或授权辅助程序。首次启用时通常会出现系统授权。公司设备的管理策略可能限制网络扩展安装。若只有浏览器可用而终端或 UDP 应用不可用，应先确认当前实际开启的是系统代理还是 TUN，而不是直接更换节点。

Linux

Linux 创建 TUN 接口和写入路由需要 root 权限或对应能力，例如为服务授予网络管理权限。命令行部署还要处理默认出口识别、策略路由、systemd 启动顺序以及 DNS 管理器之间的关系。NetworkManager、systemd-resolved 和容器网络可能同时修改路由或解析设置，需要明确由哪个组件负责最终状态。

容器和虚拟机是常见边界。宿主机开启 TUN 后，来宾流量是否经过该接口取决于桥接、NAT、转发规则和路由设计。不能仅凭宿主机浏览器测试结果推断容器流量也已进入 Clash。

适用场景怎么选

优先使用系统代理的情况

• 主要处理浏览器、代码编辑器和支持系统代理的桌面软件。
• 希望保持网络改动较少，便于随时开关和定位故障。
• 当前账户没有安装虚拟接口或修改路由的权限。
• 局域网、VPN、虚拟机或企业网络环境较复杂，需要避免额外路由冲突。
• 只需让少数应用走代理，并能在应用内明确设置 HTTP 或 SOCKS 地址。

开发工具需要单独确认。Git、包管理器、Docker 客户端和终端下载工具不一定读取图形界面的系统代理。可按工具文档设置代理环境变量，或直接给工具填写本地 SOCKS/HTTP 监听地址。系统代理模式适合把接管范围保持在可见、可控的应用层。

优先使用 TUN 的情况

• 应用忽略系统代理，或没有提供代理设置入口。
• 需要处理 UDP、游戏连接、命令行程序或多个协议混合流量。
• 希望让域名解析、规则匹配和应用连接使用较统一的路径。
• 需要按进程、目标网段或复杂规则处理全局网络流量，且客户端内核支持相应能力。
• 可以管理管理员权限、系统服务、路由恢复和局域网绕过规则。

TUN 更适合“应用不可控，但系统网络可控”的环境。它不是速度增强开关。延迟和吞吐主要仍受节点线路、拥塞、传输协议、MTU、DNS 响应以及目标服务影响。若 TUN 开启后速度下降，应检查是否发生路由环路、错误 IPv6 路径、MTU 不匹配或 DNS 回退等待，而不是直接把问题归因于虚拟网卡本身。

两者是否可以同时开启

不少客户端允许系统代理和 TUN 同时开启。这样做可以兼顾明确读取代理设置的应用与其他流量，但排障变量会增加。某些连接可能先进入本地代理端口，该端口产生的出站又受 TUN 路由影响。成熟实现通常会设置接口排除和进程绕过以避免循环，但客户端服务异常、手工路由或外部 VPN 仍可能破坏这些条件。

日常使用无需为了“覆盖更多”固定同时开启。先根据应用类型选择一个入口。系统代理已经覆盖需求时，保持单一入口更容易维护；确实存在不读取代理的应用时，再测试 TUN。

按入口、解析、规则、出站分层排障

切换代理模式后出现故障，应按数据路径逐层确认，而不是连续更换节点。以下顺序可以把问题限制在较小范围。

1. 确认内核正在运行。查看客户端状态、本地监听端口和最近日志。若内核没有启动，系统代理和 TUN 都不会产生有效转发。
2. 确认流量进入内核。访问测试站点或执行一次明确请求，观察连接列表是否出现目标。没有记录通常说明应用未读取系统代理，或 TUN 路由没有生效。
3. 确认 DNS 请求路径。比较系统解析结果、客户端 DNS 日志和浏览器安全 DNS 设置。不要只用一个网页测试下结论。
4. 确认规则命中。查看目标连接匹配到哪条规则、进入哪个策略组。规则顺序通常是从上到下，先命中的规则决定动作。
5. 确认策略组实际选择。策略组名称显示为代理不代表内部节点可用。检查当前选中节点、延迟测试和失败日志。
6. 确认出站接口。TUN 开启时尤其要检查内核是否选中了正确的物理网卡，避免把代理服务器连接再次送回 TUN。

系统代理模式下，可以分别测试“不使用代理”和“明确指定本地代理”的结果。下面的端口只是常见示例，应替换成客户端当前显示的监听端口：

curl https://example.com
curl --proxy http://127.0.0.1:7890 https://example.com
curl --proxy socks5h://127.0.0.1:7890 https://example.com

socks5h 中的主机名解析会交给 SOCKS 代理端处理，适合与本地解析结果对比。若明确指定代理可用，而普通请求不可用，问题多半位于系统代理读取或环境变量。若两者都进入内核但规则不同，则应检查请求携带的是域名还是已解析的 IP。

TUN 模式下，先查看系统是否存在对应虚拟接口和路由，再观察一次请求是否出现在 Clash 连接记录中。若 TCP 可用但 UDP 不通，应核对内核、节点协议、规则和目标服务是否支持该 UDP 路径。若局域网打印机或路由器管理页失联，应检查私有网段是否保持直连，以及自动路由是否覆盖了本地网络。

选择结论：先最小接管，再补足覆盖

只处理浏览器和常规桌面应用时，系统代理通常是更直接的起点。它权限要求低，连接入口清楚，也便于判断应用是否已读取代理设置。遇到命令行程序时，可以补充环境变量或工具自身的代理配置。

当应用忽略代理设置、需要 UDP、需要更统一的 DNS 路径，或希望通过路由接管更多进程时，再启用 TUN。启用后应同步检查管理员权限、虚拟接口、自动路由、物理出口识别、DNS 劫持、局域网绕过和 IPv6 行为。

两种模式最终都把连接送入同一套 Clash 或 mihomo 规则体系。系统代理解决“应用是否愿意交给内核”，TUN 解决“系统是否把数据包送给内核”。先确定故障位于入口、DNS、规则还是出站，再调整对应配置，能够避免把所有连接问题都归结为节点或订阅。