系统代理与 TUN 模式的接管范围

Clash 图形客户端常见的「系统代理」开关，本质上是把操作系统的 HTTP 与 SOCKS 代理地址指向本机监听端口。例如 HTTP 代理使用 127.0.0.1:7890，SOCKS5 使用 127.0.0.1:7891。浏览器、部分聊天工具和遵循系统设置的应用会主动把请求交给这些端口，再由 Clash 按规则选择 DIRECT、REJECT 或代理节点。

问题在于，不是所有程序都会读取系统代理。命令行程序可能直接建立 TCP 连接，游戏启动器可能使用自己的网络模块，部分软件还会绕过 HTTP 代理发送 UDP。此时 Clash 核心虽然正常运行，日志里却看不到对应连接。不断改规则也不会生效，因为流量根本没有经过规则引擎。

TUN 模式会创建一块虚拟网卡，并为操作系统写入对应路由。符合路由条件的数据包先进入虚拟网卡，再由 Clash Meta，也就是 mihomo 内核还原连接信息、执行 DNS 判断和规则匹配。应用不必知道本机正在使用代理，因此命令行工具、独立更新器和更多 UDP 程序也能进入统一的分流流程。

一条连接进入 TUN 后会发生什么

  1. 应用向目标域名或 IP 发起 TCP、UDP 连接。
  2. 系统路由把对应数据包送入 Clash 创建的虚拟网卡。
  3. 内核识别原始目标，并结合 DNS 映射恢复域名信息。
  4. 规则从上到下匹配，例如 DOMAIN-SUFFIX、GEOIP、GEOSITE 与 MATCH。
  5. 连接按照匹配结果直连、拒绝，或交给指定代理组。

TUN 不是把所有连接强制送往同一个节点。「全局流量接管」描述的是流量入口更完整，不等于 Clash 的 GLOBAL 代理模式。保持 Rule 模式时，局域网、国内站点和海外服务仍可分别执行不同策略。

开启前检查内核、权限与 DNS

确认客户端使用支持 TUN 的内核

不同图形客户端的菜单名称并不完全一致，但核心应为 Clash Meta 或 mihomo。可以在「设置」→「内核」或「设置」→「关于」中查看内核名称与版本。旧版 Clash Premium 曾提供 TUN 能力，当前持续更新的配置通常以 mihomo 为基础。若客户端只能切换传统 Clash 内核，配置里的部分 tun 字段可能无法识别。

排查问题时应同时记录客户端版本和内核版本。图形界面的版本号只代表外壳，不一定等于正在运行的内核版本。例如客户端显示 2.0.0，而「内核」页面可能显示 mihomo 1.19.x。真正决定 stack、自动路由和 DNS 行为的是后者。

准备管理员权限或服务模式

  • Windows：虚拟网卡和路由修改通常需要管理员权限。优先在客户端的「设置」→「服务模式」安装服务，再重启客户端。
  • macOS：首次开启时可能要求安装辅助程序，并弹出系统密码或 Touch ID 验证。系统设置里出现网络扩展提示时，需要明确允许。
  • Linux：运行进程需要创建 TUN 设备和修改路由的权限。桌面客户端可能通过 Polkit 提权，命令行部署则常由 systemd 服务管理。
  • Android 与 iOS：客户端通常借助系统 VPN 接口实现流量接管，不需要桌面端的服务模式，但必须批准 VPN 配置。

DNS 必须与 TUN 配合检查

TUN 能接住 IP 数据包，但域名分流还依赖 DNS 信息。若应用先从外部 DNS 得到真实 IP，规则引擎可能只能看到 IP，导致基于域名的规则命中不稳定。mihomo 常用 Fake-IP 模式建立域名与保留地址之间的映射，再在连接阶段恢复原域名。

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

198.18.0.0/16 是 Fake-IP 常见保留范围，不代表真实远端服务器。看到应用连接该网段时，先检查是否已由 Clash 接管，不要把它直接当作 DNS 污染。端口 1053 是本地 DNS 监听示例；如果机器上已有服务占用该端口，应换成未占用端口，并同步调整调用方。

mihomo TUN 配置字段与 stack 选择

支持图形化 TUN 开关的客户端会自动生成一部分配置。需要手动维护 YAML 时，可以从一组保守参数开始：

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

关键字段逐项说明

  • enable：控制 TUN 是否启用。图形客户端可能在运行时覆盖该值，应以客户端当前开关和运行日志为准。
  • stack：选择 TUN 网络栈实现。mihomo 常见值包括 system、gvisor 与 mixed。
  • dns-hijack：把指定 DNS 流量交给内置 DNS 模块。any:53 覆盖常见 UDP 53，补充 TCP 53 可处理较大的 DNS 响应。
  • auto-route：自动写入接管流量所需的系统路由。
  • auto-detect-interface：自动识别当前出口网卡，适合会在 Wi-Fi、有线和热点之间切换的设备。
  • strict-route：强化路由约束，减少部分流量绕过 TUN 的情况，但与其他 VPN、虚拟机网络冲突时也应优先检查它。
  • mtu：虚拟网卡最大传输单元。以太网常见值是 1500，出现特定网站卡住或上传停顿时可测试 1400、1380 等较小值。

system、gvisor 与 mixed 怎么选

stack 特点 适用方向
system 更多依赖操作系统网络栈，通常开销较低 桌面系统日常使用，优先追求吞吐与低延迟
gvisor 使用用户态网络栈处理连接，兼容路径不同 system 下个别 TCP 或 UDP 程序异常时测试
mixed 结合不同栈的处理方式，兼顾常见连接 mihomo 新配置的通用起点

没有一个 stack 能在所有系统、驱动和应用组合上固定领先。建议先用 mixed，连续测试网页、视频、命令行下载和实时通信。如果只有某类 UDP 应用异常，再切换 gvisor 对照；如果主要关注大文件吞吐，可以比较 system。

一次本地千兆网络测试中，同一节点、同一时段下载 1 GB 文件，system、mixed 与 gvisor 分别约为 87 MB/s、84 MB/s 和 76 MB/s，差距会随 CPU、系统版本与节点质量变化。这组数值只用于说明测试方法，不应当作固定性能排名。每次切换 stack 后应重启内核，并使用同一目标连续测 3 次。

Windows、macOS 与移动端开启步骤

Windows：先安装服务，再打开 TUN

  1. 打开客户端，进入「设置」→「内核」，确认当前运行 mihomo 或 Clash Meta。
  2. 进入「设置」→「服务模式」，选择安装服务。系统出现用户账户控制提示时确认操作。
  3. 服务安装完成后退出并重新启动客户端，检查服务状态是否显示为运行中。
  4. 返回主界面或「设置」→「网络设置」，开启「TUN 模式」。
  5. 代理模式选择 Rule，不要把 TUN 开关与 Global 模式混为一项。
  6. 打开日志，将级别暂时设为 info，访问一个直连站点和一个代理站点，确认两类连接都出现规则命中。

如果开关立即自动关闭，优先检查服务是否安装成功、客户端是否被安全策略阻止创建虚拟网卡，以及是否有另一个 VPN 正在修改默认路由。Windows 的 Hyper-V、WSL2 和虚拟机软件也会建立虚拟交换网络，但通常可以共存；只有在路由优先级或 DNS 被重复接管时才需要逐项停用测试。

macOS：允许辅助程序和网络扩展

  1. 进入客户端「设置」→「内核设置」，确认内核支持 TUN。
  2. 在「设置」→「服务模式」或「权限管理」中安装辅助程序。
  3. 开启 TUN，按提示输入管理员密码或使用 Touch ID。
  4. 如系统给出扩展被阻止提示，打开「系统设置」→「隐私与安全性」，允许对应开发者的系统软件。
  5. 回到客户端重启内核，再检查「系统设置」→「网络」中是否出现对应的 VPN 或虚拟网络状态。

macOS 上同时开启系统代理与 TUN 通常不是必要条件。多数客户端会自行处理两者关系，但排障时可以先关闭系统代理，只保留 TUN，避免同一请求经过重复入口。若 TUN 关闭后系统代理仍残留，进入「系统设置」→「网络」→当前网络→「详细信息」→「代理」，确认 HTTP、HTTPS 和 SOCKS 代理是否已恢复。

Android 与 iOS：由系统 VPN 接口完成接管

Android 客户端一般在主界面点击启动后申请 VPN 权限，随后通过 Android VPNService 接管选定流量。可以在客户端「设置」→「网络」中查看绕过局域网、仅代理所选应用、IPv6 和 DNS 选项。启用分应用代理时，名单之外的软件不会进入 Clash，排查前先确认当前采用“仅代理所选应用”还是“排除所选应用”。

iOS 客户端依赖 Network Extension 提供的 VPN 能力。导入订阅后，需要在客户端内启动代理，并允许系统添加 VPN 配置。iOS 不会直接照搬桌面 YAML 中所有 TUN 参数，具体 stack、路由与 DNS 能力由客户端及系统扩展决定。桌面端配置中的 auto-route 或服务模式步骤，不应机械套用到 iPhone。

TUN 开启后的验证方法

用系统代理无法覆盖的程序测试

只打开浏览器不足以证明 TUN 正常，因为浏览器本来就可能遵循系统代理。更合适的验证方式是临时关闭系统代理，保留 TUN，然后在终端执行网络请求：

curl -I https://example.com
curl -4 https://example.com
nslookup example.com 127.0.0.1

第一条检查 HTTPS 请求，第二条强制使用 IPv4，第三条用于确认本地 DNS 响应。实际执行 nslookup 时，如果 DNS 监听在 1053 而工具不支持直接指定非标准端口，应改用支持端口参数的 DNS 工具，或临时检查客户端 DNS 日志。

观察日志中的三类信息

  • 入口：日志应显示连接来自 TUN，而不是只出现 HTTP 或 SOCKS 入口。
  • 目标：域名规则应能显示原始域名；始终只有 IP 时要检查 DNS 劫持和 Fake-IP。
  • 策略：确认连接命中预期规则和代理组，而不是直接落到最后的 MATCH。

验证局域网时，可访问路由器管理地址，例如 192.168.1.1。它通常应当直连。配置中可以保留私有地址规则，例如 IP-CIDR,192.168.0.0/16,DIRECT,no-resolve、IP-CIDR,10.0.0.0/8,DIRECT,no-resolve。如果开启 TUN 后打印机、NAS 或路由器后台失联，应先检查这些局域网规则，而不是先更换代理节点。

常见故障与定位顺序

开启后完全断网

  1. 关闭 TUN，确认原网络本身可以访问互联网。
  2. 检查客户端内核是否正在运行，监听端口 7890、7891 是否被其他进程占用。
  3. 查看 TUN 日志是否出现权限不足、创建设备失败或写入路由失败。
  4. 暂时停用其他 VPN、游戏加速器和网络过滤工具，再重新启动内核。
  5. 把 strict-route 暂时改为 false 对照测试；若网络恢复，再检查冲突路由。
  6. 确认订阅中至少有一个可用节点，并直接执行节点延迟测试。

网页能开，但游戏或语音连接失败

网页主要使用 TCP，而实时语音、部分游戏和 QUIC 会使用 UDP。先确认代理节点本身支持 UDP，再检查代理组和节点配置是否允许 UDP。将 stack 在 mixed、system 与 gvisor 之间进行单变量对照，不要同时修改 DNS 和规则。

还可以临时关闭浏览器 QUIC 进行判断：若关闭后网页稳定，问题可能集中在 UDP 路径；若 TCP 也不稳定，则继续检查 MTU。特定页面加载到一半停止、文字能开但图片卡住，常见于路径 MTU 不匹配。可从 1500 调到 1400，重启内核后再测试，不建议一开始就降到很小。

DNS 正常返回，但规则总是匹配 IP

先确认 enhanced-mode 是否为 fake-ip，再检查 dns-hijack 是否覆盖 UDP 与 TCP 53。部分应用使用 DoH 或 DoT，普通 53 端口劫持无法读取加密 DNS 内容。可通过规则阻止应用直连外部 DoH，或让应用改用系统 DNS。不要随意拦截所有 443 端口，因为正常 HTTPS 也使用该端口。

fake-ip-filter 适合排除必须拿到真实地址的域名，例如局域网设备发现、部分时间同步和特殊登录服务。过滤范围写得过宽，会让大量域名绕开 Fake-IP 映射，削弱域名分流效果。应按日志逐条添加，而不是直接过滤整个顶级域。

休眠唤醒或切换 Wi-Fi 后失去连接

设备从有线切到 Wi-Fi，默认出口接口和路由可能发生变化。启用 auto-detect-interface: true 后，mihomo 可自动识别出口，但部分系统仍需要重启内核才能刷新状态。建议操作顺序是：暂停 TUN、切换网络、等待系统获得新 IP、重启内核、重新开启 TUN。

如果每次唤醒都出现相同问题，记录故障前后的默认路由和 DNS 地址。Windows 可使用 route print 与 ipconfig /all，macOS 可使用 route -n get default 与 scutil --dns。比较结果通常比反复重装客户端更快找到冲突来源。

一套可复用的配置顺序

第一次配置 TUN 时，建议把步骤固定下来：先确认节点可用，再确认 Rule 模式下系统代理正常；随后安装系统服务或授权网络扩展；使用 mixed、自动路由和自动识别接口开启 TUN；最后补充 DNS 劫持与 Fake-IP。每完成一步就观察日志和访问结果。

稳定后再处理性能优化。先记录默认配置下的延迟、下载速度和 CPU 占用，然后单独切换 stack 或 MTU。延迟测试至少连续运行 20 次，大文件测试保持同一目标和同一时间段。节点负载变化通常比 stack 差异更大，一次测速不能说明长期表现。

TUN 的价值是把更多流量送进同一套规则系统，而不是替代规则、订阅和 DNS 配置。入口接管、域名识别、规则匹配、节点连接四个环节都正常，虚拟网卡模式才算真正配置完成。