进阶原理 预计阅读 11 分钟

Clash TUN 模式与系统代理区别:流量接管层级与适用场景

从系统代理设置与虚拟网卡两条路径讲清流量如何进入客户端,对比两者对命令行、游戏与 UDP 的覆盖范围,给出按场景切换的建议。

系统代理与 TUN：区别在流量进入内核之前

判断该开哪个开关，先把两个问题分开：应用的连接有没有进入 Clash 内核，以及进入后按什么规则处理。系统代理与 TUN 主要解决第一个问题；规则模式、全局模式和策略组选择主要解决第二个问题。开启 TUN 不代表所有连接都会走代理节点，开启系统代理也不代表所有应用都会读取这项设置。

本文以桌面客户端搭配 Clash Meta 后续发展的 mihomo 内核为主要说明对象。不同客户端的开关名称、权限申请和配置合并方式可能不同；旧版 Clash 内核也不一定支持相同的 TUN 字段。先在客户端的内核信息中确认实际运行的内核，再对照配置，比只看客户端名称更可靠。

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

开启系统代理后，客户端通常会把操作系统的代理地址改为本机监听地址，例如 127.0.0.1:7890。遵循该设置的浏览器或桌面应用会连接这个地址，由内核接收 HTTP 代理请求或 HTTPS 的 CONNECT 隧道请求，再按规则决定直连还是经节点转发。

这里的关键是“应用遵循设置”。Windows 的用户代理设置与 WinHTTP 配置并不等同；后台服务、某些更新程序和命令行工具可能使用另一套设置。Linux 桌面环境中的代理选项也不是所有程序通用的强制入口。因此，浏览器能访问，不足以证明终端、游戏和后台进程都已被接管。

TUN 模式：利用虚拟网卡与路由接收 IP 流量

TUN 提供虚拟的三层网络接口。客户端或内核建立接口并配置路由后，符合路由条件的 IP 数据包进入 TUN，再由内核处理连接。应用通常不必知道本地代理端口，也不必支持 HTTP 代理设置。这是它能覆盖更多命令行程序、游戏和 UDP 应用的原因。

不过，“覆盖更多”不等于无条件接管所有流量。路由排除、绑定到特定接口的连接、IPv6 配置、其他 VPN 以及局域网流量都可能改变结果。TUN 也不是以太网桥，不能据此推断广播发现或所有链路层协议都能经代理节点传输。

覆盖范围对比：浏览器、命令行、游戏与 UDP

常见使用场景与接管条件
场景 系统代理 TUN 模式
浏览器网页 浏览器遵循系统设置时，通常足够。 可接管路由覆盖的连接；需关注 DNS 与 QUIC。
curl、Git 等命令行工具 不能假定自动生效，可显式指定代理地址。 通常无需逐个配置代理，但要检查路由和运行环境。
游戏与语音 很多程序不读取 HTTP 系统代理，覆盖有限。 可处理进入 TUN 的 TCP、UDP，节点也须具备相应能力。
容器、虚拟机、WSL 往往需要在各自环境内设置代理。 取决于虚拟网络拓扑，宿主机开关不能保证全部覆盖。
局域网访问 可借助系统代理例外列表绕过。 需结合路由排除与内核直连规则检查。

UDP 能否使用，不能只看 TUN 开关

普通 HTTP 系统代理并不能让任意应用的 UDP 自动经过节点。SOCKS5 协议虽然有 UDP 转发机制，但应用和本地入口都必须支持并使用它；仅在系统里填写一个 HTTP 代理地址，不会自动获得这条路径。

TUN 能把符合路由条件的 UDP 数据包交给内核，但后续还受出站协议、节点配置、远端服务和防火墙限制。即使配置了 udp: true，也不能让原本不支持 UDP 的出站链路凭空获得能力。游戏登录成功但语音失败时，应单独检查语音连接，而不是只测试一个网页。

按场景选择：先系统代理，再补足未覆盖的应用

网页与普通桌面应用：优先从系统代理开始

如果主要需求是浏览网页，且浏览器遵循系统代理设置，可以先关闭 TUN，只开启系统代理与规则模式。这样改动范围较小，出现问题时也容易区分是本地端口、规则还是节点故障。Windows 11 可在「设置」→「网络和 Internet」→「代理」中核对代理服务器；macOS 可在「系统设置」→「网络」→当前网络连接→「详细信息」→「代理」中检查，具体标签会随系统版本略有变化。

本机地址通常是 127.0.0.1，端口应以客户端实际配置为准。本文使用 7890 举例，它不是所有客户端的固定默认值。若客户端监听的是其他端口，系统代理、终端环境变量和应用内手动代理也需要同步修改。

终端与开发工具：显式代理便于限定范围

只想让一次下载经过代理，可以给该命令单独指定入口，不必立即接管整台设备。下面的命令用于验证本地 HTTP 代理入口能否建立 HTTPS 隧道；Windows PowerShell 中写成 curl.exe，可避免旧环境中的同名别名干扰。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

这只能证明该请求使用了指定代理入口，不能证明游戏或其他终端任务也已接管。如果使用 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 等环境变量，还要检查工具是否支持对应变量，以及 NO_PROXY 是否排除了目标地址。变量名称中的 HTTPS 通常描述目标请求类型，不要求本地代理地址必须写成 https://。

游戏、语音或不支持代理的应用：再考虑 TUN

当应用不读取系统代理，也没有可用的代理设置时，TUN 更适合补足接管范围。启用前先确认客户端能够获得创建虚拟网卡与调整路由所需的权限；Windows 上可能由服务模式或提升权限完成，macOS、Linux 上则取决于客户端的辅助程序及权限方案，不应简单理解为所有平台都必须长期以管理员身份运行整个界面。

两种入口可以同时启用，但初次排查建议分别测试。系统代理打开时，浏览器可能继续通过本地端口工作，即使 TUN 没有成功接管，也会表现为“网页正常”。如果要验证 TUN，应先暂时关闭系统代理，并清除测试程序自身的代理设置，再观察连接日志。

mihomo TUN 配置：路由、DNS 与规则各管一段

以下是用于理解字段的局部示例，适用于支持这些字段的 mihomo 内核，不是一份可独立运行的完整订阅。客户端可能通过界面开关生成或覆写同名字段，修改前应备份配置，并在修改后查看最终生效配置，避免订阅更新覆盖手工内容。

mixed-port: 7890
mode: rule

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

DNS 还需要独立配置

上面的片段没有给出完整的 dns 配置。实际使用时还要确认内核 DNS 已启用、上游解析器可达，以及 fake-ip 或 redir-host 等解析模式与现有配置兼容。fake-ip 常见地址段为 198.18.0.0/16；它返回的是用于连接映射的地址，不应把该地址误当作目标网站真实服务器地址。

浏览器的安全 DNS、应用内 DoH 和 DoT 不会仅因为监听了 53 端口就自动被按普通 DNS 查询处理。遇到域名规则未命中或解析结果异常，先确认解析发生在哪里，再决定是否调整浏览器设置或内核 DNS 规则，不要反复更换节点来掩盖解析问题。

规则依旧决定直连或代理

流量进入内核后，在规则模式下仍按配置匹配策略。域名规则、IP 规则与末尾的 MATCH 兜底共同决定出站方向；TUN 不会绕过这套逻辑。域名是否可用于匹配，还受 DNS 映射和嗅探等机制影响，不能假设每个只有目标 IP 的连接都能恢复出原始域名。

局域网打印机、NAS 和公司内网通常需要保留直连路径。比如访问 192.168.1.10 时，应检查它是否被正确排除或命中直连规则。如果某条自动路由让数据包根本没有进入内核，那么调整内核内的规则也不会改变那条连接，需先找准发生问题的层级。

可重复验证：区分入口故障、分流错误与节点问题

  1. 记录基线。记下本地端口、运行内核、当前策略组和目标域名。先用浏览器访问一个固定目标，不要在每次测试时同时更换节点、DNS 和接管模式。
  2. 只测系统代理。关闭 TUN，开启系统代理，并用前面的显式代理命令复核。若显式命令正常但浏览器失败，优先看浏览器独立代理配置、系统例外列表和扩展设置。
  3. 只测 TUN。关闭系统代理，移除测试程序内的代理设置，启用 TUN 后发起新连接。观察日志是否出现目标、网络类型、命中规则和出站策略。
  4. 检查路由与解析。Windows 可查看 route print，Linux 可查看 ip route 与 ip rule，macOS 可查看 netstat -rn。不要只凭虚拟网卡图标判断接管成功。
  5. 针对 UDP 单独验证。用实际游戏或语音功能发起连接，在客户端连接列表中找对应 UDP 会话。网页测试和 ICMP 的 ping 结果，都不能代替代理链路的 UDP 测试。

需要排除显式代理变量时，可使用以下命令。但要注意：--noproxy "*" 只让 curl 绕过其显式代理路径；如果 TUN 开着，该连接仍可能由系统路由送进内核，不能把它称为“确保直连”命令。

curl --noproxy "*" --connect-timeout 10 -I https://example.com

还应主动关闭旧连接再测一次。浏览器连接池、游戏长连接和 DNS 缓存可能保留切换前的状态。一个连接在切换开关后仍能继续传输，并不一定表示新建连接也走相同路径。

常见问题：权限、VPN 共存与退出后的网络恢复

打开 TUN 后，为什么整个设备反而无法联网？

先关闭 TUN 恢复基线，再分别检查内核日志、DNS 上游与路由。虚拟接口已建立但内核无法正常处理流量，或路由指向了错误的出站接口，都可能造成中断。若仅域名访问失败而已知 IP 的连接有响应，应优先排查 DNS；这只是定位线索，不是对所有服务通用的访问测试。

TUN 和公司的 VPN 可以同时开启吗？

取决于两者的路由、DNS 和安全策略，不能保证共存。两个程序都改写默认路由时，可能互相覆盖或形成异常路径。先单独验证各自功能，再查看公司内网网段、默认路由与 DNS 是否被改变；涉及组织管理的设备，应遵循既定网络策略，不要盲目删除路由或调整安全设置。

退出客户端后，为什么浏览器还在报代理连接失败？

系统代理可能仍指向已关闭的 127.0.0.1:7890。先在系统代理设置中检查是否残留该地址，并检查浏览器是否单独配置了代理。若问题出在 TUN，优先重新启动客户端并正常关闭 TUN，让客户端执行路由清理；不建议在不了解网络拓扑时批量删除虚拟网卡和系统路由。

TUN 模式一定比系统代理更快吗？

不一定。两者首先是接管范围的区别，最终速度仍受节点带宽、路径拥塞、丢包、DNS、MTU 与设备处理能力影响。只有在目标、节点、时间段和传输类型尽量一致时，对比才有意义。TUN 让原本未进入内核的应用获得代理路径，属于覆盖范围变化，不能直接解释为同一条链路被加速。

实际选择可以保持简单：网页优先系统代理，少量命令行任务优先显式配置，需要覆盖不支持代理的应用或 UDP 场景时再启用 TUN。每次只改一个环节，用连接日志确认入口与规则，再判断节点质量，通常比同时打开所有开关更容易找到原因。

下载Clash选择适合设备的客户端