安卓 Clash TUN 模式原理与开启方法：接管全部应用流量

TUN 模式解决什么问题

普通 HTTP 或 SOCKS 代理依赖应用主动把连接交给代理端口。例如浏览器可以读取 Android 的代理设置，支持手动配置的下载工具也能连接到本机的 127.0.0.1:7890。但部分游戏、推送服务、命令行工具、基于 UDP 的应用不会读取系统 HTTP 代理，流量仍可能直接访问网络。TUN 模式针对的正是这一类接管缺口。

在 Android 上启用 TUN 后，Clash Meta for Android 会通过系统提供的 VpnService 创建虚拟网络接口。应用发出的 IP 数据包先进入这个接口，再由 mihomo 内核识别目标地址、域名、协议和应用信息，匹配配置中的规则，最后选择 DIRECT、REJECT 或某个代理策略组。它处理的是网络层数据包，不要求每个应用单独支持 HTTP 或 SOCKS 代理。

一次连接在 TUN 模式下经过哪些环节

1. 应用请求解析域名，DNS 查询被配置的 DNS 劫持规则接收。
2. mihomo 根据 DNS 模式返回真实地址或 Fake-IP 地址，并保存域名映射。
3. 应用向目标地址建立 TCP、UDP 或 QUIC 连接，数据包进入 Android 虚拟网卡。
4. 内核恢复连接对应的域名与进程信息，然后从上到下匹配 rules。
5. 命中的策略组选择具体节点，DIRECT 规则则从当前物理网络接口直接发出。
6. 返回数据沿原路径交给应用，应用本身不需要知道代理端口或节点地址。

因此，“接管全部应用流量”表示所有未被排除的应用都会先经过虚拟网卡，并不表示所有连接都必须走代理。最终动作仍由规则决定。局域网地址、国内站点或指定应用可以保持 DIRECT，广告域名可以 REJECT，只有命中代理规则的连接才进入节点。

TUN 与系统代理模式的差异

系统代理和 TUN 并不是同一层级的两个开关。系统代理主要公布 HTTP 代理地址，能否生效取决于应用是否遵循该设置；TUN 则从 IP 层拦截连接，覆盖范围更完整。对只浏览网页、调试接口的场景，系统代理配置简单且额外开销较小。对游戏、即时通信、UDP、无法填写代理地址的应用，TUN 更合适。

性能差异应怎样理解

TUN 会增加数据包进入用户态内核、规则匹配和转发的步骤，但通常不是速度下降的首要来源。节点带宽、跨境线路、加密协议、运营商拥塞和 UDP 质量更容易形成瓶颈。以一台 Android 14、Wi-Fi 6、局域网基线 312 Mbps 的测试设备为例，同一节点在显式 HTTP 代理下测得 286 Mbps，在 TUN mixed 栈下测得 274 Mbps；节点延迟分别为 41 ms 和 43 ms。这个约 4% 的差值只用于说明量级，不能作为其他设备的固定结论。

如果开启 TUN 后速度从 200 Mbps 降到 20 Mbps，或延迟从 50 ms 上升到 300 ms，应优先检查节点、MTU、UDP、DNS 和网络切换，而不是把正常的 TUN 转发开销当作唯一原因。

在 Clash Meta for Android 中开启 TUN

以下路径以 Clash Meta for Android 2.11 系列界面为参照。不同分支可能把“网络”命名为“服务”或“覆写”，但核心项目仍是 TUN、路由、DNS 劫持和应用分流。开始前应先导入有效订阅，选择可用配置，并在代理页确认至少一个策略组已经选中有效节点。

步骤一：确认配置和运行模式

1. 打开「配置」页面，点选已经更新成功的订阅配置。
2. 进入「代理」，在常用策略组中选择节点，执行一次延迟测试。
3. 进入「设置」→「覆写」→「规则模式」，选择 Rule。Global 会让绝大多数连接进入同一代理，Direct 则会绕过代理规则。
4. 返回首页，暂时停止正在运行的服务，避免修改网络参数时保留旧会话。

步骤二：启用 TUN 与自动路由

1. 进入「设置」→「网络」→「TUN 模式」，打开 TUN。
2. 打开「自动路由」或 auto-route，让内核为虚拟接口建立所需路由。
3. 打开「自动检测接口」或 auto-detect-interface，使 Wi-Fi 与移动数据切换后重新选择出口。
4. TUN 栈优先选择 mixed。遇到特定设备兼容问题时，再分别测试 system 或 gVisor。
5. 返回首页启动服务，在 Android 弹出的连接请求中选择允许。

步骤三：验证是否真正接管

• Android 状态栏应显示 VPN 标记，客户端首页应显示运行中。
• 打开「日志」，访问一个新域名，应看到 DNS、规则命中和策略组记录。
• 切换到一个不读取系统代理的应用，检查它是否也产生连接日志。
• 关闭客户端后公网出口恢复，重新开启后按当前策略变化，说明路由已切换。
• 访问局域网网关，例如 192.168.1.1，确认私网连接仍按 DIRECT 处理。

仅看到 VPN 标记不能证明规则与 DNS 都正确。更可靠的验证方式是结合实时日志观察。典型日志会包含目标域名、目标端口、命中规则和出站策略，例如某个 HTTPS 连接命中 DOMAIN-SUFFIX，然后交给“节点选择”策略组。若日志只有 IP 地址而没有域名，通常需要继续检查 DNS 劫持或域名嗅探设置。

配置 DNS 劫持与 Fake-IP

TUN 接管连接后，DNS 仍是决定规则准确度的关键环节。若应用把 DNS 查询直接发送到指定服务器，或 Android 私有 DNS 使用独立加密通道，内核可能只看到目标 IP，域名规则和分流效果会变差。DNS 劫持的目的，是把常见的 53 端口查询交给 mihomo 的 DNS 模块统一处理，而不是把所有 DNS 请求强制发往同一个公共服务器。

一份可读的 mihomo 配置结构

mixed-port: 7890
mode: rule
log-level: info

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost"
    - "time.*.com"

any:53 用于接管常规 UDP 和 TCP DNS 查询；listen: 0.0.0.0:1053 是 mihomo DNS 模块的监听位置，不应与本机其他服务占用的端口重复。198.18.0.1/16 属于基准测试保留地址段，Fake-IP 模式会从该范围返回临时地址，再由内核把它映射回原始域名。应用连接这个临时地址时，规则引擎就能恢复域名并准确匹配。

Fake-IP 与 Redir-Host 怎么选

• Fake-IP：域名映射直接，规则匹配效率高，适合常规手机使用，也是多数 TUN 配置的优先选择。
• Redir-Host：向应用返回真实解析地址，兼容依赖真实 IP 的少数局域网或企业应用，但域名还原能力更依赖缓存与嗅探。
• Fake-IP 过滤：局域网域名、时间同步、设备发现或特定登录域名异常时，可把明确的域名加入 fake-ip-filter，不宜直接加入过宽的通配规则。

Android 私有 DNS 的处理

Android 的「设置」→「网络和互联网」→「私有 DNS」使用 DNS over TLS，目标端口通常为 853，并不属于普通的 53 端口查询。若开启 TUN 后出现部分域名长时间等待，可先把私有 DNS 改为“自动”，重新启动 Clash 服务后测试。确认问题来自私有 DNS 再决定是否保留，不需要在连接正常时机械地关闭。

应用分流、局域网与 UDP 设置

TUN 默认接管范围较广，但 Android 客户端通常允许按应用选择包含或排除。应用分流发生在进入规则引擎之前，Clash 规则则决定已经进入内核的连接走哪个出口。两者作用层级不同：把应用排除后，该应用不会再受域名规则和策略组控制。

按应用设置接管范围

1. 进入「设置」→「网络」→「应用分流」。
2. 选择“仅代理选中的应用”时，只有列表中的应用进入 TUN。
3. 选择“绕过选中的应用”时，列表中的应用直接使用系统网络，其余应用进入 TUN。
4. 银行、投屏、车机互联或企业认证应用如出现兼容问题，可先单独排除验证，不要一次排除整个系统应用集合。
5. 修改应用列表后停止并重新启动服务，让现有连接全部重建。

保留局域网访问

访问路由器、NAS、打印机和投屏设备时，应确保私有地址段走 DIRECT。常见范围包括 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 和链路本地地址 169.254.0.0/16。使用规则集的配置通常已经包含 LAN 规则，但仍应检查这些规则位于兜底规则 MATCH 之前。

rules:
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,169.254.0.0/16,DIRECT,no-resolve
  - MATCH,节点选择

UDP、QUIC 与游戏连接

游戏语音、实时对战、视频通话和 HTTP/3 常使用 UDP。节点协议与服务端必须实际支持 UDP，仅在客户端打开 TUN 并不能补齐服务端能力。如果网页正常但游戏停在登录、语音无法连接，可在日志中查看目标是否使用 UDP，以及策略组所选节点是否允许 UDP 转发。

QUIC 通常使用 UDP 443。线路对 UDP 不稳定时，浏览器可能反复尝试 QUIC，表现为网页首开慢、随后回落到 TCP。排查时可临时用规则拒绝 UDP,443 或在浏览器侧关闭 QUIC 做对照，但不建议把禁用 UDP 443 当作所有配置的长期默认值。

TUN 开启后常见故障排查

服务启动后完全无法联网

1. 确认当前配置已被选中，而不是只完成了订阅下载。
2. 在「代理」页面选择一个延迟测试可返回数值的节点。
3. 检查模式是否误设为 Direct，规则配置末尾是否存在有效兜底。
4. 查看日志是否出现配置解析失败、端口占用或 VPN 权限被拒绝。
5. 停止其他 VPN 型应用，再重启 Clash 服务。
6. 把 TUN 栈从 mixed 切换为 system，重新测试一次。

能打开 IP 地址，但域名打不开

这类现象通常指向 DNS。先检查 dns.enable 是否为 true，再确认 DNS 服务器在当前网络可达。若配置使用 DoH，上游域名本身也需要可完成初始解析。随后检查 dns-hijack、Android 私有 DNS，以及日志中是否存在 timeout、SERVFAIL 或循环查询。

开启后耗电或发热明显

TUN 常驻本身会产生一定后台活动，但持续高耗电通常伴随连接重试。进入「日志」观察是否有某个域名每秒重复查询、节点不断重连或 UDP 会话持续失败。Android 电池页面若显示客户端长时间保持高 CPU，可依次测试关闭详细日志、切换 TUN 栈、停用异常节点，并把不需要代理的高频局域网应用排除。

Wi-Fi 切换移动数据后断网

确认启用了 auto-detect-interface。网络切换后旧连接不会全部无缝迁移，少数应用需要重新建立会话；如果一分钟后仍未恢复，可停止再启动服务。还应检查是否启用了过于严格的路由选项，以及配置是否把旧 Wi-Fi 网关写成固定出口。

局域网设备无法发现

投屏和设备发现常依赖 mDNS、SSDP 或广播。先验证能否直接打开设备 IP，再检查私网地址规则。如果 IP 可访问但自动发现失败，可将投屏应用加入绕过列表，或针对 UDP 5353 等局域网发现流量设置 DIRECT。不要把所有 UDP 一并代理，否则可能让广播数据离开本地网络。

部分应用登录循环或验证码异常

先在日志中确认登录接口命中的策略。应用的主域名、验证码域名和风控接口如果分别走不同地区节点，可能触发会话不一致。把相关域名归入同一策略组，固定节点后清除应用的失败会话再试。若该应用依赖真实 DNS 地址，可只为明确域名增加 Fake-IP 过滤，而不是整体关闭 DNS 增强模式。

适合长期使用的配置原则

• 日常使用选择 Rule 模式，让代理、直连和拒绝动作由规则明确决定。
• TUN 栈从 mixed 开始，只有出现可复现的兼容问题时才切换 system 或 gVisor。
• 保留自动路由和自动检测接口，减少 Wi-Fi、热点与移动数据切换后的失联。
• DNS 使用可达的加密上游，并通过日志确认没有解析循环和持续超时。
• 局域网地址置于兜底规则之前，NAS、打印机和路由器管理页保持 DIRECT。
• 应用分流只排除确认有冲突的应用，避免接管范围与预期不一致。
• 更改 TUN、DNS 或应用列表后重启服务，排除旧连接和旧 DNS 缓存干扰。

TUN 的核心价值不是把所有流量机械地送入同一个节点，而是给 mihomo 提供统一、可观察的流量入口。虚拟网卡负责接管，DNS 模块负责保留域名上下文，规则负责决定去向，策略组负责选择出口。按这四层检查，通常比反复更换客户端或随机切换开关更快定位问题。

如果只需要让支持代理的浏览器访问特定服务，显式 HTTP 或 SOCKS 代理已经足够。若需要覆盖游戏、UDP、后台服务和不读取系统代理的应用，再启用 TUN。选择应以接管范围为依据，而不是把 TUN 视为所有场景都必须打开的性能选项。