Mihomo TUN 模式深度解析：从虚拟网卡到系统级透明代理的完整实现

为什么需要 TUN 模式？

如果你用过 Clash 系客户端，可能已经习惯了”规则分流”的概念——浏览器走代理、其他应用走直连。但这背后隐藏着一个关键的技术选择：系统代理 vs TUN 模式。

系统代理通过设置 HTTP/SOCKS 代理环境变量来工作。它的局限在于：只有遵守代理协议的应用才会走代理。命令行工具（curl、git、pip）、游戏、P2P 下载、Docker 容器……这些通常不会读取系统代理设置，它们的流量会直接绕过 Clash，暴露真实 IP。这在日常使用中可能不是大问题，但在需要全局代理的场景（比如访问某些服务需要特定 IP，或者需要防止所有流量泄露）下，系统代理就力不从心了。

TUN 模式通过在操作系统中创建一个虚拟网络接口（TUN 设备），在网络层（第三层）拦截所有 IP 流量，然后根据 Clash 的规则进行分流。它绕过了应用层的限制，实现了真正的系统级透明代理。在 Mihomo（Clash Meta）内核中，TUN 模式是官方推荐的生产方案，支持 Linux、macOS、Windows 和 Android 全平台。

本文将从 TUN 模式的工作原理、配置详解、常见问题排查、性能优化四个维度，帮助你深入理解并正确使用 Mihomo TUN 模式。

第一章：TUN 模式的工作原理

1.1 网络层代理 vs 应用层代理

要理解 TUN 模式，需要先理解操作系统网络栈的工作方式：

• 应用层（第七层）：HTTP 代理工作在这里。应用需要主动连接代理服务器，或者读取系统代理设置。很多应用（特别是命令行工具和游戏）不会这样做。
• 传输层（第四层）：SOCKS5 代理工作在这里。同样需要应用主动支持 SOCKS5 协议。
• 网络层（第三层）：TUN 模式工作在这里。操作系统将所有 IP 包路由到 TUN 虚拟网卡，由 Clash 内核接管处理。

TUN 模式的核心优势在于：它不依赖应用的配合。无论应用是否知道代理的存在，它的流量都会被正确处理。 这就是”透明代理”的含义——对应用来说，代理是完全透明的。

1.2 Mihomo TUN 数据流路径

当一个应用发起网络请求时，在 TUN 模式下的数据流路径如下：

1. 应用调用系统 Socket API 发送数据包（如 connect() 到 8.8.8.8:443）
2. 操作系统路由表将这个数据包路由到 TUN 虚拟网卡（wg0 或 utun）
3. Mihomo 内核从 TUN 设备读取数据包，解析目标地址和端口
4. 根据 Clash 规则匹配结果，决定走哪个代理节点（或直连）
5. 如果命中代理规则：通过代理协议加密后发送到远程服务器
6. 如果命中直连规则：通过真实网卡发送到目标服务器
7. 返回数据按原路回传，Mihomo 将解密后的数据写入 TUN 设备
8. 应用收到响应，完全不知道中间经过了代理

整个过程对应用完全透明，应用看到的网络环境与没有代理时完全一样——只是所有的流量都被 Mihomo 接管和处理了。

1.3 TUN 模式下的 DNS 处理

DNS 是 TUN 模式中最容易出问题的环节。在系统代理模式下，浏览器走代理，DNS 请求自然由代理服务器处理。但在 TUN 模式下，所有应用的 DNS 请求也会被 TUN 设备拦截——如果处理不当，会导致 DNS 泄露（真实 IP 通过 DNS 请求暴露）。

Mihomo 提供了两种 DNS 方案：

Fake-IP 模式（推荐）：Mihomo 拦截所有 DNS 请求，立即返回一个虚假的 IP 地址（通常在 198.18.0.0/16 段），同时将域名-IP 的映射关系缓存起来。当应用使用这个虚假 IP 发起连接时，Mihomo 根据映射关系找到真实域名，再通过代理解析和连接。这种方式的优势是速度极快（不需要等待真实的 DNS 查询返回），且完全杜绝 DNS 泄露。

Redir-Host 模式：Mihomo 将 DNS 请求转发到上游 DNS 服务器（如 1.1.1.1 或 8.8.8.8），获取真实 IP 后再进行代理连接。这种方式兼容性更好（某些应用不接受 Fake-IP），但速度稍慢，且有 DNS 泄露风险。

对于大多数用户，推荐使用 Fake-IP 模式。它的性能和安全性都优于 Redir-Host。只有在遇到特定应用兼容性问题时，才需要切换到 Redir-Host。

第二章：Mihomo TUN 配置详解

2.1 最小可用配置

以下是一个 Mihomo TUN 模式的最小配置，包含了 DNS、TUN、代理和规则的基本设置：

# mihomo-config.yaml
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    # 局域网域名不使用 Fake-IP
    - '*.lan'
    - 'localhost.ptlogin2.qq.com'
    # 需要真实解析的域名
    - '+.msftconnecttest.com'
    - '+.msftncsi.com'
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

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

proxies:
  - name: "hk-node"
    type: ss
    server: hk-server.example.com
    port: 8388
    cipher: aes-256-gcm
    password: "your-password"

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - "hk-node"
      - "DIRECT"

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

2.2 TUN 栈选择：gvisor vs system

Mihomo 的 TUN 模式支持两种实现栈：

特性	gvisor（推荐）	system
兼容性	全平台，不需要额外权限	仅 Linux/macOS，需要 root/Administrator
性能	良好（用户态实现）	最优（内核态实现）
稳定性	高，适合日常使用	可能影响系统网络栈
推荐场景	大多数用户	Linux 服务器、追求极致性能

建议始终使用 gvisor 栈，除非你在 Linux 服务器上部署且有明确的高吞吐量需求。

2.3 DNS 劫持（dns-hijack）配置

dns-hijack 是 TUN 模式中 DNS 处理的关键配置。它告诉 Mihomo 拦截发往特定端口和地址的 DNS 请求：

tun:
  dns-hijack:
    # 劫持所有发往 53 端口的 DNS 请求
    - any:53
    # 也可以劫持特定 DNS 服务器的请求
    - 8.8.8.8:53
    - 1.1.1.1:53
    # 劫持 DNS-over-HTTPS
    - any:443

推荐使用 any:53，它会劫持所有发往 53 端口的 DNS 请求。如果你发现某些应用的 DNS 请求没有被拦截，可以添加更多规则。

第三章：常见问题排查

3.1 开启 TUN 后无法上网

这是最常见的问题，通常由以下原因导致：

原因一：路由表冲突。 如果你同时运行了其他 VPN 软件（如 OpenVPN、WireGuard 客户端），它们的路由规则可能与 Mihomo TUN 冲突。解决方法是先关闭其他 VPN，或调整 Mihomo 的 auto-route 设置。

原因二：DNS 解析失败。 如果 Mihomo 的 nameserver 配置不正确，所有域名都无法解析。检查 nameserver 中的 DNS 服务器是否可达（可以先关掉 TUN，用 nslookup 测试）。

原因三：防火墙阻止。 Windows Defender 防火墙可能阻止 Mihomo 创建 TUN 设备。需要在防火墙设置中允许 Mihomo 的网络访问。

3.2 某些应用不走代理

情况一：应用使用了硬编码 DNS。 某些应用（如部分游戏）内置了 DNS 服务器地址（如 8.8.8.8），绕过系统 DNS 设置。在 TUN 模式下，这些 DNS 请求也会被 dns-hijack 拦截。如果没有被拦截，在 dns-hijack 中添加对应的 DNS 地址即可。

情况二：应用使用了 UDP/QUIC。 某些应用使用 QUIC 协议（如 Chrome 的 HTTP/3），其底层是 UDP。确保 Mihomo 的代理节点支持 UDP 转发。如果节点不支持 UDP，QUIC 流量会直接失败，浏览器会自动降级到 TCP+TLS（HTTP/2），不影响使用。

3.3 TUN 模式下的性能监控

Mihomo 提供了丰富的运行时数据，可以通过 RESTful API 获取：

# 查看 TUN 设备流量统计
curl http://127.0.0.1:9090/traffic

# 查看当前连接数和活跃代理
curl http://127.0.0.1:9090/connections

# 查看 DNS 缓存和解析情况
curl http://127.0.0.1:9090/dns/query?name=google.com&type=A

配合 支持 Clash 订阅的机场节点 使用时，TUN 模式的优势更加明显——你可以在一条机场订阅中混合使用多种协议的节点，由 Mihomo 根据规则自动选择最优路径，实现真正的”智能分流”。

第四章：TUN 模式性能优化

4.1 减少 Fake-IP 缓存冲突

在 Fake-IP 模式下，所有域名都被映射到 198.18.0.0/16 段的 IP。如果缓存映射表过大，可能导致内存占用增加和查找变慢。优化方法：

• 在 fake-ip-filter 中添加不需要代理的域名，让它们直接使用真实 IP
• 定期重启 Mihomo 清理缓存（对于长期运行的服务端部署）
• 设置合理的 fake-ip-cache-size（默认足够大，通常不需要调整）

4.2 规则优化减少匹配延迟

每一条规则都是一个正则匹配或子串匹配。规则过多会导致延迟增加。优化方法：

• 将高频匹配的规则放在前面（GEOIP、DOMAIN-SUFFIX 通常命中率高）
• 使用 rule-providers 替代内联规则，远程规则集由 Mihomo 预加载到内存中
• 避免过多的正则表达式规则，优先使用 DOMAIN-SUFFIX 和 DOMAIN-KEYWORD

4.3 推荐的规则集搭配

TUN 模式下，因为所有流量都经过 Clash，一套好的规则集尤为重要。如果你不想手动维护规则，推荐使用成熟的规则集服务。在 机场推荐 页面筛选支持 rule-provider 的服务商，它们的订阅链接通常内置了高质量的规则配置，省去了自己维护的麻烦。同时也可以参考 Clash 客户端下载页面 获取各平台的 Mihomo 内核客户端，确保 TUN 模式的兼容性。

总结

TUN 模式是 Mihomo 内核中最强大但也最容易出问题的功能。理解它的工作原理后，你会发现”透明代理”并没有想象中复杂——核心就是虚拟网卡 + DNS 劫持 + 规则分流三个步骤。配置正确后，TUN 模式能提供系统级的全局代理体验，同时保持 Clash 强大的规则分流能力。

对于日常使用，推荐在 PC 端使用 Clash Verge Rev 或 Clash Nyanpasu 等客户端（它们内置了 TUN 模式的图形开关），在 Android 端使用 Surfboard 或 Clash Meta for Android。配合优质的机场订阅，一键导入即可享受全局智能分流。