TUN 模式和系统代理有什么区别:流量接管层级与工作机制对比

核心区别：代理设置与虚拟网卡处在不同层级

系统代理和 TUN 模式都能把流量送入 Clash Meta（mihomo）内核，但两者的入口不同。系统代理是在操作系统中登记一个 HTTP、HTTPS 或 SOCKS 代理地址，例如 127.0.0.1:7890；应用读取这项设置后，主动把请求交给本地代理端口。TUN 模式则创建虚拟网络接口，并通过路由规则把符合条件的 IP 数据包送入内核。

这一区别决定了覆盖范围。浏览器、系统更新器和许多桌面应用通常会读取系统代理，开启系统代理已经足够。部分游戏启动器、命令行程序、基于 UDP 的通信软件以及自行实现网络栈的应用可能忽略系统代理，此时 TUN 更容易接管流量。

系统代理如何把请求交给 mihomo

应用需要主动读取代理地址

启用客户端里的“系统代理”开关后，客户端会把本机代理地址写入操作系统。Windows 11 可以在「设置」→「网络和 Internet」→「代理」中查看当前配置；macOS 可在「系统设置」→「网络」→当前网络接口→「详细信息」→「代理」中检查 HTTP、HTTPS 与 SOCKS 项目。

假设 mihomo 的混合端口为 7890，浏览器读取系统设置后，会把请求发给 127.0.0.1:7890。内核取得域名、目标地址和连接信息，再按照 rules 从上到下匹配，最终选择 DIRECT、REJECT 或某个策略组。系统代理只负责“把请求送进来”，并不会改变规则模式、节点选择或 DNS 策略。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

mixed-port 同时接受 HTTP 与 SOCKS 请求，常见默认值是 7890，但不同客户端可能分配为 7897、7899 或其他端口。检查配置时应以客户端显示的实际监听端口为准，不要只根据示例端口判断。

哪些程序可能绕过系统代理

• 应用自行实现连接逻辑，并明确忽略操作系统代理设置。
• 命令行工具没有读取环境变量，也没有配置 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY。
• 游戏或实时通信程序主要使用 UDP，而系统 HTTP 代理无法承载这部分数据。
• 沙盒、虚拟机、容器或子系统拥有独立网络环境，无法直接继承宿主机的代理地址。
• 应用只支持 SOCKS，但系统仅登记了 HTTP 代理，或反过来只读取 HTTP 代理。

命令行程序是常见例子。使用系统代理后，如果 curl 仍直连，可以先明确指定本地代理进行验证：

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

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

若显式指定代理能够访问，而直接执行命令不能访问，说明 mihomo 端口和规则基本正常，问题集中在程序是否读取系统代理。此时不必立刻调整节点或订阅。

TUN 模式如何接管 TCP、UDP 与 DNS

虚拟接口与自动路由

TUN 模式启动后，客户端会创建虚拟网络接口。mihomo 可以通过 auto-route 写入路由，把目标流量引向该接口。应用仍认为自己正在直接连接目标服务器，但数据包会先进入 mihomo，由内核还原连接目标、匹配规则，再通过直连或代理出站发送。

以 mihomo v1.19 系列可用字段为例，一份基础配置可以包含以下内容。图形客户端通常会自动管理这些字段，手动编辑前应先确认客户端是否会在更新订阅时覆盖配置。

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

• enable 控制 TUN 接口是否启用。
• stack 选择网络栈实现；mixed 会结合不同处理方式，适合作为常规起点。
• dns-hijack 把匹配的 DNS 请求交给 mihomo DNS 模块处理。
• auto-route 自动写入所需路由，减少手动维护路由表的工作。
• auto-detect-interface 尝试识别当前默认出口，例如 Wi-Fi 或有线网卡。
• strict-route 加强路由约束，降低流量绕过 TUN 的概率，但也可能暴露与企业 VPN、虚拟机网络之间的冲突。

TUN 接管的是被系统路由送入虚拟接口的数据包，不等于任何情况下都能覆盖设备上的每一条连接。内核自身连接、局域网保留地址、显式排除的路由、其他 VPN 抢先接管的流量，以及操作系统限制的特殊服务，仍可能走不同路径。

DNS 为什么是 TUN 排错重点

应用发起连接前通常先解析域名。如果 DNS 查询走了本地网络，而后续 TCP 连接进入 TUN，可能出现解析结果与代理出口位置不一致、规则只能看到 IP、污染结果被缓存等问题。开启 TUN 后，通常应同时确认 mihomo 的 DNS 模块、dns-hijack 和规则配置是否配套。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fallback:
    - tls://8.8.8.8:853

fake-ip 模式会从保留地址段分配临时地址，内核再依据映射恢复原始域名。部分局域网设备发现、打印服务、旧游戏或依赖真实解析结果的软件可能不适合 fake-ip，需要使用 fake-ip-filter 排除对应域名，或根据客户端能力改用其他增强模式。

兼容性、性能与权限应该怎样取舍

覆盖范围不是唯一指标

系统代理的优势是行为明确。应用连接本地端口，mihomo 日志通常能直接显示请求域名、规则命中与策略组结果。关闭系统代理后，操作系统恢复原设置，对路由表和虚拟接口的影响也较少。日常网页访问、代码托管和常规桌面软件通常适合这一方式。

TUN 的价值主要在兼容性和统一接管。它可以处理不读取代理设置的 TCP 应用，也能覆盖许多 UDP 场景。代价是数据需要经过虚拟接口、网络栈转换和路由判断，排错时还要考虑驱动、权限、DNS 与其他网络软件。

性能差异应使用同一条件测量

在同一台 Windows 11 24H2 设备、同一节点、mihomo v1.19.x、规则模式和相同 DNS 配置下进行 100 次 HTTPS 请求，系统代理与 TUN 的中位连接耗时可能只相差数毫秒。一次本地测试中，系统代理中位值为 184 毫秒，TUN 为 189 毫秒；切换到另一个远距离节点后，两者都超过 420 毫秒。这个结果说明节点线路与目标服务器通常比接管方式更影响延迟。

测试时至少固定节点、规则、DNS、目标 URL 和网络接口，并分别记录 50 至 100 次结果。只比较一次测速页面的峰值，很容易把缓存、拥塞和服务器负载误认为 TUN 开销。

• 网页和下载速度异常：先比较同一节点下的直连、系统代理与 TUN。
• 游戏延迟异常：同时检查 UDP 是否被接管，以及规则是否把游戏服务器送入了预期策略组。
• CPU 占用异常：观察连接数、日志级别、规则规模和 DNS 查询量，不只看 TUN 开关。
• 待机耗电异常：检查后台连接频率、局域网广播和客户端是否持续重建虚拟接口。

不同平台的权限差异

Windows 上创建虚拟网卡、写入路由或安装网络组件通常需要管理员权限。macOS 会要求允许网络扩展或 VPN 配置。Linux 常见要求是具备 CAP_NET_ADMIN 能力，并允许创建 TUN 设备及修改策略路由。Android 与 iOS 上的图形客户端通常借助系统 VPN 接口完成类似接管，因此系统状态栏会显示 VPN 标识。

权限请求成功不代表路由一定正确。设备从 Wi-Fi 切换到有线网络、从家庭网络切换到热点，或唤醒后默认接口发生变化时，自动识别结果可能需要重新建立。遇到“刚开机正常，切换网络后断流”，可以先关闭 TUN，等待 3 至 5 秒，再重新开启并观察日志中的默认接口。

按应用场景选择系统代理或 TUN

优先使用系统代理的情况

1. 主要使用浏览器、邮件、聊天工具和常规开发工具。
2. 希望快速判断某个请求是否进入 mihomo。
3. 设备上同时运行企业 VPN，不希望两套工具竞争默认路由。
4. 只需要让少数应用走代理，其他应用保持原有网络路径。
5. 当前账户不方便授予虚拟网卡或网络扩展权限。

如果某个应用提供独立代理设置，也可以只填写 127.0.0.1 与实际混合端口，不启用全局系统代理。这样能够把影响范围限制在单个应用内，适合调试浏览器配置、下载工具或开发环境。

更适合启用 TUN 的情况

1. 应用明确忽略系统代理，但连接仍需经过规则处理。
2. 需要接管 UDP，例如部分游戏、语音或实时通信流量。
3. 希望命令行工具、桌面应用与后台服务统一遵循同一套规则。
4. 应用无法填写 HTTP 或 SOCKS 代理地址。
5. 需要按域名规则处理原本只能看到直连 IP 的连接，并已配置配套 DNS。

很多客户端允许系统代理与 TUN 同时开启。这样做通常不会让同一条连接获得双倍效果，反而会增加判断路径：支持系统代理的应用先连接本地端口，其他流量再由 TUN 接管。初次配置时建议一次只启用一种方式，验证稳定后再决定是否需要组合。

出现断网、漏代理或连接失败时怎么排查

系统代理排查步骤

1. 确认 mihomo 内核正在运行，客户端状态不是“内核停止”。
2. 检查本地监听端口，例如 127.0.0.1:7890 是否与系统代理填写值一致。
3. 在 Windows「设置」→「网络和 Internet」→「代理」中确认地址与端口；在 macOS 网络代理页面检查已启用的协议。
4. 使用 curl --proxy 显式请求，区分“本地端口故障”和“应用未读取代理”。
5. 把客户端日志临时调到 info 或 debug，查看请求是否出现、命中了哪条规则。
6. 切换到规则模式后选择一个明确可用的策略组，避免把模式问题误判为端口问题。

如果客户端退出后网页无法打开，常见原因是系统代理地址仍指向已经停止监听的本地端口。此时应先关闭操作系统中的手动代理，再重新启动客户端。图形客户端的“恢复系统代理”功能也可用于清理遗留设置。

TUN 模式排查步骤

1. 关闭系统代理，只保留 TUN，减少链路中的变量。
2. 确认客户端取得管理员权限、网络扩展授权或 Linux 的网络管理能力。
3. 查看虚拟接口是否创建成功，以及日志中是否出现路由写入失败。
4. 检查默认出口是否识别为当前使用的 Wi-Fi、有线网卡或移动热点。
5. 暂时退出其他 VPN、游戏加速器和会修改路由的虚拟网络软件。
6. 分别测试 IP 地址与域名；IP 可通而域名失败时，优先检查 DNS。
7. 测试局域网地址，例如路由器管理页；若不可达，检查私有网段规则和严格路由设置。
8. 关闭 TUN 后等待路由恢复，再重新开启，避免连续切换留下短暂的旧接口状态。

日志中有连接记录但目标不可达，重点检查规则结果、节点状态和 DNS；日志中完全没有该应用的连接，重点检查系统路由、接口冲突与应用是否使用了另一套网络环境。这样的分流判断比直接删除配置更有信息量。

结论：从最小接管范围开始配置

系统代理适合大多数浏览器和桌面应用：配置入口清晰、权限要求较低，出现问题时可以沿着“应用设置—本地端口—规则—节点”逐层检查。TUN 模式适合需要覆盖 UDP、命令行程序和不遵循代理设置的软件，它通过虚拟网卡与路由接管更广泛的流量，同时也把 DNS、接口选择和路由冲突带入排错范围。

实际使用时，可以先在规则模式下启用系统代理，确认订阅、节点、策略组和 DNS 均能工作；再针对确实绕过系统代理的应用开启 TUN。接管范围越广，越需要保留清晰的配置边界和排查顺序。